Re: [PHP-DEV] GD Shared library confusion
As long as the configm4's use PHP_ADD_LIBRARY_WITH_PATH() and the other macros and don't touch LIBS themselves, there won't be any /usr/lib entries in it So, I'd check the la files There's propably libpspellla which has -L/usr/lib defined in 'dependency_libs=' And then you can complain to the libtool folks about this :) Easiest way to fix/test this is to just move all the la files from /usr/lib to some other place --Jani On Sat, 2 Mar 2002, Rasmus Lerdorf wrote: This is the problem /usr/lib shouldn't be here In your working build you won't see it Looks like ext/pspell/configm4 is the culprit -Rasmus -- -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
On Sun, Mar 03, 2002 at 06:16:07PM +0200, Jani Taskinen wrote : As long as the configm4's use PHP_ADD_LIBRARY_WITH_PATH() and the other macros and don't touch LIBS themselves, there won't be any /usr/lib entries in it So, I'd check the la files There's propably libpspellla which has -L/usr/lib defined in 'dependency_libs=' And then you can complain to the libtool folks about this :) Easiest way to fix/test this is to just move all the la files from /usr/lib to some other place Are you sure? On my system nearly all la files contain -L/usr/lib in the dependency_libs line $ grep dependency_libs /usr/lib/*la|grep -- '-L/usr/lib '|wc -l 138 Or am I missing some specific point? -- Please always Cc to me when replying to me on the lists GnuPG Key: http://gurujosefineat/~mfischer/C2272BD0asc -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
Libtool version? Not all have this problem --Jani On Sun, 3 Mar 2002, Markus Fischer wrote: On Sun, Mar 03, 2002 at 06:16:07PM +0200, Jani Taskinen wrote : As long as the configm4's use PHP_ADD_LIBRARY_WITH_PATH() and the other macros and don't touch LIBS themselves, there won't be any /usr/lib entries in it So, I'd check the la files There's propably libpspellla which has -L/usr/lib defined in 'dependency_libs=' And then you can complain to the libtool folks about this :) Easiest way to fix/test this is to just move all the la files from /usr/lib to some other place Are you sure? On my system nearly all la files contain -L/usr/lib in the dependency_libs line $ grep dependency_libs /usr/lib/*la|grep -- '-L/usr/lib '|wc -l 138 Or am I missing some specific point? -- -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
On Sun, Mar 03, 2002 at 06:37:53PM +0200, Jani Taskinen wrote : Libtool version? Not all have this problem $ libtool --version ltmainsh (GNU libtool) 14 (1920 2001/04/24 23:26:18) I think I lost discussion point somewhere now sorry -- Please always Cc to me when replying to me on the lists GnuPG Key: http://gurujosefineat/~mfischer/C2272BD0asc -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
Hmmit depends on so many things But the bug exists only in some 14x versions (including 14) --Jani On Sun, 3 Mar 2002, Markus Fischer wrote: On Sun, Mar 03, 2002 at 06:37:53PM +0200, Jani Taskinen wrote : Libtool version? Not all have this problem $ libtool --version ltmainsh (GNU libtool) 14 (1920 2001/04/24 23:26:18) I think I lost discussion point somewhere now sorry -- -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
ltmainsh (GNU libtool) 14 (1920 2001/04/24 23:26:18) And no, none of my /usr/lib/*pspell*la files have -L/usr/lib in their dependency_libs Lots of other la files in /usr/lib have that, but not pspell -Rasmus On Sun, 3 Mar 2002, Jani Taskinen wrote: Libtool version? Not all have this problem --Jani On Sun, 3 Mar 2002, Markus Fischer wrote: On Sun, Mar 03, 2002 at 06:16:07PM +0200, Jani Taskinen wrote : As long as the configm4's use PHP_ADD_LIBRARY_WITH_PATH() and the other macros and don't touch LIBS themselves, there won't be any /usr/lib entries in it So, I'd check the la files There's propably libpspellla which has -L/usr/lib defined in 'dependency_libs=' And then you can complain to the libtool folks about this :) Easiest way to fix/test this is to just move all the la files from /usr/lib to some other place Are you sure? On my system nearly all la files contain -L/usr/lib in the dependency_libs line $ grep dependency_libs /usr/lib/*la|grep -- '-L/usr/lib '|wc -l 138 Or am I missing some specific point? -- -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
[PHP-DEV] GD Shared library confusion
Ok, so the situation is this: --with-gd=/some/dir This will go through and do configure checks to figure out which version of GD live in /some/dir Say a static libgda built from gd-201 is sitting in there If the system also has a /usr/lib/libgdso then as of 420 the -lgd is picking up this shared library I suppose the only way around this is to use a full path to the static library in the link line instead of -lgd Does a full path library link work for a shared library as well? I didn't think it did This is going to cause all sorts of questions about GD in 42, I think -Rasmus -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
At 07:56 AM 3/2/2002 -0800, Rasmus Lerdorf wrote: Ok, so the situation is this: --with-gd=/some/dir This will go through and do configure checks to figure out which version of GD live in /some/dir Say a static libgda built from gd-201 is sitting in there If the system also has a /usr/lib/libgdso then as of 420 the -lgd is picking up this shared library I suppose the only way around this is to use a full path to the static library in the link line instead of -lgd Does a full path library link work for a shared library as well? I didn't think it did Nope it doesn't but you can use -L/path/to/shared_lib and then -lgd Andi This is going to cause all sorts of questions about GD in 42, I think -Rasmus -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
If the system also has a /usr/lib/libgdso then as of 420 the -lgd is picking up this shared library I suppose the only way around this is to use a full path to the static library in the link line instead of -lgd Does a full path library link work for a shared library as well? I didn't think it did Nope it doesn't but you can use -L/path/to/shared_lib and then -lgd I don't think a -L/path is going to override the LD_LIBRARY_PATH though for a shared library -Rasmus -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
At 08:03 AM 3/2/2002 -0800, Rasmus Lerdorf wrote: If the system also has a /usr/lib/libgdso then as of 420 the -lgd is picking up this shared library I suppose the only way around this is to use a full path to the static library in the link line instead of -lgd Does a full path library link work for a shared library as well? I didn't think it did Nope it doesn't but you can use -L/path/to/shared_lib and then -lgd I don't think a -L/path is going to override the LD_LIBRARY_PATH though for a shared library No it doesn't for loading I thought you were talking about the build itself I think there's a way to embed the actual LD_LIBRARY_PATH in the binary but I forgot how :) Andi -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
At 08:03 AM 3/2/2002 -0800, Rasmus Lerdorf wrote: If the system also has a /usr/lib/libgdso then as of 420 the -lgd is picking up this shared library I suppose the only way around this is to use a full path to the static library in the link line instead of -lgd Does a full path library link work for a shared library as well? I didn't think it did Nope it doesn't but you can use -L/path/to/shared_lib and then -lgd I don't think a -L/path is going to override the LD_LIBRARY_PATH though for a shared library No it doesn't for loading I thought you were talking about the build itself I think there's a way to embed the actual LD_LIBRARY_PATH in the binary but I forgot how :) You can with -R, but that doesn't solve this problem I don't want to remove /usr/lib from the link path The problem really is that when you give configure a path to some specific place for a static library, but you also have that library as a shared library in /usr/lib things get messy because we do the configure check against the located static library explicitly, but then we do a -L/specific/place -lgd which ends up linking in the different shared library from /usr/lib It isn't just for GD this happens, it just so happens to be more common for people to have two copies of GD -Rasmus -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
On Sat, 2 Mar 2002, Rasmus Lerdorf wrote: At 08:03 AM 3/2/2002 -0800, Rasmus Lerdorf wrote: If the system also has a /usr/lib/libgdso then as of 420 the -lgd is picking up this shared library I suppose the only way around this is to use a full path to the static library in the link line instead of -lgd Does a full path library link work for a shared library as well? I didn't think it did Nope it doesn't but you can use -L/path/to/shared_lib and then -lgd I don't think a -L/path is going to override the LD_LIBRARY_PATH though for a shared library No it doesn't for loading I thought you were talking about the build itself I think there's a way to embed the actual LD_LIBRARY_PATH in the binary but I forgot how :) You can with -R, but that doesn't solve this problem I don't want to remove /usr/lib from the link path The problem really is that when you give configure a path to some specific place for a static library, but you also have that library as a shared library in /usr/lib things get messy because we do the configure check against the located static library explicitly, but then we do a Actually, we check for both static and shared: for i in lib/gd13 lib/gd lib gd13 gd ; do test -f $j/$i/libgd$SHLIB_SUFFIX_NAME -o -f $j/$i/libgda GD_LIB=$j/$i done -L/specific/place -lgd which ends up linking in the different shared library from /usr/lib It isn't just for GD this happens, it just so happens to be more common for people to have two copies of GD What is the problem actually? I have two copies, one in /usr/lib and one in /www/gd-184/lib and I haven't noticed any problems --Jani -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
The problem really is that when you give configure a path to some specific place for a static library, but you also have that library as a shared library in /usr/lib things get messy because we do the configure check against the located static library explicitly, but then we do a Actually, we check for both static and shared: for i in lib/gd13 lib/gd lib gd13 gd ; do test -f $j/$i/libgd$SHLIB_SUFFIX_NAME -o -f $j/$i/libgda GD_LIB=$j/$i done Yes, we do, but I meant that if you do: --with-gd=/some/path And /some/path/libgda is there, and for the sake of this example assume there is no /some/path/libgdso We then do all the version checks against that static libgda library But on the final build we do: -L/some/path -lgd If /usr/lib/libgdso exists, as of 420 this will now be picked up In my paritcular case I had /usr/lib/libgdso being gd-184 and /some/path/libgda being gd-201 And it broke with an unresolved gdImageColorResolveAlpha symbol error when loading libphp4so -L/specific/place -lgd which ends up linking in the different shared library from /usr/lib It isn't just for GD this happens, it just so happens to be more common for people to have two copies of GD What is the problem actually? I have two copies, one in /usr/lib and one in /www/gd-184/lib and I haven't noticed any problems Sure, no problems if it is the same version of GD Normally when people have two copies they will not be the same version -Rasmus -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
Hrm Ok, so the problem isn't as clearcut as I thought A walkthrough: Install the gd-18x and gd-devel-18x packages on some common Linux distro I am using an old rh-71 box with a bunch of upgraded packages here Make sure it installs a /usr/lib/libgdso Then download gd-201targz from boutellcom and build it in /some/dir by changing GD's Makefile's LIBS line to: LIBS=libgda -lpng -lz -ljpeg -lfreetype -lm And type: make libgda to get the static library Now with a clean php-420-dev checkout do: /configure --with-gd=/home/rasmus/gd-201 --with-png-dir=/usr \ --with-zlib --with-freetype-dir=/usr --enable-gd-native-ttf \ --enable-gd-imgstrttf --with-jpeg-dir=/usr make /php -v and it *works* Weird also if I just add --with-apxs to the above it still works Running ldd on libphp4so at this point gives me: ~/php4 ldd libs/libphp4so libdlso2 = /lib/libdlso2 (0x40178000) libpamso0 = /lib/libpamso0 (0x4017c000) libpngso2 = /usr/lib/libpngso2 (0x40184000) libzso1 = /usr/lib/libzso1 (0x401a5000) libjpegso62 = /usr/lib/libjpegso62 (0x401b4000) libcryptso1 = /lib/libcryptso1 (0x401d3000) libresolvso2 = /lib/libresolvso2 (0x4020) libmso6 = /lib/libmso6 (0x40212000) libnslso1 = /lib/libnslso1 (0x40234000) libcso6 = /lib/libcso6 (0x4024b000) /lib/ld-linuxso2 = /lib/ld-linuxso2 (0x8000) The final link line for this working build was: /bin/sh /home/rasmus/php4/libtool --silent --mode=link gcc -I -I/home/rasmus/php4/ -I/home/rasmus/php4/main -I/home/rasmus/php4 -I/usr/include/apache -I/home/rasmus/php4/Zend -I/home/rasmus/gd-201/ -I/home/rasmus/php4/ext/mysql/libmysql -I/home/rasmus/php4/ext/xml/expat -DLINUX=22 -DEAPI -DEAPI_MM -DEAPI_MM_CORE_PATH=/var/run/httpdmm -I/home/rasmus/php4/TSRM -g -O2 -prefer-pic -o libphp4la -rpath /home/rasmus/php4/libs -avoid-version -L/home/rasmus/gd-201/ -R /home/rasmus/gd-201/ stublo Zend/libZendla sapi/apache/libsapila main/libmainla regex/libregexla /home/rasmus/php4/ext/zlib/libzlibla /home/rasmus/php4/ext/gd/libgdla /home/rasmus/php4/ext/mysql/libmysqlla /home/rasmus/php4/ext/overload/liboverloadla /home/rasmus/php4/ext/pcre/libpcrela /home/rasmus/php4/ext/posix/libposixla /home/rasmus/php4/ext/session/libsessionla /home/rasmus/php4/ext/standard/libstandardla /home/rasmus/php4/ext/xml/libxmlla TSRM/libtsrmla -lpam -lgd -lpng -lz -ljpeg -lz -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt -ldl Looks good We have a -L/home/rasmus/gd-201/ -R /home/rasmus/gd-201/ there Now, here comes the problem Try building using: /configure --with-pdflib=/usr/local --with-gd=/home/rasmus/gd-201 \ --with-jpeg-dir=/usr --with-freetype-dir=/usr \ --enable-gd-native-ttf' --enable-gd-imgstrttf \ --with-jpeg-dir=/usr --with-png-dir=/usr \ --with-xpm-dir=/usr/X11R6 --enable-exif \ --with-config-file-path=/etc --enable-debug \ --with-mysql=/usr --enable-inline-optimization \ --with-pgsql=/usr --with-zlib-dir=/usr \ --with-expat=/usr --enable-xslt --with-xslt-sablot=/usr \ --with-imap --with-gettext --with-kerberos --with-imap-ssl \ --with-mcrypt=/usr/local --with-ldap \ --with-pspell --with-apxs=/usr/sbin/apxs gives me: Cannot load /usr/lib/apache/libphp4so into server: /usr/lib/apache/libphp4so: undefined symbol: gdImageColorClosestAlpha And the ldd clearly shows that the wrong libgdso18 is now suddenly being pulled in What happened? Why did adding a bunch of other stuff suddenly switch me from using /home/rasmus/gd-201/libgda to using /usr/lib/libgdso18 ? ~/php4/libs ldd libphp4so libdlso2 = /lib/libdlso2 (0x4029f000) libpamso0 = /lib/libpamso0 (0x402a3000) libcryptoso2 = /lib/libcryptoso2 (0x402ab000) libsslso2 = /lib/libsslso2 (0x40382000) libsablotso0 = /usr/local/lib/libsablotso0 (0x403b3000) libexpatso0 = /usr/lib/libexpatso0 (0x4045f000) libpspellso4 = /usr/lib/libpspellso4 (0x4047d000) libpqso2 = /usr/lib/libpqso2 (0x40497000) libpdfso1 = /usr/local/lib/libpdfso1 (0x404a7000) libzso1 = /usr/lib/libzso1 (0x40532000) libpngso2 = /usr/lib/libpngso2 (0x40541000) libmcryptso4 = /usr/local/lib/libmcryptso4 (0x40562000) libltdlso3 = /usr/local/lib/libltdlso3 (0x40568000) libldapso2 = /usr/lib/libldapso2 (0x4056e000) liblberso2 = /usr/lib/liblberso2 (0x40597000) libcryptso1 = /lib/libcryptso1 (0x405a1000) libgdso18 = /usr/lib/libgdso18 (0x405cf000) libX11so6 = /usr/X11R6/lib/libX11so6 (0x40602000) libXpmso4 = /usr/X11R6/lib/libXpmso4 (0x406f8000) libjpegso62 = /usr/lib/libjpegso62 (0x40707000) libresolvso2 = /lib/libresolvso2 (0x40726000) libmso6 = /lib/libmso6 (0x40738000) libnslso1 = /lib/libnslso1 (0x4075b000) libgssapi_krb5so2 =
Re: [PHP-DEV] GD Shared library confusion
On Sat, 2 Mar 2002, Rasmus Lerdorf wrote: -L/usr/lib/gcc-lib/i386-redhat-linux/296/// -L/usr/lib/gcc-lib/i386-redhat-linux/296 -L/tmp/19246-i386/BUILD/pspell-122/modules/libs -L/usr/lib This is the problem /usr/lib shouldn't be here In your working build you won't see it So, there are 2 possibilities that come to my mind: 1 Some configm4 adds /usr/lib into the LIBS 2 You have some la file somewhere which has it in it and which is used during linking (I had to move all la files out of /usr/lib when we started using libtool 14) --Jani -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] GD Shared library confusion
This is the problem /usr/lib shouldn't be here In your working build you won't see it Looks like ext/pspell/configm4 is the culprit -Rasmus -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
