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

[Duft Markus]

> Message: 1
> Date: Sat, 15 Aug 2009 21:41:26 +0200
> Subject: Re: global_symbol_pipe not picking up an initialized global
>       variable with msvc
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Den 2009-08-14 23:41 skrev David Byron:
[snip]
> >
> > UTL_EXPORT becomes __declspec(dllexport) when compiling the shared
> lib,
> > __declspec(dllimport) when compiling the executable that uses it.

did you double check if that really works on both sides? your problem
sound to me as if dllimport is missing somewhere.

> >
> > 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

shouldn't that be looking for __imp_optopt, etc? i guess you do try to
link against a shared lib?

> >
> > Snippets from dumpbin -symbols on the getopt_long.obj look like
this:
> >
[snip]
> >
> > Note that the unitialized variables are marked as "UNDEF" whereas
> optopt,
> > optind and optopt are marked as "SECT4".

thats a typical problem of visual studio i have run into many times
before. uninitialized variables are often simple undefined, and the
linker knows how/where to magically define them. i still haven't
discovered how i can overcome the issue .. :(

Hope that helps,
Cheers, Markus

> >
> > 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
> 
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Libtool mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/libtool
> 
> 
> End of Libtool Digest, Vol 81, Issue 16
> ***************************************