C++ games on Linux, not good?
Check this thread: http://www.pluribus.org/forums/atitd/viewtopic.php?t=3569 Any comments? Or even suggestions? Matt
On Sat, 2003-02-15 at 22:07, Matthew Johnson wrote:
Check this thread:
http://www.pluribus.org/forums/atitd/viewtopic.php?t=3569
Any comments? Or even suggestions?
How they connect a missing symlink libGL.so -> libGL.so.1 is completely beyond me. It is, however, a "SuSE specific" problem (if it is indeed the problem), since other dists create that symlink by default. I've complained about that since 7.1 or so But yes, c++ ABI changes in gcc has been a huge problem. Anders
Anders Johansson
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
Philipp Thomas
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?"
Derek Fountain
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?
Yes, sorry for the confusion. The sentence should read: when passed the parameter -lGL will first search for a dynamic library named libGL.so and then for a static library named libGL.a.
Also, are you saying that the static linker will, as it's first option, look for a dynamic library, which it somehow links statically?
Again a bit confusion regarding the names. You normally have two linkers on a Linux machine. One is the dynamic linker (ld-linux.so.2 on a current system), whose task is to resolve dependencies *at runtime* by loading needed libraries into memory, locating the addresses of needed symbols (functions, variables etc.) and writing these addresses into special tables inside the binary that needs them. The other is the linker used when creating binaries. In contrast to the afore mentioned, this linker is sometimes called the static linker. This doesn't mean that it will link in everything static but only that it resolves dependencies statically at compile time and not dynamically at runtime. Is that a bit clearer? Philipp -- Philipp Thomas work: pthomas@suse.de Development SuSE Linux AG private: pth@t-link.de
participants (4)
-
Anders Johansson
-
Derek Fountain
-
Matthew Johnson
-
Philipp Thomas