apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: [Fwd: DO NOT REPLY [Bug 28205] - expat detection broken on lib64 platforms]
Date Thu, 11 Jan 2007 23:08:18 GMT

On 01/08/2007 09:38 PM, Ruediger Pluem wrote:
> Sorry missed Joe's comment that test results should be posted to dev.
> ------- Additional Comments From rpluem@apache.org  2007-01-08 12:35 -------
> Created an attachment (id=19375)
>  --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19375&action=view)
> Backport to 1.2.8 based on r493791
> Based on r493791 by Joe I created the attached patch which smoothly applies to
> apr-util 1.2.8. I tested this patch successfully with the following
> environments:
> SuSE 8.1 32 bit with libexpat installed in /usr/lib
> SuSE 10.1 64 bit with libexpat installed in /usr/lib (32 bit) and /usr/lib64
> (64 bit) and a 64 bit build.

I noticed that the following situation does not work as expected:

- 64 bit Linux system (SuSE 10.1 in my case)
- 32 bit and 64 bit versions of libexpat installed with libexpat.la present
  in /usr/lib and /usr/lib64
- CFLAGS contain -m32 to create a 32 bit build on a 64 bit system

In this case the build of apr-util fails as it tries to link against /usr/lib64/libexpat.so
I guess this is caused by libtool. As far as I understand libtool

sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | sed -e "s/^libraries://"
-e "s/;/ /g"`

it searches above path for the appropriate .la files. If it finds one it uses the information
found there for linking (instead of -lsomething).
On the 64 bit system the 64 bit library pathes are located *before* the 32 bit library pathes.
Thus libtool picks up the libexpat.la file from the 64 bit directory.
Why doesn't this fail during the configure test?
I guess because in the test case linking is done without libtool and
I guess the compiler and the linker silently ignore 64 bit libraries as they walk through
search-dirs if -m32 is set. So they finally reach the 32 bit dirs and pick up the correct
.so file.

If my assumptions above are true, is this a bug of libtool or do we need to fix anything
within apr?



View raw message