* Philip Guenther <guent...@gmail.com> [171107 00:44]:
> On Mon, Nov 6, 2017 at 2:37 PM, Christian Kellermann <ck...@pestilenz.org>
> wrote:
> >
> > While porting a smalltalk VM to OpenBSD I came across this peculiar
> > quirk and I don't quite understand what's going on.
> >
> > This VM does its FFI calls through dlopen'ing and dlsym'ing the
> > symbols in question. This seems to work fine for all kinds of
> > functions. However it fails with libc's "environ" symbol.
> >
>
> libc's environ symbol is only used in static links; in dynamic links it's
> overridden by ld.so's definition. This is also the case for the dl*
> symbols themselves (as well as the internal __progname symbol that you
> should avoid: use getprogname() instead).
>
> So, instead of doing this:
>
> > handle = dlopen("libc.so", RTLD_NOW|RTLD_GLOBAL);
> >
>
> I think you should just pass dlsym() the fake RTLD_DEFAULT handle. Is
> there a particular reason you're not using that, or maybe RTLD_NEXT, right
> now?
That's due to the nature of this code in question. It is a general
FFI handling primitive, so it gets used to, say bind symbols from
libcairo as well. So in this case I have no control over the handle.
I could special case that for this explicit call in the smalltalk
code though. I will have to discuss this with upstream. Is this
just necessary for environ and __progname or are there other special
cases I need to watch out for?
Thanks for your explanation, this makes sense to me now!
Kind regards,
Christian
