On Saturday 14 May 2005 14:00, Nix wrote:
> On Sat, 14 May 2005, [EMAIL PROTECTED] prattled cheerily:
> > On Saturday 14 May 2005 13:00, Nix wrote:
> >> On Sat, 14 May 2005, [EMAIL PROTECTED] whispered secretively:
> >> > On Saturday 14 May 2005 02:00, Nix wrote:
> >> >> On Sat, 14 May 2005, [EMAIL PROTECTED] spake:
> >> Hm, well, it failed, because you link against -lutil but don't have any
> >> library search paths set up in vmlinux.lds.
> > Why the hell it works anywhere else? binutils dependant?
> Yes, I think so. The implementation of linker search dir stuff has
> changed quite a lot recently, and there are no longer any implicitly
> searched directories: you've got to specify them all in the
> scripts. (IIRC.)
> At any rate, specifying the paths explicitly won't do any harm
> anywhere. :)
On 2.6 we just removed -L/usr/lib from the linker command line because of
some warnings. So, we could conditionalize that (maybe -D_SEARCH_PATH=). I'm
not going to merge it in this form, so send me the cleaned up version.
Also, I'd like to ask some questions to you, my dear compiler guy.
0) When is RH going to drop LinuxThreads support (as opposed to NPTL)?
1) UML does not compile with TT mode enabled when the host has a NPTL-only
glibc installed. This showed up on Gentoo, and will show up on newer RedHat
since I heard they're dropping LinuxThreads away.
Now, the problem we're currently having is due to this:
arch/um/kernel/uml.lds.S:
.thread_private : {
__start_thread_private = .;
errno = .;
. += 4;
arch/um/kernel/tt/unmap_fin.o (.data)
__end_thread_private = .;
}
That gives a "overflow of program headers, allocated #n needed #m > n" (more
or less). Would that be fixable at the linker script level? What it does is
to provide a errno definition for that segment of code since it remaps the
code while UML is executing.
I tried time ago, but failed, so I was curious.
Actually, I recently learned another way to do this, but I was still curious:
it was to change arch/um/kernel/tt/unmap.c to inline the syscalls and avoid
using errno at all (it's used in the SKAS test program I posted).
2) /usr/lib/libpcap.so ships with a global symbol named "vmap" which overlaps
with the kernel vmap() function. Depending on the libpcap version, it's
either BSS or common, which is even worse, i.e. causes subtle failures (I've
actually verified them). This has stopped me until now from enabling pcap,
apart other issues (actually I could write -Dvmap=kernel_vmap for UML, but I
didn't because it wasn't clean).
The questions are:
- shouldn't common symbols in libraries be forbidden
- I've verified that that symbol could be static (it's a var. of a type
declared in the object and there are no relocation pointing to it, and the
linker is not allowed to resolve the relocations there). Isn't that stupid?
Would this be fixable at distro's level?
(Note that I already played dirty linker tricks as in
arch/um/kernel/tt/Makefile).
--
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
