Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 06-09-03, 04:19 PM   #1
Chem
Registered User
 
Join Date: Apr 2003
Posts: 15
Default Application error with RH9 + 43.49 / 43.63

Hello,

I am using an NVIDIA Quadro4 750 XGL under a fresh install of RedHat 9. One application I use is a computational chemistry tool called "Ecce" .. homepage of http://www.emsl.pnl.gov:2080/docs/ecce/

Ecce worked fine with this video card in RedHat 8, using the 43.49 nvidia linux drivers. However, upgrading to RH9, certain features of it are broken in both 43.49 and 43.63. Specifically, there are operations which result in the error:

-----
./builder: relocation error: /usr/lib/tls/libGLcore.so.1: undefined symbol: __gl_tls_var0
Exec failed - child 2159 died
-----

...I'm guessing this is associated with RH9 using glibc 2.3 (tls-based?) libraries. But I don't know if the exact error is a problem in RH9, the NVidia drivers, or Ecce.

Was hoping Andy could give some insight if this could be an nvidia bug. We contacted the Ecce developers and they had no immediate response (they were surprised to hear this...).

Nothing special in my XF86Config or log; a modeline created by gtf. RH9 defaults.
Chem is offline   Reply With Quote
Old 06-09-03, 05:41 PM   #2
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default

If this is the boxed U.S. version of RH9, then you need to update your glibc (to the latest patchlevel of 2.3.X that RedHat has available), because the glibc that shipped with RH9 is buggy. Even if it isn't the boxed U.S. version, try upgrading glibc (but DON'T try upgrading from 2.2.X to 2.3.X, or you WILL break a lot of stuff).

Actually, if you didn't recompile Ecce on the RH9 installation, that could very well be the problem too... but I think it's driver related (either the driver didn't install the correct TLS version libs, or something like that).
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Old 06-10-03, 10:15 AM   #3
Chem
Registered User
 
Join Date: Apr 2003
Posts: 15
Default

our RH9 has all the latest patches installed. Ecce was not recompiled; in fact the source code is not distributed. it was 99% likely compiled on a RH7.3 box. that in itself should not be evil...

the error is an OpenGL library error, in a file distributed by the nvidia driver, I believe...
Chem is offline   Reply With Quote
Old 06-10-03, 05:36 PM   #4
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default

Quote:
Originally posted by Chem
it was 99% likely compiled on a RH7.3 box. that in itself should not be evil...
Actually, yes, that in itself is evil. RH7.3 used glibc 2.2, and RH9 uses glibc 2.3. Those two glibc's are only barely compatible.

Talk to whoever makes Ecce and see if there are plans to recompile it for a newer glibc version (it probably won't need any source code changes, but the old binaries almost assuredly won't work).
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Old 06-11-03, 03:13 PM   #5
Chem
Registered User
 
Join Date: Apr 2003
Posts: 15
Default

Quote:
Originally posted by bwkaz
[b]Actually, yes, that in itself is evil. RH7.3 used glibc 2.2, and RH9 uses glibc 2.3. Those two glibc's are only barely compatible.
as noted in my original post, the error occurs in an openGL library distributed by NVIDIA.

So I was hoping our local NVIDIA rep on this board would at least comment on the possiblity of the error being a bug in the file they distribute. We run plenty of other apps compiled under RH7.3 just fine on RH9, thank you very much.

But Andy seems to be MIA...

-Brian
Chem is offline   Reply With Quote
Old 06-11-03, 07:41 PM   #6
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default

Yes, it is a library distributed by nVidia, but the simple fact that hundreds (if not thousands) of other people are using the very same library without problems points to something unique on your system.

Near as I can tell, that uniqueness is running a program linked against glibc 2.2 under glibc 2.3. Granted, that may not be the case, but if you grab one of the many open-source GL programs floating around (something like the last release of TuxRacer before it went commercial), I bet that it'll work without that error.

I'm thinking it's some sort of interaction between TLS and non-TLS libraries (the program itself links against non-TLS, but the libGLcore links against TLS, or something like that), but since I've never used a RH9-TLS system, I don't know enough about how that works.

Yeah, I'm not sure where Andy went, but it seems like he's here for a few weeks or so around a new driver release, then disappears doing either driver development, or driver developer bugging, or something, until about the time the next driver gets released. Whatever -- how he spends his time doesn't really bother me.
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 06:28 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.