Re: [Mingw-users] How to find out how symbols are exported

[Brian D. <br...@de...>]

Suresh Govindachar wrote:

>   So when building gvim with dynamic support for perl:
> 
>   1) For older versions of ActivePerl, the build is
>      successful without any explicit -lperl58
> 
>      The linker somehow knows that perl58 related
>      symbols that it cannot resolve will be resolved
>      at runtime via perl58.dll

No, the linker doesn't actually know this.  It's quite dumb.  Read Ross
Ridge's reply, for I think it makes a great deal of sense.  There is a
difference between dynamically loading a library at runtime
(LoadLibrary/GetProcAddress) and linking directly against it at
link-time.  In the former, the linker has no idea that the library is
even used, as it has no symbols at compile/link time to resolve.  In the
latter case it must be explicitly told via the link command otherwise
the symbols are undefined.

This is complicated by the fact that ELF platforms have lazy binding,
which means a binary can be linked with unresolved symbols that are
dynamically resolved through the dynamic linker at runtime.  But this
facility does not exist on PE, so this is why gvim most likely built
successfully without -lperl58 on ELF platforms.

>   So ActiveState is "exporting" Perl_sv_2iv_flags and
>   Perl_newXS_flags in a way that is different from the
>   way they export other symbols.
> 
>   Is it possible to examine perl58.dll and/or perl58.lib
>   to figure out what's wrong in the way Perl_sv_2iv_flags
>   and Perl_newXS_flags are being exported?

It's not the perl library that needs to be examined, it's how the code
calls it.  If you use LoadLibrary/GetProcAddress (analogous to POSIX
dlopen/dlsym) then you effectively hide the presense of the symbols from
the linker completely -- they are created at runtime and don't exist at
link-time.

> Here's what worked (had two -lperl58) -- would be interested in knowing more about the "ordering" issue.

The linker reads arguments from left to right.  It pulls in symbols from
each object that represent undefined symbols that it has so far
encountered.  Thus if you specify a dependent library before the object
that uses it, no symbols will be copied from the library which results
in undefined references at the end.

Again a lot of people run into this because in the case of ELF it does
not matter for linking of shared libraries, so you can get away with any
order.  But it does matter on ELF for static libraries, and it matters
on PE for both shared and static libraries.

Brian