Re: global_symbol_pipe not picking up an initialized global variable with msvc

[Peter Rosin]

Den 2009-08-14 23:41 skrev David Byron:
> I'm pretty sure I'm running into a pr-msvc-support-specific problem but I'm
> still learning about libtool so...
>
> I'm trying to get rid of unresolved externs when linked an executable
> against a libtool shared library compiled with msvc.  The unresolved externs
> are global variables.  The code in question yet another getopt
> implementation.  The variables are declared and defined like this:
>
> <getopt.h>
> extern UTL_EXPORT int   opterr;
> extern UTL_EXPORT int   optind;
> extern UTL_EXPORT int   optopt;
> extern UTL_EXPORT int   optreset;
> extern UTL_EXPORT char  *optarg;
>
> <getopt_long.c>
> int     opterr = 1;
> int     optind = 1;
> int     optopt = '?';
> int     optreset;
> char    *optarg;
>
> UTL_EXPORT becomes __declspec(dllexport) when compiling the shared lib,
> __declspec(dllimport) when compiling the executable that uses it.
>
> What's interesting is that I only get unresolved externs for the initialized
> variables:
>
> utils-test.obj : error LNK2001: unresolved external symbol _optopt
> utils-test.obj : error LNK2001: unresolved external symbol _optind
> utils-test.obj : error LNK2001: unresolved external symbol _opterr
>
> Snippets from dumpbin -symbols on the getopt_long.obj look like this:
>
> COFF SYMBOL TABLE
> 000 006DC627 ABS    notype       Static       | @comp.id
> 001 00000001 ABS    notype       Static       | @feat.00
> 002 00000000 SECT1  notype       Static       | .drectve
>     Section length   C9, #relocs    0, #linenums    0, checksum        0
> 004 00000000 SECT2  notype       Static       | .debug$S
>     Section length 1EEC, #relocs   5B, #linenums    0, checksum        0
> 006 00000000 SECT3  notype       Static       | .bss
>     Section length    7, #relocs    0, #linenums    0, checksum        0
> 008 00000000 SECT3  notype       Static       | $SG6258
> 009 00000004 UNDEF  notype       External     | _optarg
> 00A 00000004 UNDEF  notype       External     | _optreset
> 00B 00000000 SECT4  notype       Static       | .data
>     Section length   44, #relocs    1, #linenums    0, checksum 2C7EE1AD
> 00D 00000000 SECT4  notype       External     | _opterr
> 00E 00000004 SECT4  notype       External     | _optind
> 00F 00000008 SECT4  notype       External     | _optopt
> 010 0000000C SECT4  notype       Static       | _place
>
> Note that the unitialized variables are marked as "UNDEF" whereas optopt,
> optind and optopt are marked as "SECT4".
>
> After a bit of digging, I have a feeling that the place to fix this is the
> source file that puts this in the generated libtool script:
>
> # Take the output of nm and produce a listing of raw symbols and C names.
> global_symbol_pipe="gawk '     {last_section=section; section=\$ 3};
> /Section length .*#relocs.*(pick any)/{hide[last_section]=1};     \$
> 0!~/External *\\|/{next};     / 0+ UNDEF /{next}; / UNDEF
> \\([^|]\\)*()/{next};     {if(hide[section]) next};     {f=0}; \$
> 0~/\\(\\).*\\|/{f=1}; {printf f ? \"T \" : \"D \"};     {split(\$ 0, a,
> /\\||\\r/); split(a[2], s)};     s[1]~/address@hidden/{print s[1], s[1]; next};
> s[1]~prfx {split(s[1],t,\"@\"); print t[1], substr(t[1],length(prfx))}     '
> prfx=^_"
>
> My libtool/awk skills are not where they need to be to fix this.  My
> understanding of symbol resolution/linking in general is not where it needs
> to be to even know if pulling in everything marked "External" but not
> necessarily "UNDEF" is the right thing to do.
>
> I could (obviously) use a hand here.
>
> Thanks for your help.

I don't think the awk script is at fault, if I run your dumpbin -symbols
data through that global_symbols_pipe (manually, m4sh-isms stripped
of course) it produces:

D _optarg optarg
D _optreset optreset
D _opterr opterr
D _optind optind
D _optopt optopt

which seems about right. Sure, the initialized variables *could* have
been marked with C instead of D, but I think C and D are treated
equally further down in the processsing.

However, to be 100% certain and eliminate any doubt you can - if you
wish - configure with NM=nm (instead of dumpbin -symbols) and see if
that makes any difference.

I need to see more of what you are actually trying to do, the real
libtool invocations and the output they produce etc. Compress the
output if it is large...

Cheers,
Peter