Docs for running 32-bit apps?
con...@cox.net
under amd64, and if so, where they might be found?
Thanks.
--
Conrad J. Sabatier <con...@cox.net> -- "In Unix veritas"
Tommi Lätti
> Anyone know if there's any documentation anywhere re: how to run 32-bit apps
> under amd64, and if so, where they might be found?
You should be able to 'just run them', if you have the lib32 installed
in your system.
--snip--
$ cat /usr/src/tools/lib32/README
# $FreeBSD: src/tools/lib32/README,v 1.2 2004/11/25 04:25:21 peter Exp $
Set WITH_LIB32=yes in /etc/make.conf and do a buildworld/installworld.
Alternatively, if you have just done a buildworld/installworld, you
might be able to 'make build32' and 'make install32' in the top of the
/usr/src tree.
--snip--
--
br,
Tommi
Kael Fischer
Running 6.0-Release amd64 on new Intel SBX82 blades. The vendor
delivered these without overriding lib32 and it was present in the
build tree but, strangely not installed. Applications complained that
ld-elf32.so.1 wasn't there.
% cd /usr/src; make install32
'Fixed' that error, but now I get this kind of thing:
/usr/libexec/ld-elf.so.1: Shared object "libm.so.2" not found, ...
or
/usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.3" not found, ...
Am I missing some big part of the puzzle? I am coming from a mostly
FreeBSD 4.X environment and libmap.conf (5) is a new idea, so maybe
that is it. /etc/libmap.conf doesn't exist on these systems. But I
thought this was 'just supposed to work.'
Rgds,
Kael
--
Kael Fischer, Ph.D
DeRisi Lab - Univ. Of California San Francisco
Steve Kargl
>
> 'Fixed' that error, but now I get this kind of thing:
>
> /usr/libexec/ld-elf.so.1: Shared object "libm.so.2" not found, ...
> or
> /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.3" not found, ...
>
> Am I missing some big part of the puzzle? I am coming from a mostly
> FreeBSD 4.X environment and libmap.conf (5) is a new idea, so maybe
> that is it. /etc/libmap.conf doesn't exist on these systems. But I
> thought this was 'just supposed to work.'
>
What does "ldconfig -32 -r" show? You probably need to
do "ldconfig -32 /usr/lib32".
--
Steve
Kael Fischer
Thanks, I forgot to mention that I had already tried that. Doing it
again does not fix it. But perhaps the first error message is
significant? Is there something that loads at boot time?
b1# ldconfig -32 -r
ldconfig: Cannot open "/var/run/ld-elf32.so.hints": No such file or directory
b1# ldconfig -32 /usr/lib32
b1# ~kael/src/pdbanal/raftercc
/usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.3" not found,
required by "raftercc"
b1# ~kael/src/wublast/freebsd-i686/blasta
/usr/libexec/ld-elf.so.1: Shared object "libm.so.2" not found,
required by "blasta"
-Kael
Steve Kargl
>
> Thanks, I forgot to mention that I had already tried that. Doing it
> again does not fix it. But perhaps the first error message is
> significant? Is there something that loads at boot time?
>
> b1# ldconfig -32 -r
> ldconfig: Cannot open "/var/run/ld-elf32.so.hints": No such file or directory
> b1# ldconfig -32 /usr/lib32
Do you have libstdc++.so.3 and libm.so.2 in /usr/lib32?
Does ldconfig -32 -r show a list of files.
> b1# ~kael/src/pdbanal/raftercc
> /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.3" not found,
> required by "raftercc"
> b1# ~kael/src/wublast/freebsd-i686/blasta
> /usr/libexec/ld-elf.so.1: Shared object "libm.so.2" not found,
> required by "blasta"
If you can't recompile raftercc and blasta for amd64, then try
to find the missing 32bit libs and drop them im /usr/lib32.
You could create a symlink to get libm.so.2 (although I don't
recommend this approach). A symlink probably won't work for
libstdc++.co.3 because the C++ ABI changed.
--
Steve
Kael Fischer
>
> Do you have libstdc++.so.3 and libm.so.2 in /usr/lib32?
> Does ldconfig -32 -r show a list of files.
>
No, that was the complete output from all those commands.
[clip]
> If you can't recompile raftercc and blasta for amd64, then try
> to find the missing 32bit libs and drop them im /usr/lib32.
> You could create a symlink to get libm.so.2 (although I don't
> recommend this approach). A symlink probably won't work for
> libstdc++.co.3 because the C++ ABI changed.
So in the normal buildworld on amd64 these get built, right? I'm
trying to figure out if the vendor just screwed up the
build/installworld and I should just redo it.
Anyway I'm rebuilding on a blade to test it.
Besides GENERIC and SMP the conf is:
options BGE_FAKE_AUTONEG
so it seems like lib32 stuff should be standard.
-Kael
Steve Kargl
> > If you can't recompile raftercc and blasta for amd64, then try
> > to find the missing 32bit libs and drop them im /usr/lib32.
> > You could create a symlink to get libm.so.2 (although I don't
> > recommend this approach). A symlink probably won't work for
> > libstdc++.co.3 because the C++ ABI changed.
>
> So in the normal buildworld on amd64 these get built, right?
You need to add "WITH_LIB32=yes" to /etc/make.conf. This will
then build the 32 bit libraries and install them.
>
> so it seems like lib32 stuff should be standard.
>
You may need to add COMPAT_FREEBSD4, COMPAT_FREEBSD5
(or whatever the names) to the kernel config file.
--
Steve
Kael Fischer
All this stuff has been said before on this list, but I'll try to pull
it together here in a coherent summary.
To recap, this is 6.0-RELEASE amd64 running on Intel SBX82 Systems.
Rebuilding/installing world (or build32/install32) is sufficient to
populate /usr/lib32.
Note KERNCONF=GENERIC includes:
options COMPAT_43 # Needed by COMPAT_LINUX32
options COMPAT_IA32 # Compatible with i386 binaries
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
options COMPAT_LINUX32 # Compatible with i386 linux binaries
Note also that "WITH_LIB32=yes" in make.conf is not required (anymore,
see other threads on this list).
After install32, I had to run 'ldconfig -32 /usr/lib32'.
I still have plenty of apps that don't find the versions of libraries
they want. I'm mostly handling this with /etc/libmap32.conf (see
below)
== /etc/libmap32.conf ==
libm.so.2 libm.so
libc_r.so.5 libc_r.so
libc.so.5 libc.so
==================
I believe this is roughly equivalent to the method noted (but not
recommended) by Steve of adding symlinks. It worked fine for the test
program I don't have the source for (yeah!).
The c++ test program, which is my own code, did not work with either a
libstdc++.so.3 mapping in /etc/libmap32.conf or by copying the
libstdc++.so.3 from the 4.9-RELEASE machine it was compiled on. But
it compiles fine - so no worries there.
Those are my results, your mileage will vary.
-Kael.
p.s. Steve, thanks for the pointers.
On 1/16/06, Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
Larry Rosenman
>
> After install32, I had to run 'ldconfig -32 /usr/lib32'.
>
This brings up a point I wanted to ask about. Shouldn't the system
Startup scripts do the ldconfig -32 /usr/lib32 if /usr/lib32 exists?
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: l...@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US
Danny Braniss
> >
> > After install32, I had to run 'ldconfig -32 /usr/lib32'.
> >
>
> This brings up a point I wanted to ask about. Shouldn't the system
> Startup scripts do the ldconfig -32 /usr/lib32 if /usr/lib32 exists?
from some test runs i did:
(all tests on FreeBSD - stable amd64)
- file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1
(FreeBSD), dynamically linked (uses shared libs), not stripped
- did NOT do ldconfig -32 /usr/lib32 and a 32bit a.out run ok
- /usr/bin/ldd a.out
ldd: a.out: can't read program header
ldd: a.out: not a dynamic executable
- using a 32bit ldd actually runs/executes a.out
could someone shed some light at this magic? :-)
danny