Date: Thu, 31 Jul 2008 17:17:14 -0700 (PDT) From: Nate Eldredge <nge@cs.hmc.edu> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-amd64@freebsd.org Subject: Re: app programming on freebsd amd64 Message-ID: <Pine.LNX.4.64.0807311703260.1277@knuth.cs.hmc.edu> In-Reply-To: <20080731234107.GA99946@troutmask.apl.washington.edu> References: <4891F3F3.8090608@telenix.org> <20080731195527.GT1359@server.vk2pj.dyndns.org> <489243B0.80307@telenix.org> <20080731234107.GA99946@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Jul 2008, Steve Kargl wrote:
> On Thu, Jul 31, 2008 at 06:58:56PM -0400, Chuck Robey wrote:
>> Peter Jeremy wrote:
>>>
>>> There are a couple of open PRs about this but fixing it is non-trivial.
>>>
>>> Your only current option is to install an i386 world (as well as your
>>> amd64 world) and chroot into it to build i386 apps.
>>
>> Oh, you're telling me that if I run one app as 32 bit (compiling it, the whole
>> enchilada, as 32 bit) would only work if I had the OS, kernel and all libs, as
>> 32 bits? I couldn't just run the X11 as 32 bits? I mean, not only run it as 32
>> bits, also compile it as 32 bits? If I did that, it would use the OS and libs
>> as 64 bits, and be therefore incorrect?
>>
>> If that's so, it does throw a wrench into things, forcing another set of
>> decisions on me, so I need a confirmation, you'll understand.
>
> He's telling you that -m32 doesn't work because the necessary
> run time support is missing.
It's not really missing completely though. Just that gcc isn't set up to
look for it in the right place.
>
> troutmask:kargl[202] cat h.c
> #include <stdio.h>
> int main(void)
> {
> printf("Hello world!\n");
> return 0;
> }
> troutmask:kargl[203] cc -o z h.c
> troutmask:kargl[205] ldd z
> z:
> libc.so.7 => /lib/libc.so.7 (0x20063c000)
> troutmask:kargl[206] file z
> z: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), for FreeBSD 8.0 (800040), dynamically linked (uses shared libs), FreeBSD-style, not stripped
> troutmask:kargl[207] cc -o z -m32 h.c
> /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc
> /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc
> /usr/bin/ld: cannot find -lgcc
nate@vulcan:/tmp$ gcc -c -m32 h.c
nate@vulcan:/tmp$ gcc -v -o h -m32 h.o
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719 [FreeBSD]
/usr/bin/ld --eh-frame-hdr -m elf_i386_fbsd -V -dynamic-linker
/libexec/ld-elf.so.1 -o h /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/crtbegin.o -L/usr/local/lib -L/usr/local/lib -L/usr/lib
-L/usr/lib h.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
GNU ld version 2.15 [FreeBSD] 2004-05-23
Supported emulations:
elf_i386_fbsd
elf_x86_64_fbsd
/usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for
-lgcc
/usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for
-lgcc
/usr/bin/ld: cannot find -lgcc
So it's still looking for things in /usr/lib when it should use
/usr/lib32. We can call ld directly and give it the right things:
nate@vulcan:/tmp$ /usr/bin/ld --eh-frame-hdr -m elf_i386_fbsd -V -dynamic-linker /libexec/ld-elf32.so.1 -o h /usr/lib32/crt1.o /usr/lib32/crti.o /usr/lib32/crtbegin.o -L/usr/lib32 h.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib32/crtend.o /usr/lib32/crtn.o
GNU ld version 2.15 [FreeBSD] 2004-05-23
Supported emulations:
elf_i386_fbsd
elf_x86_64_fbsd
nate@vulcan:/tmp$ file ./h
./h: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for
FreeBSD 7.0 (700055), dynamically linked (uses shared libs),
FreeBSD-style, not stripped
nate@vulcan:/tmp$ ./h
Hello world!
It might be that there is some set of options to gcc itself that would
make the right thing happen here without calling ld directly. More likely
someone would have to write a new specs file. But that's a relatively
minor issue; the guts are there.
Now it may be that the 32-bit runtime has bugs that would appear if we
tried to do something more complicated. But it isn't totally absent.
--
Nate Eldredge
nge@cs.hmc.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.64.0807311703260.1277>