[CentOS] 32bit development on x86-64

Wed Nov 11 13:52:59 UTC 2009
Juergen Gotteswinter <jg at internetx.de>

perhaps linux32 helps you out

man linux32

greetings

Juergen

Roger K. Wells wrote:
> We develop software and are beginning a slow transition from 32 bit 
> applications
> to their 64 bit equivalents.  During this period it will be necessary to 
> build
> programs targeted for both environments using the x86-64 machines for 
> development.
> 
> here is a simple/small "application", sizes.c:
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(int argc, char **argv)
> {
>     printf("Various sizes:\n");
>     printf("    short                    = %d\n", sizeof(short));
>     printf("    int                      = %d\n", sizeof(int));
>     printf("    long                     = %d\n", sizeof(long));
>     printf("    float                    = %d\n", sizeof(float));
>     printf("    double                   = %d\n", sizeof(double));
>     return 0;
> }
> 
> if I build it using:
> 
> gcc -m32 -Wall -osizes sizes.c
> 
> there are no warnings or complaints and a functioning 32 bit
> program runs, giving the size of a long as 4 bytes. (Of course
> without the m32 flag the size of long is 8 bytes.)
> 
> if I try to do the equivalent in two steps:
> 
> gcc -c -m32 -Wall sizes.c
> gcc -osizes -Wl,-m,elf_i386 sizes.o
> 
> the result is:
> /usr/bin/ld: skipping incompatible 
> /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc.a when searching for -lgcc
> /usr/bin/ld: skipping incompatible 
> /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc.a when searching for -lgcc
> /usr/bin/ld: cannot find -lgcc
> collect2: ld returned 1 exit status
> 
> there is some confusion in the man pages as to whether the correct 32 
> bit emulation is elf_i386 or i386linux so:
> 
> gcc -osizes -Wl,-m,i386linux sizes.o
> gives result:
> /usr/bin/ld: unrecognized option '--eh-frame-hdr'
> /usr/bin/ld: use the --help option for usage information
> collect2: ld returned 1 exit status
> 
> since the single line command works it seems that there must be a way to 
> get the job done.
> This becomes important when there are many source files and use of a 
> traditional
> makefile is involved where compiling and linking are separate steps.
> 
> Thanks in advance for reading this,
> roger wells
>