Re: fix dumpbin symbol pipe

[Ralf Wildenhues]

Hi Peter,

* Peter Ekberg wrote on Fri, Sep 09, 2005 at 10:29:27AM CEST:
> * Ralf Wildenhues wrote on Thursday, September 08, 2005 10:26 CEST:
> > * Peter Ekberg wrote on Wed, Aug 31, 2005 at 05:52:43PM CEST:
> > > 
> > > I have tried to stay away from gawk-specific constructs,
> > > as documented by "info gawk", but allowed myself to
> > > use posix stuff (split with regexp in 3rd arg), even if not
> > > all awk implementations are posix compliant. But who does
> > > not run gawk on MinGW and Cygwin?
> > 
> > OK, I think we can live with this for now.
> 
> If you want to be really portable (according to "info gawk") this
> is a possible (untested) change I suppose:
> 
> -      {split(\$ 0, a, /\||\r/); split(a[2], s)}
> +      {split(\$ 0, b, \"\r\"); split(b[1], a, \"\|\"); split(a[2], s)}
> 
> (but you did ask for POSIX...)

Oh.  Hmm, dunno.

> > A little note to keep in mind: before we release, we have to add a
> > statement that all of the new (even if documented) features are
> > experimental and bound to change.
> 
> Where to put that statement? NEWS?

Not sure.  In a state of enthusiasm a while ago I envisioned
doc/notes.texi as a place to put information that is necessary for users
of libtoolized packages.  Rationale: being also part of the manual, it's
readily accessible online.

A short note in NEWS wouldn't hurt either, though.

> >  (I'm not sure if going back to not
> > using $NM as dumpbin would be a better idea, and I want to keep this
> > option available to our discretion.)
> 
> Not sure either, seems to work though so what the hell? And it
> would also mean that my first ever awk program would be rejected,
> *sulk* :-)

I was not clear above:  I do _not_ want to rip out your awk script.
All I was wondering is whether it may in the end turn out to hurt users
if we changed the semantics of $NM.  Because I have meanwhile seen
packages that use the libtool-calculated value of $NM, and would break
with the "dumpbin" format.  In the case that both dumpbin and GNU nm are
available, that could be mitigated by setting $DUMPBIN to dumpbin, and
NM to nm, and adjusting export_symbols_cmds and the other places in
ltmain where $NM is used.

Clearer now?

> But I suppose the global_symbol_pipe for nm could be
> fixed to allow MSVC style symbols instead. I.e. symbols starting
> with and containing @ or ?, in addition to what gcc generates.
> Hmm, perhaps that is orthogonal? Maybe gcc also generates such
> symbols?
> 
> *testing*
> 
> $ cat foo.c
> __declspec(fastcall) int foo(int a) { return 0; }
> $ gcc -c foo.c -o foo.o
> $ nm foo.o
> 00000000 b .bss
> 00000000 d .data
> 00000000 t .text
> 00000000 T @address@hidden
> 
> Yups, orthogonal IMO, the problem with these symbols starting
> with @ is of course that global_symbol_to_cdecl is, how should I
> put it, harder to get right. The @4 part is significant and for
> C++ there's some real work to do...

Feel free to pursue this path.  :)
But, as per clarification of my thought above, it should not be
pressing, at least.  Right?  ;)