Re: [PHP-DEV] GD Shared library confusion

[Rasmus Lerdorf]

ltmain.sh (GNU libtool) 1.4 (1.920 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 config.m4'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 libpspell.la
> >> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Jani Taskinen]

Hmm..it depends on so many things. But the bug
exists only in some 1.4.x versions (including 1.4).

--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
>ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18)
>
>
>I think I lost discussion point somewhere now .. sorry
>
>

-- 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Markus Fischer]

On Sun, Mar 03, 2002 at 06:37:53PM +0200, Jani Taskinen wrote : 
> 
> Libtool version? Not all have this problem..

$ libtool --version
ltmain.sh (GNU libtool) 1.4 (1.920 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://guru.josefine.at/~mfischer/C2272BD0.asc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Jani Taskinen]

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 config.m4'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 libpspell.la
>> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Markus Fischer]

On Sun, Mar 03, 2002 at 06:16:07PM +0200, Jani Taskinen wrote : 
> 
> As long as the config.m4'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 libpspell.la
> 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://guru.josefine.at/~mfischer/C2272BD0.asc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Jani Taskinen]

As long as the config.m4'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 libpspell.la
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/config.m4 is the culprit.
>
>-Rasmus
>
>
>

-- 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Rasmus Lerdorf]

> This is the problem. /usr/lib shouldn't be here.
> In your working build you won't see it.

Looks like ext/pspell/config.m4 is the culprit.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Jani Taskinen]

On Sat, 2 Mar 2002, Rasmus Lerdorf wrote:

>-L/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../..
>-L/usr/lib/gcc-lib/i386-redhat-linux/2.96
>-L/tmp/19246-i386/BUILD/pspell-.12.2/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 config.m4 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 1.4)

--Jani



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Rasmus Lerdorf]

Hrm.. Ok, so the problem isn't as clearcut as I thought.  A walkthrough:

Install the gd-1.8.x and gd-devel-1.8.x packages on some common Linux
distro.  I am using an old rh-7.1 box with a bunch of upgraded packages
here.  Make sure it installs a /usr/lib/libgd.so

Then download gd-2.0.1.tar.gz from boutell.com and build it in /some/dir
by changing GD's Makefile's LIBS line to:

LIBS=libgd.a -lpng -lz -ljpeg -lfreetype -lm

And type:

make libgd.a

to get the static library.

Now with a clean php-4.2.0-dev checkout do:

./configure --with-gd=/home/rasmus/gd-2.0.1 --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 libphp4.so at this point gives me:

~/php4> ldd .libs/libphp4.so
libdl.so.2 => /lib/libdl.so.2 (0x40178000)
libpam.so.0 => /lib/libpam.so.0 (0x4017c000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40184000)
libz.so.1 => /usr/lib/libz.so.1 (0x401a5000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x401b4000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x401d3000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4020)
libm.so.6 => /lib/libm.so.6 (0x40212000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40234000)
libc.so.6 => /lib/libc.so.6 (0x4024b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (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-2.0.1/
-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/httpd.mm
-I/home/rasmus/php4/TSRM -g -O2 -prefer-pic   -o libphp4.la -rpath
/home/rasmus/php4/libs -avoid-version -L/home/rasmus/gd-2.0.1/  -R
/home/rasmus/gd-2.0.1/ stub.lo  Zend/libZend.la sapi/apache/libsapi.la
main/libmain.la regex/libregex.la /home/rasmus/php4/ext/zlib/libzlib.la
/home/rasmus/php4/ext/gd/libgd.la /home/rasmus/php4/ext/mysql/libmysql.la
/home/rasmus/php4/ext/overload/liboverload.la
/home/rasmus/php4/ext/pcre/libpcre.la
/home/rasmus/php4/ext/posix/libposix.la
/home/rasmus/php4/ext/session/libsession.la
/home/rasmus/php4/ext/standard/libstandard.la
/home/rasmus/php4/ext/xml/libxml.la TSRM/libtsrm.la -lpam -lgd -lpng -lz
-ljpeg -lz -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt -ldl

Looks good.  We have a -L/home/rasmus/gd-2.0.1/  -R /home/rasmus/gd-2.0.1/
there.

Now, here comes the problem.  Try building using:

./configure --with-pdflib=/usr/local --with-gd=/home/rasmus/gd-2.0.1 \
--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/libphp4.so into server:
/usr/lib/apache/libphp4.so: undefined symbol: gdImageColorClosestAlpha

And the ldd clearly shows that the wrong libgd.so.1.8 is now suddenly
being pulled in.  What happened?  Why did adding a bunch of other stuff
suddenly switch me from using /home/rasmus/gd-2.0.1/libgd.a to using
/usr/lib/libgd.so.1.8 ?

~/php4/.libs> ldd libphp4.so
libdl.so.2 => /lib/libdl.so.2 (0x4029f000)
libpam.so.0 => /lib/libpam.so.0 (0x402a3000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x402ab000)
libssl.so.2 => /lib/libssl.so.2 (0x40382000)
libsablot.so.0 => /usr/local/lib/libsablot.so.0 (0x403b3000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4045f000)
libpspell.so.4 => /usr/lib/libpspell.so.4 (0x4047d000)
libpq.so.2 => /usr/lib/libpq.so.2 (0x40497000)
libpdf.so.1 => /usr/local/lib/libpdf.so.1 (0x404a7000)
libz.so.1 => /usr/lib/libz.so.1 (0x40532000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40541000)
libmcrypt.so.4 => /usr/local/lib/libmcrypt.so.4 (0x40562000)
libltdl.so.3 => /usr/local/lib/libltdl.so.3 (0x40568000)
libldap.so.2 => /usr/lib/libldap.so.2 (0x4056e000)
liblber.so.2 => /usr/lib/liblber.so.2 (0x40597000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x405a1000)
libgd.so.1.8 => /usr/lib/libgd.so.1.8 (0x405cf000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40602000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x406f8000)
li

Re: [PHP-DEV] GD Shared library confusion

[Rasmus Lerdorf]

> >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/gd1.3 lib/gd lib gd1.3 gd ""; do
>test -f $j/$i/libgd.$SHLIB_SUFFIX_NAME -o -f $j/$i/libgd.a && GD_LIB=$j/$i
> done

Yes, we do, but I meant that if you do:

  --with-gd=/some/path

And /some/path/libgd.a is there, and for the sake of this example assume
there is no /some/path/libgd.so.  We then do all the version checks
against that static libgd.a library.  But on the final build we do:

  -L/some/path -lgd

If /usr/lib/libgd.so exists, as of 4.2.0 this will now be picked up.  In
my paritcular case I had /usr/lib/libgd.so being gd-1.8.4 and
/some/path/libgd.a being gd-2.0.1.  And it broke with an unresolved
gdImageColorResolveAlpha symbol error when loading libphp4.so

> >-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-1.8.4/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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Jani Taskinen]

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/libgd.so then as of 4.2.0 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/gd1.3 lib/gd lib gd1.3 gd ""; do
   test -f $j/$i/libgd.$SHLIB_SUFFIX_NAME -o -f $j/$i/libgd.a && 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-1.8.4/lib and I haven't noticed any problems..

--Jani



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Rasmus Lerdorf]

> At 08:03 AM 3/2/2002 -0800, Rasmus Lerdorf wrote:
> > > >If the system also has a /usr/lib/libgd.so then as of 4.2.0 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Andi Gutmans]

At 08:03 AM 3/2/2002 -0800, Rasmus Lerdorf wrote:
> > >If the system also has a /usr/lib/libgd.so then as of 4.2.0 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Rasmus Lerdorf]

> >If the system also has a /usr/lib/libgd.so then as of 4.2.0 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD Shared library confusion

[Andi Gutmans]

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 libgd.a built from gd-2.0.1 is
>sitting in there.
>
>If the system also has a /usr/lib/libgd.so then as of 4.2.0 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 4.2, I think.
>
>-Rasmus
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] GD Shared library confusion

[Rasmus Lerdorf]

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 libgd.a built from gd-2.0.1 is
sitting in there.

If the system also has a /usr/lib/libgd.so then as of 4.2.0 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 4.2, I think.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php