[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Rosin
Subject: Re: extra exports with libtool (pr-msvc-support)
Date: Fri, 28 Aug 2009 09:23:43 +0200
User-agent: Thunderbird (Windows/20090812)

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:

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:

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]