Re: Other Linux stuff...
For trivial cases, the simplest solution would be to just remove /compat/linux/usr/bin/ldd and have our native ldd do the work. If something depends on the switches, this won't work. At http://huizen.dds.nl/~frodol/glibc/problems.html it says: * ldd gives real strange output, sometimes... The ldd script that comes with glibc-2.0.6 handles libc5 executables incorrectly, resulting in strange output. You are probably better off if you always use the ldd that comes with ld.so-1.9.9. Implement this by deleting or renaming /usr/i486-linux-libc6/bin/ldd I've done this under Linux itself, and it worked well. -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Other Linux stuff...
"Bruce A. Mah" wrote: If memory serves me right, Marcel Moolenaar wrote: So, from a pure ELF layout point of view, both shared objects and executables are the same. But a shared library is not guaranteed to be executable. Allowing shared objects to be executed is in violation with the specs: This may be a really stupid question, but what on Earth do they gain by allowing the execution of shared object files? The only gain I see, if you can call it a gain, is that you can get non-trivial information out of a shared object from within scripts, but I don't know if this has been the reason. If you don't allow execution of shared objects, you have to use dlopen(3) and call some functions or query some variables. Would it be possible to write a small wrapper to load the shared library and execute some entryfunction to get it started? I suppose that's what the elf-loader under linux does. If so that would be a simple addition to the linux-lib port. Marc. -- Marc van Kempen BowTie Technology Raiffeisenstraat 7 5611 CH Eindhoven tel. +31 40 2 64 98 60 mailto:[EMAIL PROTECTED] fax. +31 40 2 64 98 61 http://www.bowtie.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Other Linux stuff...
Marc van Kempen wrote: The only gain I see, if you can call it a gain, is that you can get non-trivial information out of a shared object from within scripts, but I don't know if this has been the reason. If you don't allow execution of shared objects, you have to use dlopen(3) and call some functions or query some variables. Would it be possible to write a small wrapper to load the shared library and execute some entryfunction to get it started? I suppose that's what the elf-loader under linux does. You mean something like MS Windows rundll? Yes, that should work in general. But may not in all cases. If the dynamic linker (ld-linux.so.2) checks the executable name to see if it has been started by the OS to perform dynamic linking for the binary or to see if it's executed itself for the dependency information (ie by ldd), then this may not work (I have to check if this is the case, but I don't think it's out of the question). If so that would be a simple addition to the linux-lib port. For trivial cases, the simplest solution would be to just remove /compat/linux/usr/bin/ldd and have our native ldd do the work. If something depends on the switches, this won't work. I haven't come up with a solution I like. I also haven't paid much attention to it, because it doesn't seem a major problem. Suggestions are always welcome, of course. As a work-around, I can have linux_devtools remove ldd(1) so that it at least works for the trivial cases. I don't know why I haven't done this already :-) -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Other Linux stuff...
Huh... I was sure it did... Oh, well, guess my memory ain't what it used to be :-/ But... Since you are the Linux Guru, and it seems I momentarily have your attention, let me ask you about another Linux emulation matter. :) The Linux 'ldd' program is, as I'm sure you know, just a shell script that tries to directly execute 'ld-linux.so.2' on the filename passed in argv to the script. This doesn't work with our Linux emulation. Apparently, ld-linux.so.2 is simply (and not too surprisingly) not recognized as an executable file. While I'm surprised that this works on Linux, shouldn't our emulator emulate this behavior too? On Tue, Nov 28, 2000 at 07:03:38PM -0500, Marcel Moolenaar wrote: "Donald J . Maddox" wrote: I actually thought that COMPAT_LINUX had been completely removed, just causing opt_dontuse.h to be generated. I see now that it doesn't even warn about this being a deprecated option. *Is* it still considered a deprecated option? I'm sure config used to warn about COMPAT_LINUX being deprecated a while back... It's not a deprecated option. I'm not aware of config ever emitting a warning for it. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Other Linux stuff...
"Donald J . Maddox" wrote: The Linux 'ldd' program is, as I'm sure you know, just a shell script that tries to directly execute 'ld-linux.so.2' on the filename passed in argv to the script. This doesn't work with our Linux emulation. Apparently, ld-linux.so.2 is simply (and not too surprisingly) not recognized as an executable file. While I'm surprised that this works on Linux, shouldn't our emulator emulate this behavior too? It's not a matter of our emulator. The problem is that Linux allows the execution of shared objects. Technically speaking this is wrong and our ELF loader doesn't do that. We can change our ELF loader, but that would propagate the bug to FreeBSD at large. I don't think we should do that. I did make patches once. They're probably outdated, but there's a change they apply: http://people.FreeBSD.org/~marcel/elf-2.2.8.diff http://people.FreeBSD.org/~marcel/elf-stable.diff http://people.FreeBSD.org/~marcel/elf-current.diff WARNING: -stable probably represents 3.x (which makes -current represent 4.x) -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Other Linux stuff...
It's not a matter of our emulator. The problem is that Linux allows the execution of shared objects. Technically speaking this is wrong and our ELF loader doesn't do that. We can change our ELF loader, but that would Could you elaborate on this, please. I am interested in what is meant with execution of shared objects (as opposed to programs). Why is this wrong? Thanks, Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Other Linux stuff...
[EMAIL PROTECTED] wrote: It's not a matter of our emulator. The problem is that Linux allows the execution of shared objects. Technically speaking this is wrong and our ELF loader doesn't do that. We can change our ELF loader, but that would Could you elaborate on this, please. I am interested in what is meant with execution of shared objects (as opposed to programs). Why is this wrong? Because the ELF file doesn't have the right attribute and therefore may not have all the necessary information to execute it properly (such as start address). In principle a shared object will have the same structure as an executable in that both are loadable. So, from a pure ELF layout point of view, both shared objects and executables are the same. But a shared library is not guaranteed to be executable. Allowing shared objects to be executed is in violation with the specs: on FreeBSD: gauss% ./libc.so.4 ./libc.so.4: Permission denied. on HP-UX (why not, it's accessable): barra:marcel_as% ./libc.2 ./libc.2: Exec format error. Binary file not executable. on Linux: [marcel@hpcll510 /lib]$ ./libc.so.6 GNU C Library stable release version 2.1.3, by Roland McGrath et al. Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.14-1.5.0 system on 2000-02-29. Available extensions: GNU libio by Per Bothner The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others BIND-4.9.7-REL NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton linuxthreads-0.8 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Report bugs using the `glibcbug' script to [EMAIL PROTECTED]. And for a different library (still on Linux): [marcel@hpcll510 /lib]$ ./libutil.so.1 Abort -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Other Linux stuff...
If memory serves me right, Marcel Moolenaar wrote: So, from a pure ELF layout point of view, both shared objects and executables are the same. But a shared library is not guaranteed to be executable. Allowing shared objects to be executed is in violation with the specs: This may be a really stupid question, but what on Earth do they gain by allowing the execution of shared object files? Bruce. PGP signature
Re: Other Linux stuff...
"Bruce A. Mah" wrote: If memory serves me right, Marcel Moolenaar wrote: So, from a pure ELF layout point of view, both shared objects and executables are the same. But a shared library is not guaranteed to be executable. Allowing shared objects to be executed is in violation with the specs: This may be a really stupid question, but what on Earth do they gain by allowing the execution of shared object files? The only gain I see, if you can call it a gain, is that you can get non-trivial information out of a shared object from within scripts, but I don't know if this has been the reason. If you don't allow execution of shared objects, you have to use dlopen(3) and call some functions or query some variables. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
