You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Ruediger Pluem <rp...@apache.org> on 2007/01/08 21:38:02 UTC
[Fwd: DO NOT REPLY [Bug 28205] - expat detection broken on lib64
platforms]
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.
Regards
Rüdiger
Re: [Fwd: DO NOT REPLY [Bug 28205] - expat detection broken on lib64 platforms]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 1/11/07, Ruediger Pluem <rp...@apache.org> wrote:
> If my assumptions above are true, is this a bug of libtool or do we need to fix anything
> within apr?
Just for giggles, how well does --enable-experimental-libtool (i.e.
jlibtool) handle this scenario? -- justin
Re: [Fwd: DO NOT REPLY [Bug 28205] - expat detection broken on lib64
platforms]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
> On 01/12/2007 12:25 PM, Joe Orton wrote:
>>
>> The only correct way to change the compiler ABI choice is to use e.g.:
>>
>> CC="gcc -m32"
>
> Thanks for the hint. Now I am able to compile the 32 bit version with
> your patch and the configuration above (minus -m32 in the CFLAGS).
Joe - thank you for this incredibly useful pointer. You've restored some
of my sanity and faith in solving unix nightmares :)
Re: [Fwd: DO NOT REPLY [Bug 28205] - expat detection broken on lib64
platforms]
Posted by Ruediger Pluem <rp...@apache.org>.
On 01/12/2007 12:25 PM, Joe Orton wrote:
> On Fri, Jan 12, 2007 at 12:08:18AM +0100, Ruediger Pluem wrote:
>
>
>>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
>
>
> The only correct way to change the compiler ABI choice is to use e.g.:
>
> CC="gcc -m32"
Thanks for the hint. Now I am able to compile the 32 bit version with
your patch and the configuration above (minus -m32 in the CFLAGS).
Regards
Rüdiger
Re: [Fwd: DO NOT REPLY [Bug 28205] - expat detection broken on lib64 platforms]
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Jan 12, 2007 at 12:08:18AM +0100, Ruediger Pluem wrote:
> On 01/08/2007 09:38 PM, Ruediger Pluem wrote:
> > 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.
Thanks for testing this out!
> 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
The only correct way to change the compiler ABI choice is to use e.g.:
CC="gcc -m32"
since there are places (as you note) where $CC will be used without
LDFLAGS or CFLAGS.
Regards,
joe
Re: [Fwd: DO NOT REPLY [Bug 28205] - expat detection broken on lib64
platforms]
Posted by Ruediger Pluem <rp...@apache.org>.
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 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