> > You've basically hacked rtld to bits. All the ifdefs make it hard
> > to read and maintain.
>
> There number of #ifdef's is not large (for me) to make rtld unmaintainable.
> If this is inappropriate for you there are two obvious ways to solve it:
> - refactor rtld-elf and move common parts of libdl (or whatever) and
> rtld-elf to separate files
> - unifdef rtld-elf and put libdl sources separately
>
> The reasons I implemented this as a patch for rtld-elf are:
> - I did not want to create two almost identical pieces of code
> - I wanted to make these patches as obvious as they can be.
> This is just a proof-of-concept work.
Understood, but I think that either solution is not great. We either
wedge libdl into rtld or we have 2 copies of large amounts of rtld.
>
> > This statically links rtld into any static binary that wants to use
> > dlopen. What was that about saving space on the root partition?
>
> I didn't tell you or anyone else that this work is done towards
> saving space in /. The question was about nsswitch and (in particular)
> dlopen in statically linked programs.
Ok.
> > It also creates a special case in the makefiles, unless
> > we do this for all static binaries, which would cause a lot of bloat.
>
> Are you talking about STATICOBJS and SHOBJS? This is how libpam is built
> right now. You have different sets object files in shared and static
> versions of libpam. Please take a look at src/lib/libpam/libpam/Makefile
> and corresponding /usr/share/mk bits.
What I was referring to is a trick to force the linker to generate
a dynamic binary with all the usual elf dynamic tables, but which is
actually statically linked.
eg:
> cat test.c
int
main(void)
{
printf("hello world\n");
}
> cc -static -Wl,-r -o test test.c
> touch hack.c
> cc -shared -o hack.So hack.c
> ld -o test1 test /home/jake/hack.So
> ./test1
hello world
>
Conceivably this would allow dlopen to work on the main program, and is
what we do to allow the kernel to link klds against itself. But you
also need to do something about the .interp section that gets put in,
and the .dynamic, .dynsym and .dynstr sections aren't free.
>
> > As a result of the above, how do you deal with multiple implementations
> > of library services being present? For example a statically linked
> > binary calls malloc, so it has a copy of malloc linked into it. It tries
> > to dlopen a library which also calls malloc. Which copy of malloc does
> > the library use? How does it locate the malloc that's linked into the
> > static binary without the dynamic tables?
>
> A part of answer is above (about ld not knowing which symbols
> shared object will want). The real solution is to link
> shared libraries with all objects they will need (including libc).
> This is how things are implemented in other systems.
> As a result library will use malloc from libc that will be
> loaded as a dependency (and this is demonstrated in the example I posted).
>
> > What happens when the application
> > tries to free a pointer allocated by the library, or vice versa?
>
> This is not possible for obvious reasons.
> On Linux you will get SEGFAULT (for the same obvious reasons).
> Yes, this is a limitation.
>
> > When David said we didn't think it could be done properly or sanely, we
> > meant it. It must work exactly like it would in a dynamic binary.
>
> You can't get exact behaviour. But this behaviour is sufficient
> for PAM and NSS. Maybe there are some other (less important) uses for
> this stuff.
What I'm suggesting is that for libdl to be a viable alternative to
making the binaries in / dynamic so that pam works, it has to work
better. Preferably as good as in dynamic binaries, and without the
foot shooting potential that having 2 copies of malloc or other things
loaded entail. Yes, a simple implementation may work for PAM, but
using full blown dynamic linking is architecturally much cleaner and
I think that this outweighs the disadvantages.
>
> Sorry for being too emotional, but none of your questions make sense.
> I highly appreciate your work on sparc64 but seems that
> you were in bad mood when typing an answer.
Very bad, sorry. :)
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
