bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Building 32 bits binaries in Linux 64


From: SplinterGU (gmail)
Subject: Building 32 bits binaries in Linux 64
Date: Mon, 24 Nov 2008 10:33:00 -0200
User-agent: Thunderbird 2.0.0.17 (X11/20080925)

Hi! I've this bug with libtool in Ubuntu64 (8.10)... I search info in internet and I found other guy with the same error... I copy & past this text here, because my english is bad... my project is own project but it compile in other linux32 without problem...

link: http://mail-archives.apache.org/mod_mbox/apr-dev/200701.mbox/address@hidden

---------------- from here -----------------

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 address@hidden  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

----- to here -----

thanks...










reply via email to

[Prev in Thread] Current Thread [Next in Thread]