Anders Johansson [15 Feb 2003 22:17:00 +0100]:

How they connect a missing symlink libGL.so -> libGL.so.1 [to C++] is completely beyond me.

And it should! The author must have done something mysterious to get that. Normally a shared library has an internal name, the so called soname, which you can see when doing 'objdump -p' on a shared library. The linker will record this soname in any binary and library that is linked against such a library in DT_NEEDED records, which 'objdump -p' will show as NEEDED. For libGL.so.1 on a 7.3 system, this looks like this: Dynamic Section: NEEDED libSM.so.6 NEEDED libICE.so.6 NEEDED libXmu.so.6 NEEDED libXext.so.6 NEEDED libXi.so.6 NEEDED libX11.so.6 NEEDED libc.so.6 SONAME libGL.so.1 So you see, that the internal name is libGL.so.1 and you also see the libraries libGL needs. BTW, this is also the reason why ldconfig will create a symlink with the name of the soname to the actual library if soname and real name of the library differ, i.e. something like: libfoo.so.1 -> libfoo.so.1.3 Because the dynamic linker (/lib/ld-linux.so.2) will read these DT_NEEDED entries and then search for libraries with this name. The symlink ending in .so is only needed for linking libraries or binaries because the static linker (/usr/bin/ld), when passed the parameter -lGL will first search for a dynamic library named libfoo.so and then for a static library named libfoo.a.

It is, however, a "SuSE specific" problem (if it is indeed the problem), since other dists create that symlink by default.

What other dists do or don't do is irrelevant, as it would be plain wrong to provide this symlink in anything but the -devel package. When an application needs libGL.so when the soname is libGL.so.1, it's *wrong* to make that symlink because the application obviously either needs a different libGL or the programmer has done something stupid. It's IMO not SuSE's job to work around stupid setups in other distributions.

But yes, c++ ABI changes in gcc has been a huge problem.

Define huge problem. But it was inevitable *and* known well in advance that the ABI would change with gcc 3.X. The C++ ABI of gcc 3.X is a cross platform ABI, making it possible for the first time to link together C++ objects created by different compilers (if these also support this ABI). Philipp -- Philipp Thomas work: pthomas@suse.de Development SuSE Linux AG private: pth@t-link.de

The symlink ending in .so is only needed for linking libraries or binaries because the static linker (/usr/bin/ld), when passed the parameter -lGL will first search for a dynamic library named libfoo.so and then for a static library named libfoo.a.

I followed your reply doggedly, and understand it all except the paragraph quoted above. Should I be mentally replacing "libfoo" with "libGL"? Or, when you said "libfoo", did you mean something else I don't understand? Also, are you saying that the static linker will, as it's first option, look for a dynamic library, which it somehow links statically? If so, why? Why not look for a static library first? -- Microsoft Palladium: "Where the hell do you think YOU'RE going today?"

Is that a bit clearer?

Yes, thanks. Got it now. :o) -- Microsoft Palladium: "Where the hell do you think YOU'RE going today?"