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 [EMAIL PROTECTED] 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 the 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? Regards Rüdiger
