RE: extra exports with libtool (pr-msvc-support)

[David Byron]

> The portable way to specify which symbols you want to be
> visible (with libtool) is to use -export-symbols or
> -export-symbols-regex, IIUC. So, assuming you have some
> visibility requirements you are better off using those
> options anyway.

Lightbulb goes on a bit.  Whatever happens with __declspec(dllexport) and
msvc and -fvisibility/gcc, I still need to do something with -export-symbols
if I want to be portable to non-msvc/non-gcc platforms.

> Given that, and the fact that I have found no way to
> detect which symbols have been dllexport-decorated, it
> seemed best to export everything unless any of the above
> options are given.

I don't claim this is a proper solution, but there must be a way if the msvc
linker does it.  I tried compiling two different versions of this:

int     foo ( const char *bar );

int
foo ( const char *bar)
{
    printf("%s: %s\n",__FUNCTION__,bar);
    return 1;
}

and then again with __declspec(dllexport) in front of the declaration.

$ dumpbin /directives no_dllexport.obj
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file no_dllexport.obj

File Type: COFF OBJECT

   Linker Directives
   -----------------
   /DEFAULTLIB:"LIBCMT"
   /DEFAULTLIB:"OLDNAMES"

  Summary

           C .data
          8D .debug$S
          2F .drectve
          20 .text


$ dumpbin /directives with_dllexport.obj
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file with_dllexport.obj

File Type: COFF OBJECT

   Linker Directives
   -----------------
   /DEFAULTLIB:"LIBCMT"
   /DEFAULTLIB:"OLDNAMES"
   /EXPORT:_foo

  Summary

           C .data
          8D .debug$S
          3C .drectve
          20 .text

So there is a difference.  I don't know what's involved in teaching libtool
about it, but if someone points me in the right direction I'll take a look.

> gcc/ld does something equivalent if there are no dllexport
> decorations at all, at least with the options libtool is
> using (I think so anyway, but I may be wrong here too). So,
> I suspect that fewer and fewer packages will have the
> dllexport decorations and rely on auto-export instead.

My only comment to this is here:

http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shar
ed-Libraries.html

This page mentions that libtool uses a programmer-specified list of symbols
to define what's exported but then goes on to describe the gnulib method
that uses symbol decoration (my term).  And then at the end it says:

---
Note about other compilers: MSVC support can be added easily, by extending
the definition of the macro mentioned above, to something like this:

     #if BUILDING_LIBFOO && HAVE_VISIBILITY
     #define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
     #elif BUILDING_LIBFOO && defined _MSC_VER
     #define LIBFOO_DLL_EXPORTED __declspec(dllexport)
     #elif defined _MSC_VER
     #define LIBFOO_DLL_EXPORTED __declspec(dllimport)
     #else
     #define LIBFOO_DLL_EXPORTED
     #endif
---

Maybe I should have a discussion on the gnulib-list to add some
clarification to this page, but if people use a combination of gnulib and
libtool (or this gnulib mechanism and libtool), adding support for msvc
means more than adjusting this macro.

-DB