undefined symbols at *runtime*

syphilis has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

Every now and then I see questions here that involve reports of "undefined symbol" during the make test phase of a module build procedure ... eg this from this post:

Can't load 'blib/arch/auto/PGPLOT/PGPLOT.so' for module PGPLOT: /usr/l
+ocal/pgplot/libpgplot.so: undefined symbol: e_rsfe at /usr/lib64/perl
+5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm line 230, <STDIN> lin
+e 1.
[download]

In this instance the OP (nickschurch) was building on a nix-type architecture.

It's the fact that this error occurred during the 'make test' (runtime) phase, rather than the 'make' (compile-time) phase, that has me puzzled.

As a (primarily) MS-Windows (MinGW compiler) user I only ever see "undefined symbol" errors at the 'make' (compilation) phase. I have *never* struck an "undefined symbol" error during the 'make test' (runtime) stage of a module build on MS Windows. Is this because:

a) I'm incredibly lucky ?
b) I'm on MS Windows ?
c) I only ever build against *static* libraries ?
d) other ?

Cheers,
Rob

Comment on undefined symbols at runtime Select or Download Code

Replies are listed 'Best First'.
Re: undefined symbols at runtime by Joost (Canon) on Nov 30, 2007 at 17:19 UTC
Note that PGPLOT.so (a shared library) tries to link to another shared library and the error message states that one of the symbols (usually a function) cannot be found in that shared library. This is expected behaviour - at least on unix, but I assume the same thing happens on windows - when you're using shared libraries, since the references to symbols in libraries you're using are resolved when linking, and shared libraries are linked at run time (on unix - using the dlopen() function, which is often handled automatically but you can load library files and look up their symbols "by hand" too, if you need to). I.e. loading a library/program that uses another shared library causes the other library to be loaded and linked recursively, at the moment the library is actually opened. That's done because otherwise you would have to recompile all referring programs when you update a shared library. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]

Replies are listed 'Best First'.

Re: undefined symbols at *runtime*
by Joost (Canon) on Nov 30, 2007 at 17:19 UTC

This is expected behaviour - at least on unix, but I assume the same thing happens on windows - when you're using shared libraries, since the references to symbols in libraries you're using are resolved when linking, and shared libraries are linked at run time (on unix - using the dlopen() function, which is often handled automatically but you can load library files and look up their symbols "by hand" too, if you need to).

I.e. loading a library/program that uses another shared library causes the other library to be loaded and linked recursively, at the moment the library is actually opened.

That's done because otherwise you would have to recompile all referring programs when you update a shared library.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

[reply]