Date: Sat, 02 Feb 2002 18:49:11 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE> Cc: John Polstra <jdp@polstra.com>, hackers@freebsd.org Subject: Re: problem w/ dlopen(); bug or feature? Message-ID: <3C5CA527.4A7BEEC4@mindspring.com> References: <20020201201018.GB2992@frolic.no-support.loc> <20020201212028.GC2992@frolic.no-support.loc> <200202020424.g124OXD03238@vashon.polstra.com> <20020202125107.GA481@frolic.no-support.loc>
next in thread | previous in thread | raw e-mail | index | archive | help
Bjoern Fischer wrote: > > Yes, it's possible to find out which shared object the dlopen call > > was made from. There's already a function obj_from_addr() in rtld.c > > which does that. But as far as I know, it is not standard behavior to > > search the RPATH of the object which issued the dlopen call. > > I only have seen an early draft of the current ELF spec, but I think > the search strategy is simply unspecified in this point. Even so, the ELF > spec probably would have specified to use the RPATH of the 'parent' > object, because the ELF spec targets self containedness for all shared > objects. > > A shared object should be self contained. This is not possible for > dlopen()ed objects with the current search strategy of the FreeBSD rtld. It would be useful to be able to dlopen a shared object that was linked against a Linux shared library, from inside a FreeBSD binary that opens the shared object. I think that FreeBSD still does not handle the ld and the rtld code correctly, right now. There was an issue that Archie Cobbs ran into with Kaffe; it was not obvious to start with, but it boiled down to a shared object needing symbols from another shared object, and the dlopen not bringing in the second shared object when the first was brought in (the Kaffe issue is that it was in the context of a JNI). The ugly workaround was to link the Kaffe against the library that the shared object needed to be linked against, so the symbols would be found. There are also some issues with rtld of "RTLD_NOW" vs. "RTLD_LAZY", when linking against shared libraries. In particular, the FreeBSD linker doesn't treat all symbols as "RTLD_NOW" for liraries that reference libraries. Specifically, if I have program A linked against library B (shared), which needs library C (shared) for some of the symbols it imports, the link will succeed anyway, and the program will fail at runtime, if library C is not specified, and there will not be an "unresolved symbols" error, as you would expect (want) in the case that the library C is used *only* by library B, and not by program A. In other words, links are treated as "RTLD_LAZY" at link time. I went and tried to fix this in ld, at one time, but there is a lot of sweater on the other end of that thread, if you pull it, and I stopped when it became obvious that fixing it for real would require some fundamental linker changes for symbol reference counting (I had it fixed, but it was over 300 lines of changes, and the resulting code was very ugly). Personally, I like the idea that linking a shared object against a shared object should work to drag in the second, when a main program links against the first. The ELF spec *dies* specify that that should work. I like the "by extension" argument that would let me use different versions of the same library in the same program, based on an intermediate library being linked against a different version than the main program (we're talking only major version numbers here -- for minors, the one the main program is linked against should override). I don't know how you would deal with data space, in that case, though. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C5CA527.4A7BEEC4>