Re: migrating to 64 bit

Robert Schaefer wrote:
> Hi,
Aloha
>   I am migrating open source packages from redhat EL5 on 32 bit
> machines to 64 bit machines.
>   I found a problem with some packages that now need the -m32 flag
> passed into gcc for
>   the executable to work properly.
Okay, so you are trying to build target 32 bit executables under a 64
bit host ?
>
>   w3c-libwww appears to not have the -m32 flag, and the linker, ld
> complains when I link to it with  a mix
>   of files some built to run in 32 bit mode and some built 64 bit.
Were you trying something like,

  $ CFLAGS="-m32"  ./configure --target=i686

If so, where did it fail ?

>   Is there a way to configure  w3c-libwww for the 32 bit mode on a 64
> bit box?

For some reason, it seems to drop the compiler flag when generating the
modules/expat/libtool . . .

However, going back in and adding the compiler flag after running
configure and before running make seems to work.

For example, the difference would be something like,

  $ diff modules/expat/libtool modules/expat/libtool-generated
  1042c1042
  <     compiler_flags=-m32
  ---
  >     compiler_flags=

This way, there is are 32 bit shared libraries, e.g.,

  $ file modules/expat/.libs/libexpat.so.0.4.0
  modules/expat/.libs/libexpat.so.0.4.0: ELF 32-bit LSB shared object,
Intel 80386, version 1 (SYSV), dynamically linked, not stripped

The example applications are also 32 bit, e.g.,

  $ file LineMode/src/www
  LineMode/src/www: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
stripped

At first glance however, I do not see where the '-m32' falls off on the
way down into expat's libtool generation . . .

more,
l8r,
v

-- 
"The future is here. It's just not evenly distributed yet."
 -- William Gibson, quoted by Whitfield Diffie

Received on Wednesday, 15 December 2010 04:19:19 UTC