Re: Behavior change, PLT entries for R_X86_64_PLT32 relocations with undefined symbol

[Michael Matz <matz at suse dot de>]

Hi,

On Mon, 25 Mar 2019, Martin McClure wrote:

> Using the weak symbol worked nicely -- thanks again! The '-z 
> dynamic-undefined-weak' option was not required. I like this better than 
> our previous use of --unresolved-symbols=ignore-all since that did not 
> detect misspelled function names until runtime.

With weak symbols you won't have such detection either.  Weak undefined 
symbols will simply turn out to be NULL and crash the same way.

> Is there any drawback to using weak symbols? I don't expect any strong 
> symbols with these names to be defined anywhere outside of the 
> dynamically loaded library.

Then weak symbols won't have any drawback in your scenario.  Weak 
references aren't much different from undefined (in the current DSO) 
global symbols; weak definitions would be, but you don't have those.

> Is there any better way to implement this kind of pattern? I looked for 
> an option something like -l to link a dynamic library, but that unlike 
> -l did not add a DT_NEEDED entry for the library, so the specific 
> library could be specified at runtime. However, if there is such an 
> option I did not find it.

There is one way: --dynamic-list.  You can force certain symbols to be 
dynamic, which luckily still includes undefined symbols:

% cat symbols.list
{
answer;
};
% gcc executable.o -lc -ldl -Wl,--unresolved-symbols=ignore-all \
  -Wl,--dynamic-list,symbols.list  -o executable

(remove the weak again to see it working for real).

But you still need the --unresolved-symbols=ignore-all to not get an 
error, so you still get no nice checking for misspellings.


Ciao,
Michael.