On my linux 64-bit system with 8.72 libraries installed in /usr/lib64, when I do a "make so" it causes the build system to produce "libgs.so.9.00" alongside binaries that are linked to "libgs.so.8". If libgs.so.9.00 is installed and ldconfig is run prior to re-running make so, the correct binaries linked to libgs.so.9 will be produced. This will cause trouble for anyone upgrading from 8.xx to 9.xx, as they will get binaries that will continue to use the old library when they attempt to build a 9.00-shared lib version.
Have you looked *after* "make soinstall"? It should link libgs.so to libgs.so.9 . I don't think there is a bug here - after 'make so' and 'before make soinstall', ldd would show the new binaries as linked to libgs.so.8 (in the system directory) without any LD_LIBRARY_* trickery, but that's temporary and all should be fine when you get to 'make soinstall'.
Yes, make soinstall does not change the fact that the gsc and gsx produced are linked explicitly to libgs.so.8 You can see libgs.so.8 as a string literal in the binary file. make soinstall does not change that. The only way to get correct gsc/gsx binaries would be to do the following: make so make soinstall make soclean make so make soinstall
To be clear, when I said linked above, I mean dynamically linked in the programming sense. They get linked to (the installed) libgs.so.X rather than libgs.so, so it doesn't matter that soinstall is going to fix up the libgs.so symbolic link, they don't use it anyway.
(In reply to comment #2) > Yes, make soinstall does not change the fact that the gsc and gsx produced are > linked explicitly to libgs.so.8 > > You can see libgs.so.8 as a string literal in the binary file. make soinstall > does not change that. That's not the case here - I actually just tried 'make so' (r11620) myself this morning and right after, ldd on sobin/gsc and sobin/gsx shows they are linked to libgs.so.9 and => not found . (which is expected, before soinstall). So I am inclined to think there is something wrong or strange with your system.
Could I ask what the contents of your /usr/lib or /usr/lib64 directory were in terms of libgs prior to make so?
(In reply to comment #5) > Could I ask what the contents of your /usr/lib or /usr/lib64 directory were in > terms of libgs prior to make so? I have a fairly standard fedora 13 x86_64 (nothing installed outside of rpm/yum). $ ls -l /usr/lib*/libgs.* lrwxrwxrwx. 1 root root 13 Aug 11 19:54 /usr/lib64/libgs.so -> libgs.so.8.71 lrwxrwxrwx. 1 root root 13 Aug 11 15:33 /usr/lib64/libgs.so.8 -> libgs.so.8.71 -rwxr-xr-x. 1 root root 8074728 Mar 16 15:19 /usr/lib64/libgs.so.8.71 lrwxrwxrwx. 1 root root 13 Aug 11 19:53 /usr/lib/libgs.so -> libgs.so.8.71 lrwxrwxrwx. 1 root root 13 Aug 11 15:34 /usr/lib/libgs.so.8 -> libgs.so.8.71 -rwxr-xr-x. 1 root root 7096156 Mar 16 15:20 /usr/lib/libgs.so.8.71
I get the same results as Hin-Tak: with the current trunk head revision I get executables linked against libgs.so.9 despite having libgs.so.8.70 installed in /usr/lib (this is on my 32 bit system). I believe the current behaviour is correct.