app programming on freebsd amd64

[bruce at cran.org.uk]

On Thu, Jul 31, 2008 at 05:17:14PM -0700, Nate Eldredge wrote:
> It's not really missing completely though.  Just that gcc isn't set up to 
> look for it in the right place.
> 
> [...] 
>
> 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 at 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 at 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 at 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.
>

I don't know if it works for more complex programs, but passing
-B/usr/lib32 to gcc certainly works for simple apps - it searches 
there for the libraries before falling back to the standard locations if
it can't find them there.

-- 
Bruce Cran