RE: Libtool: Microsoft dumpbin as name lister

[Peter Ekberg]

Ralf Wildenhues wrote:
> Sent: Wednesday, August 17, 2005 20:54
> To: Peter Ekberg
> Cc: address@hidden
> Subject: Re: Libtool: Microsoft dumpbin as name lister
> 
> Hi Peter,
> 
> * Peter Ekberg wrote on Mon, Aug 15, 2005 at 11:20:58PM CEST:
> > 
> > I have forked out this patch (against HEAD) from my MSVC work.
> 
> Good work.

Thanks!

> Missing bits below, plus: We advertise `NM' in libtool.texi as BSD
> compatible, and show how its output looks like (two different 
> sections).
> We should update that, if possible.  If you would not like to do that,
> I could do it if I knew how dumpbin's output looked like and how it
> behaved.  As you noticed already, it's not present in the 
> 2003 version,
> and I can't find an older accessible msvc to try out.

I have attached (to prevent distortions) the output from
"dumpbin -symbols" after compiling the following with
cl -c -o sym.obj sym.c

-----8<-----
#include <windows.h>
int global_vardef;
int global_vardef_init = 1;
extern int extern_vardecl;
static int static_vardef;
static int static_vardef_init = 1;
extern __declspec(dllexport) int export_vardef;
int export_vardef;
extern __declspec(dllexport) int export_vardef_init;
int export_vardef_init = 1;
extern __declspec(dllexport) int export_vardecl;
extern __declspec(dllimport) int import_vardecl;

static void static_funcdef(void) {}
extern void extern_funcdecl(void);
extern __declspec(dllexport) void export_funcdef(void);
void export_funcdef(void) {}
extern __declspec(dllexport) void export_funcdecl(void);
extern __declspec(dllimport) void import_funcdecl(void);

void global_funcdef(void)
{
        int local_var;

        extern_funcdecl();
        export_funcdecl();
        import_funcdecl();

        local_var  = extern_vardecl;
        local_var += export_vardecl;
        local_var += import_vardecl;
}
-----8<-----

nm on that object file gives:
$ nm sym.obj
00000000 d .data
00000000 i .drectve
00000000 t .text
000a2306 a @comp.id
         U __imp__import_funcdecl
         U __imp__import_vardecl
         U _export_funcdecl
00000000 T _export_funcdef
         U _export_vardecl
00000004 C _export_vardef
00000008 D _export_vardef_init
         U _extern_funcdecl
         U _extern_vardecl
00000005 T _global_funcdef
00000004 C _global_vardef
00000000 D _global_vardef_init
00000004 d _static_vardef_init

Regarding dumpbin not being present in the 2003 version, I
*think* it's just missing from the free toolkit and that it is
still going strong in "the real" releases of Visual Studio.

> Also, there seem to be third-party programs named `dumpbin'.  
> Does your1> test av   oid them or do they work with your macro?  Are
they in
> wide-spread use?  (We can just wait till someone reports a bug, if you
> don't know; but maybe you do, or I just missed that info.)

Hmm, I was not aware of other dumpbins, so if they are similar
there might be a problem.

But, as the test is currently, the located dumpbin must
not choke on the -symbols option and it must output a line
with both "External" and "some_variable" on it. So false
positives seem unlikely to me, but the test can always be
hardened. If the test is negative the found dumpbin is
assumed to support the BSD nm interface, which is probably
more likely to happen. But as you noted below, nm must be
Missing for that to happen and in that case you were toast
previously as
well...

> Another remark: we change the interface provided by 
> libtool.m4.  Please
> update the serial number of the file.  Strictly speaking, 
> your patch is
> an incompatible change, too (as the documented interface, i.e., output
> of $NM, is not guaranteed any more), but in practice I think it is a
> good compromise: before, without any nm, things would not 
> have worked at
> all.  So I consider that OK.

Ok.

> Lastly, can I ask a favor of you?  I've seen your other patches, and
> hate to delay them even longer, but I won't be able to test 
> them enough
> before the weekend.  So I'd like you to not use the 72 hour rule.
> Thanks.  I'll try to get to them as quickly as possible, if 
> nobody else
> has before.

No problem at all, I'm just beginning to feel that I have soon
filled the quota for at least some people with very similar-
looking patches, and that people are perhaps no longer reading.
So I just pictured your request for a 2nd maintainer to chip in
disappearing in the bitbucket...

> Cheers,
> Ralf
> 
> > 2005-08-15  Peter Ekberg  <address@hidden>
> > 
> >     * m4/libtool.m4 (LT_PATH_NM): If nm is not found on the
> >     path, look for dumpbin. Then check if $NM responds as
> >     dumpbin would and if not, assume the name lister is
> >     BSD nm compatible.
> >     (_LT_CMD_GLOBAL_SYMBOLS): If the name lister uses the
> >     dumpbin interface, adjust the test to find a working
> >     global_symbol_pipe.
> 
> 
> | +AC_CACHE_CHECK([for BSD-compatible nm], lt_cv_path_NM,
> 
> Maybe rather 'for BSD- or MS-compatible name lister (nm)'?

Done, updated patch attached.

2005-08-18  Peter Ekberg  <address@hidden>

        * m4/libtool.m4: Bump serial number.
        (LT_PATH_NM): If nm is not found on the path, look for
        dumpbin. Then check if $NM responds as dumpbin would
        and if not, assume the name lister is BSD nm compatible.
        (_LT_CMD_GLOBAL_SYMBOLS): If the name lister uses the
        dumpbin interface, adjust the test to find a working
        global_symbol_pipe.
        * doc/libtool.texi: Document $NM to possibly be MS
        dumpbin compatible, and also document the format of the
        relevant output from MS dumpbin.

Regarding the changes to the documentation, I have not tested
it, so it just might look like crap or generally suck in other
ways. Feel free to edit or suggest fixes.

Cheers,
Peter

sym-dumpbin.txt
Description: sym-dumpbin.txt

head-dumpbin-as-name-lister-2.patch
Description: head-dumpbin-as-name-lister-2.patch