If you want to compile things you usually need header files. In the case of GL apps, the only place I've managed to find header files is in mesa-devel.rpm. Installing this package, however, *breaks* GL, since it forces a symlink libGL.so -> the mesasoft driver. All apps compiled with -lGL will look for libGL.so, not libGL.so.1 The rpm that was available on nvidia's was apparently made for RedHat, but this had code in the install scripts that correctly set the .so symlink. The new suse rpm still ignores it. It doesn't install the symlink, doesn't do anything about it in the install scripts and the switch2nvidia_glx still doesn't do it. Yes, changing the symlink manually isn't that difficult, but then again, neither is setting the other symlinks. My questions are 1) where, if not in mesa-devel.rpm, is one to find the GL header files 2) why doesn't suse's script handle this symlink? Or have I missed something fundamental (again)? TIA Anders
Hello, On Wednesday 05 December 2001 15:41, you wrote:
My questions are 1) where, if not in mesa-devel.rpm, is one to find the GL header files
The header files you may be after can be found in the NVIDIA_GLX-1.0-2313.tar.gz file, here: ftp://209.213.197.10/XFree86_40/1.0-2313/NVIDIA_GLX-1.0-2313.tar.gz Piers
On Wednesday 05 December 2001 17.27, Piers Meynell wrote:
Hello,
On Wednesday 05 December 2001 15:41, you wrote:
My questions are 1) where, if not in mesa-devel.rpm, is one to find the GL header files
The header files you may be after can be found in the NVIDIA_GLX-1.0-2313.tar.gz file, here: ftp://209.213.197.10/XFree86_40/1.0-2313/NVIDIA_GLX-1.0-2313.tar.gz
Piers
Half of them, yes. Not, e.g., glext.h. On the DVD there are three packages I can find with these header files. mesa-devel, xf86glx-devel and glx-devel. All of them set the libGL.so symlink which means they all break when the real nvidia driver is installed. And the latter two both say to use mesa-devel. Anders
On Wednesday 05 December 2001 18.17, Anders Johansson wrote:
On the DVD there are three packages I can find with these header files. mesa-devel, xf86glx-devel and glx-devel. All of them set the libGL.so symlink which means they all break when the real nvidia driver is installed. And the latter two both say to use mesa-devel.
Still waiting for some sort of comment on this. It would be nice if someone told me what I'm missing. I have seen machines that crashes when 3D apps are run, and when the symlink is corrected it works. I did a little test on my machine. I changed the symlink to point to mesasoft, and did a ldconfig. ldd /opt/gnome/bin/gtulpas showed it pointing directly to libGL.so.1. I installed the source of gtulpas and recompiled with the symlink still pointing at mesasoft. ldd on the new binary still pointed directly at .so.1. An strace of the gcc process shows that I'm not completely insane. gcc does indeed open .so when it compiles. Could someone please tell me what I'm missing here. //Anders
On Thursday 06 December 2001 18.06, Anders Johansson wrote:
Could someone please tell me what I'm missing here.
I really really really would like a little education here. I thought I knew how the linker worked under *nix Please, bitte, snälla? //Anders
Still no sign of life in this thread. May I ask why? Is it a poorly phrased question, a stupid question or am I just being ignored here? //Anders
On Friday 07 December 2001 15:05, Anders Johansson wrote:
Still no sign of life in this thread. May I ask why? Is it a poorly phrased question, a stupid question or am I just being ignored here?
//Anders
Does 'it's over my head' work for you? :)
* Jerry Kreps (jk05308@alltel.net) [011207 19:50]:
On Friday 07 December 2001 15:05, Anders Johansson wrote:
Still no sign of life in this thread. May I ask why? Is it a poorly phrased question, a stupid question or am I just being ignored here?
Sorry. yes, the -devel package is the correct place to get the headers and the missing symlink most likely a %post_install bug in our package. I'll report it... -- -ckm
On Saturday 08 December 2001 05.12, Christopher Mahmood wrote:
Sorry. yes, the -devel package is the correct place to get the headers and the missing symlink most likely a %post_install bug in our package. I'll report it...
OK, thanks. But the more general question is this: I'm seeing that some packages seem to respect where a .so points to, and others, like ldconfig, jumps straight to .so.1, so I'd like to know what the rule is. How does the linker determin which lib to open when it's been dynamically linked to -lsomething. Sometimes it seems to be libsomething.so, other times libsomething.so.1. There must be a general rule to this //Anders
* Anders Johansson (andjoh@cicada.linux-site.net) [011208 02:20]:
How does the linker determin which lib to open when it's been dynamically linked to -lsomething. Sometimes it seems to be libsomething.so, other times libsomething.so.1. There must be a general rule to this
Thorstan Kukuk can give a much better answer than I can, but my understanding is that /etc/ld.so.cache (created by ldconfig) creates a mapping from sonames to filenames. E.g., libfoo might have a soname of foo so that you can link against it with -lfoo, but the file that that contains the object code might be named blahblah. If you run the ld.so.cache through strings you can kind of see what's going on: ckm@hades: ~> strings < /etc/ld.so.cache|grep GL libMesaGLU.so.3 /usr/lib/libMesaGLU.so.3 libMesaGL.so.3 /usr/lib/libMesaGL.so.3 libGLU.so.1 /usr/lib/libGLU.so.1 libGL.so.1 /usr/lib/libGL.so.1 -- -ckm
On Monday 10 December 2001 21.00, Christopher Mahmood wrote:
Thorstan Kukuk can give a much better answer than I can.
I've had a chance to meditate on this, and I now realize that my thinking was seriously fscked up on this. I was thinking about updating library versions and how not respecting symlinks could create problems, but after some hard thinking I now see that I had it all confused. Obviously if a version 2 is backwards compatible all one has to do is to symlink .1 to .2. no need to mix .so into it at all. Sorry //Anders
* Anders Johansson (andjoh@cicada.linux-site.net) [011210 13:57]:
On Monday 10 December 2001 21.00, Christopher Mahmood wrote:
Thorstan Kukuk can give a much better answer than I can.
Obviously if a version 2 is backwards compatible all one has to do is to symlink .1 to .2. no need to mix .so into it at all. Sorry
I don't know if that's always the case though. E.g., the Berkeley DB in libc isn't backwards compatible in some cases I think. But with something like GL it's probably a safe assumption. -- -ckm
* Anders Johansson [Mon, 10 Dec 2001 22:57:25 +0100]:
Obviously if a version 2 is backwards compatible all one has to do is to symlink .1 to .2. no need to mix .so into it at all.
You should never symlink .1 to .2 unless you can make sure that all structures are identical, functions take the same arguments and so on. Being backwards compatible does not suffice, the binary interface must be identical. Philipp -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
On Tuesday 11 December 2001 09.41, Philipp Thomas wrote:
You should never symlink .1 to .2 unless you can make sure that all structures are identical, functions take the same arguments and so on. Being backwards compatible does not suffice, the binary interface must be identical.
Not identical, surely. But the .1 functions and structures must exist in .2, I realize that. I was more concerned that the system somehow tried to outsmart me in a win-esque sort of way, but I think I've understood it now. Thanks for the explanation in the other mail, BTW. //Anders
* Anders Johansson [Tue, 11 Dec 2001 10:03:15 +0100]:
But the .1 functions and structures must exist in .2, I realize that.
And *those* must be identical, up to the last bit. Sorry that I didn't make that clear in my first mail. The only other possibility to change the ABI but not the major library version is using symbol versioning like glibc does, as this allows you to attach one or more versions to a symbol. Philipp -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
* Anders Johansson [Sat, 8 Dec 2001 11:20:44 +0100]:
How does the linker determin which lib to open when it's been dynamically linked to -lsomething. Sometimes it seems to be libsomething.so, other times libsomething.so.1. There must be a general rule to this
There is no real general rule. Dynamic libraries have an internal name, the so called soname, set at the time the library is created. Normally this is lib<name>.so.<major version> (I don't know what gets set if no soname is explicitly passed to the linker). This soname gets recorded in the binary that is linked to the library (AFAIR via DT_NEEDED). It's this soname that the dynamic linker ld.so searches for when resolving dependencies and that's also why ldconfig creates symlinks from the soname to the actual library. cheers Philipp -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
participants (5)
-
Anders Johansson -
Christopher Mahmood -
Jerry Kreps -
philippt＠t-online.de -
Piers Meynell