Opened 13 years ago

Closed 12 years ago

#13 closed defect (fixed)

libtool and -m32

Reported by: asm4 Owned by: andreasw
Priority: minor Component: component1
Version: Keywords: libtool, -m32
Cc: asm4@…

Description

on a 64 bit machine (Debian), if one compiles with -m32 option, make throws out errors like:

/usr/bin/ld: skipping incompatible /usr/bin/../lib/libm.so when searching for -lm

/usr/bin/ld: skipping incompatible /usr/bin/../lib/libm.a when searching for -lm

/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm

/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm

/usr/bin/ld: cannot find -l

the libraries libm.so, libm.so ... are located in /lib32 instead of /lib. Setting LD_LIBRARY_PATH does not seem to help.

Change History (7)

comment:1 Changed 13 years ago by andreasw

  • Owner changed from somebody to andreasw
  • Priority changed from major to minor
  • Status changed from new to assigned

I'm aware of this problem. This is a bug in libtool. It will require modifications of the automatically generated libtool script by configure to fix this problem. Will try to get to this at some point.

comment:2 Changed 13 years ago by asm4

After updating my operating system, specifically packages libc6-dev-i386 ia32-libs (on a debian IA64), the code compiles perfectly OK. So I believe, this was more a problem of the system and library paths than any bug in Coin packages. Sorry for the trouble. This ticket should probably be closed.

Just for reference, in order to avoid the above problem:

If using -m32 flag on a 64 bit machine, make sure 32-bit libraries and 32-bit devel. packages are installed.

More specifically, /sbin/ldconfig -p | grep libm.so should reveal a 32-bit library (something like: libm.so (libc6, OS ABI: Linux 2.6.0) => /usr/lib32/libm.so) and 32-bit versions crt1.o crti.o etc should be available (in /usr/lib32 or a similar location).

comment:3 Changed 13 years ago by andreasw

It seems to me that it is quite involved to fix this. Hopefully, there will be a new version of libtool soon which will handle this correctly.

comment:4 Changed 13 years ago by lou

On the Solaris systems I use, it turns out that LD_LIBRARY_PATH and LD_LIBRARY_PATH32 are used for 32-bit builds, and I need LD_LIBRARY_PATH64 for 64-bit builds. Libtool could probably diagnose the problem, but it'd be a stretch to fix it. At least for Solaris, it really is a system and library path issue.

comment:5 Changed 13 years ago by lou

Just to follow up on this for Solaris, it turns out that when both of LD_LIBRARY_PATH and LD_LIBRARY_PATH32 are set, PATH32 overrides plain PATH. This causes (for example) 'make test' to fail when it tries to run the unitTest. That's because unitTest is actually a shell script courtesy of libtool which tries to assemble a binary on-the-fly. The script modifies PATH, but not PATH32, and then fails because it can't find any of the hidden 'libtoolized' binaries. Unsetting PATH32 cures the problem.

comment:6 Changed 13 years ago by andreasw

I now added a fix of the generated libtool script, so that one can use -m32 on x86_64. Other platforms will probably still fail, but we might be able to find a similar corrections.

The problem is (at least for -m32 on x86_84) that libtool sets sys_lib_search_path_spec incorrectly. If the GNU compiler is used, it gets the value from gcc -print-search-dirs, which doesn't give the correct values for compilation with the -m32 flag.

I keep the ticket open in case the problem occures on other systems.

Hopefully they bring out a new version of libtool soon, that has this fixed.

comment:7 Changed 12 years ago by andreasw

  • Resolution set to fixed
  • Status changed from assigned to closed

Close ticket, nothing seems to have come up.

Note: See TracTickets for help on using tickets.