CentOS - Nov 2009 - 32bit development on x86-64

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

-- 
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells at saic.com

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
>