Hello, first of all many thanks to the four Persons who replied: Thomas Anders, Casper Dik, Darren Dunham and Nick Hindley. Secondly the solutions: The main answer is to compile on the lowest Solaris version you support. If this is not an option, read further, please. After some more investigation I've noticed that my original message was unprecise not noting the difference between internal and external versioning. My original problem concerns both, not only external versioning as described in the original mail. - External versioning is versioning by different file names. Note, that the reference to a shared library the linker puts in an executable is neither the name of the shared library link nor the name of the actual lib the link points to, but the name that has been written into the shared lib by the "-h" option of "ld", if any. Because you can't recompile the libraries of Solaris, there's no way to change this string. This is why "-lposix4" will put a reference to "librt.so.1" into your executable if compiled under Solaris 7 or 8. So the application won't run under Solaris 2.6. There is a workaround: Link "libposix4.so" to "librt.so.1". But that's not guaranteed to work... - Even libraries with the same name on different Solaris versions can implement different interface versions. This is called "internal versioning". Which interface versions are supported, can be seen doing a "pvs -dsv libname". Normally, ld records the version name of the smallest interface needed to the executable. You can, however, disable internal versioning e.g. with the linking option "-z noversion". Alternatively, you can exactly specify which interface version to record by a so called mapfile. This, too, seems not to be guaranteed to work... For further information see the "Linker and Libraries Guide" in "Sun Software Developer Collection", e.g. online at <http://docs.sun.com/>. Greetings, Philipp Bachmann. Original message was: > my problem is, that when building dynamic executables the Solaris linker > records shared libraries not by the name given by the "-l" command line > argument, but with the name recorded inside the shared libraries' dynamic > section using ld's "-h" option (e.g. if linked with "-lXm" under Solaris 8 > SPARC the library reference points to "libXm.so.4", not to "libXm.so"). > This, I know, is due to versioning effords. Using such binaries even under > Solaris 7 is impossible - ld.so.1 won't find the lib, because there's only > an older version of it. Is there a standard way to build one executable > for different Solaris versions, i.e. forcing the linker to drop any file > name extension when writing the dynamic section? Does perhaps the usage of > GNU ld (from the binutils) with its "linker scripts" represent a solution? > O.K., the drawback will be that versioning by the file names of the shared > objects won't work this way. -- Philipp Bachmann <bachlipp@uni-freiburg.de> +49 7621 424542Received on Thu May 10 13:02:57 2001
This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:24:54 EDT