Building 32 bits binaries in Linux 64

[SplinterGU (gmail)]

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...