Re: GNU dlopen(3) differs from POSIX/IEEE

[Carlos O'Donell <carlos@redhat.com>]

On 06/13/2016 10:48 AM, Suprateeka R Hegde wrote:
> Without provding libfoo on the link line, I could not get a JUMP_SLOT
> for foo. So I provided -lfoo for the link-edit phase and then renamed
> libfoo.so to libfoo1.so and also created a dummy libfoo.so without
> foo. This way, I could get a JUMP_SLOT for foo. This hack was not
> necessary on other platforms as foo gets a PLT entry even without
> definition. By getting a JUMP_SLOT, I could verify if LD_PRELOAD
> works in this case.

Correct, you don't get a PLT entry for foo unless it's in a shared
library at link-edit time.

Could you actually provide the exact steps you used in a GNU/Linux-
--based system to produce the final executable?

My experience is that you will either see a failure at link-edit
time, failure at runtime (missing libfoo.so, undefined symbol foo),
and will never get to the point where you can run the application
and get a segfault. I'm curious to see exactly the way you constructed
the scenario.

Therefore if the application's global symbol references all must be
defined before it starts there is no possibility for dlopen with
RTLD_GLOBAL to add symbols to the global scope that can be used
to result such symbols, because they are already resolved.

-- 
Cheers,
Carlos.