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

[Peter Rosin]

Den 2009-08-27 18:40 skrev 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:

*snip interesting dumpbin -directives stuff*

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

Indeed, good to know. Your input made me realize that it
should be possible to work around the extra exports with
something like -export-symbols-regex=probably_not_a_match
or with an empty SYMFILE and -export-symbols=SYMFILE

Untested though, but the linker should then pick up the
symbols to export from the directives in the object files,
and libtool will not add any more exports.

But you better only add the above options if you are indeed
using MSVC and have decorated the symbols, or else you risk
ending up with a severly crippled library...

An automatic solution has this additional requirements (if
you ask me):

        If you specify neither -export-symbols nor
        -export-symbols-regex and do use at least one
        dllexport decoration, only the dllexport
        decorated symbols should be exported.

So, if the use -export-symbols or -export-symbols-regex or if
you don't have any dllexport decorations at all, the current
behaviour is the desired behaviour.

Regarding pointers into hacking libtool to do the above, I'm
probably not the best source. But look in libltdl/m4/libtool.m4
and libltdl/config/ltmain.m4sh near the use of the variable
export_symbols_cmds. But before you do anything major, make
sure you are prepared to assign the copyrights of the new
code to the FSF...

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

Extending gnulib with this can only be done after pr-msvc-support has
been merged, methinks. Until then, I don't know if it's worth spending
time on it. But there's still the unresolved issue that
__declspec(dllimport) is wrong if you are linking with a static
library, so the above isn't entirely correct anyway.

Cheers,
Peter