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