After setting up Linux binary support as per the handbook and the additional instructions displayed during the installation (using the linux_base-fc-4_8 port as of 2006-08-23), both some programs contained in the port as well as external Linux binaries behave strangely. ldconfig more or less works: yeti# /compat/linux/sbin/ldconfig -v /compat/linux/sbin/ldconfig: PATH `/lib' given more than once /compat/linux/sbin/ldconfig: PATH `/usr/lib' given more than once /lib: libpcre.so.0 -> libpcre.so.0.0.1 [lot more output to follow...] However, Linux ldd can't display which libraries are used by Linux ldconfig: yeti# /compat/linux/usr/bin/ldd /compat/linux/sbin/ldconfig /compat/linux/usr/bin/ldd: /lib/ld-linux.so.2: not found ldd: /lib/ld-linux.so.2 $exited with unknown exit code (127) And you can't run a Linux binary installed by a port which only depends on linux_base-fc-4_8: yeti# /usr/local/bin/915resolution 915resolution: error while loading shared libraries: /usr/lib/libc.so.6: ELF file OS ABI invalid Fix: none How-To-Repeat: In order to return to a clean state, I've removed everything Linuxish from my box. This is not required to see the problem, but it is meant to show that the failure does not depend on a botched system installation: - pkg_delete all linux_? ports - unmount linprocfs - rm -r /compat/linux - remove the linprocfs entry from /etc/fstab - remove the Linux ABI support from /etc/rc.conf - reboot Now I should have a box without any Linux stuff left over. - cd /usr/ports/emulators/linux_base-fc-4 - make && make install - add "linproc /compat/linux/proc linprocfs rw 0 0" to /etc/fstab - add the Linux ABI support to /etc/rc.conf: linux_enable="YES" - reboot (or mount linproc manually) - verify that Linux support is in the kernel: "kldstat|grep linux" returns linux.ko - verify that linproc is mounted: "mount" returns linprocfs on /usr/compat/linux/proc (linprocfs, local) - cd /usr/ports/sysutils/915resolution - make && make install - run /usr/local/bin/915resolution, or any of the abovementioned Linux commands, to see the errors
Responsible Changed From-To: freebsd-bugs->freebsd-emulation Ports PR.
If you've read /usr/ports/UPDATING (20060616: AFFECTS users of emulation/linux_base-*) and your "printenv | grep LD_" shows nothing please put ktrace.out of "ktrace -i <your_programm>" somewere at http:// or ftp:// and send me a link by email. WBR -- bsam
State Changed From-To: open->feedback Awaiting for a feedback.
Boris, this is the additional info pertaining to the section you mentioned in UPDATING: - I did not modify any relevant sysctls: yeti# sysctl -h compat.linux.osname compat.linux.osname: Linux yeti# sysctl -h compat.linux.osrelease compat.linux.osrelease: 2.4.2 - I did not set any LD_* variables: yeti# printenv|grep LD_ yeti# The ktrace output is available at: http://refdb.sourceforge.net/stuff/ktrace.out Thanks for looking into this. Markus Boris Samorodov writes: > If you've read /usr/ports/UPDATING (20060616: AFFECTS users of > emulation/linux_base-*) and your "printenv | grep LD_" shows nothing > please put ktrace.out of "ktrace -i <your_programm>" somewere at > http:// or ftp:// and send me a link by email. > > WBR > -- > bsam > -- Markus Hoenicka markus.hoenicka@cats.de (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de
Quoting Boris Samorodov <bsam@ipt.ru> (from Fri, 25 Aug 2006 02:28:36 +0400)= : > On Thu, 24 Aug 2006 23:48:08 +0200 Markus Hoenicka wrote: >> Boris Samorodov writes: > >> > Can you give me a link to ktrace.out for >> > "ktrace -i /compat/linux/usr/bin/ldd /compat/linux/sbin/ldconfig"? > >> Yes, please have a look at: > >> http://refdb.sourceforge.net/stuff/ldd/ktrace.out > > Aha, /compat/linux/usr/bin/ldd is a script. Can't say for sure should > it work or not but something strange does exist: > ----- > 24546 ktrace RET ktrace 0 > 24546 ktrace CALL execve(0xbfbfe85e,0xbfbfe75c,0xbfbfe768) > 24546 ktrace NAMI "/compat/linux/usr/bin/ldd" > 24546 ktrace NAMI "/bin/sh" > 24546 ktrace NAMI "/libexec/ld-elf.so.1" > 24546 sh RET execve 0 > ----- > > Alexander, can you comment on this behaviour? Thanks! The kernel contains code to detect if a linux program is a script and =20 contains "#!" at the beginning. If it detects this, it tries to start =20 the linux version of the interpreter. At least it should do that. If =20 the above isn't a cut-down version of the ktrace, and if the linux ldd =20 does contain "#!" as the first two characters of the file (I can't =20 check ATM), then there's something wrong here. Regarding the lib problem in the PR: FreeBSD 6.x and fc4 contain a =20 libc.so.6. So the order of the ld path (/compat/linux/etc/ld.so.conf =20 or how it is spelled) may matter. I don't have a 6.x system to test =20 this, so someone has to play around with it and report here (don't =20 forget to rerun the linux ldconfig with the '-R /compat/linux' option =20 after each change). If this doesn't solve the problem, I need to see =20 the complete ktrace of a failing program which tries to link with =20 libc.so.6. Bye, Alexander. --=20 58: Shareware installieren Die System Clock um drei Monate zur=C3=BCckstellen (Peter Berlich= ) http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
On Fri, Aug 25, 2006 at 08:23:20AM +0200, Alexander Leidinger wrote: > Quoting Boris Samorodov <bsam@ipt.ru> (from Fri, 25 Aug 2006 02:28:36 > +0400): > > >On Thu, 24 Aug 2006 23:48:08 +0200 Markus Hoenicka wrote: > >>Boris Samorodov writes: > > > >> > Can you give me a link to ktrace.out for > >> > "ktrace -i /compat/linux/usr/bin/ldd /compat/linux/sbin/ldconfig"? > > > >>Yes, please have a look at: > > > >>http://refdb.sourceforge.net/stuff/ldd/ktrace.out > > > >Aha, /compat/linux/usr/bin/ldd is a script. Can't say for sure should > >it work or not but something strange does exist: > >----- > > 24546 ktrace RET ktrace 0 > > 24546 ktrace CALL execve(0xbfbfe85e,0xbfbfe75c,0xbfbfe768) > > 24546 ktrace NAMI "/compat/linux/usr/bin/ldd" > > 24546 ktrace NAMI "/bin/sh" > > 24546 ktrace NAMI "/libexec/ld-elf.so.1" > > 24546 sh RET execve 0 > >----- > > > >Alexander, can you comment on this behaviour? Thanks! > > The kernel contains code to detect if a linux program is a script and > contains "#!" at the beginning. If it detects this, it tries to start > the linux version of the interpreter. At least it should do that. If > the above isn't a cut-down version of the ktrace, and if the linux ldd > does contain "#!" as the first two characters of the file (I can't > check ATM), then there's something wrong here. > > Regarding the lib problem in the PR: FreeBSD 6.x and fc4 contain a > libc.so.6. So the order of the ld path (/compat/linux/etc/ld.so.conf > or how it is spelled) may matter. I don't have a 6.x system to test > this, so someone has to play around with it and report here (don't > forget to rerun the linux ldconfig with the '-R /compat/linux' option > after each change). If this doesn't solve the problem, I need to see > the complete ktrace of a failing program which tries to link with > libc.so.6. it might be unrelated but I have reports that libmaping doesnt work in this case when you have the same named library. the problem is in system linker. dont remember details I CC: cejkar@fit.vutbr.cz who reported me this problem. roman
On Fri, 25 Aug 2006 08:23:20 +0200 Alexander Leidinger wrote: > Quoting Boris Samorodov <bsam@ipt.ru> (from Fri, 25 Aug 2006 02:28:36 +0400): > > On Thu, 24 Aug 2006 23:48:08 +0200 Markus Hoenicka wrote: > >> Boris Samorodov writes: > > > >> > Can you give me a link to ktrace.out for > >> > "ktrace -i /compat/linux/usr/bin/ldd /compat/linux/sbin/ldconfig"? > > > >> Yes, please have a look at: > > > >> http://refdb.sourceforge.net/stuff/ldd/ktrace.out > > > > Aha, /compat/linux/usr/bin/ldd is a script. Can't say for sure should > > it work or not but something strange does exist: > > ----- > > 24546 ktrace RET ktrace 0 > > 24546 ktrace CALL execve(0xbfbfe85e,0xbfbfe75c,0xbfbfe768) > > 24546 ktrace NAMI "/compat/linux/usr/bin/ldd" > > 24546 ktrace NAMI "/bin/sh" > > 24546 ktrace NAMI "/libexec/ld-elf.so.1" > > 24546 sh RET execve 0 > > ----- > > > > Alexander, can you comment on this behaviour? Thanks! > The kernel contains code to detect if a linux program is a script and > contains "#!" at the beginning. If it detects this, it tries to start > the linux version of the interpreter. At least it should do that. If > the above isn't a cut-down version of the ktrace, and if the linux ldd It is a cut-down version of ktrace. I expected that a linux shell should be execed, but not a native one. And later this shell is trying to find /lib/ld-linux.so.2 and boils out! > does contain "#!" as the first two characters of the file (I can't > check ATM), then there's something wrong here. Yep: ----- # uname -a FreeBSD bsam.ru 6.1-STABLE FreeBSD 6.1-STABLE #0: Sat Aug 19 00:13:01 MSD 2006 bsam@bsam.ru:/usr/obj/usr/src/sys/GENERIC i386 # head -1 /compat/linux/usr/bin/ldd #! /bin/sh ----- > Regarding the lib problem in the PR: FreeBSD 6.x and fc4 contain a > libc.so.6. So the order of the ld path (/compat/linux/etc/ld.so.conf > or how it is spelled) may matter. I don't have a 6.x system to test > this, so someone has to play around with it and report here (don't > forget to rerun the linux ldconfig with the '-R /compat/linux' option > after each change). If this doesn't solve the problem, I need to see > the complete ktrace of a failing program which tries to link with > libc.so.6. The lib problem is already fixed (non-standard file /usr/lib/libc.so.6 existed at the submitter's machine). Thanks for your help. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve
State Changed From-To: feedback->closed Solved - nonstandard installation on submitter's machine. The underlaying problem in rtld stays.