[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: Sat, 29 Aug 2009 12:09:13 +0200
User-agent: Thunderbird (Windows/20090812)

Den 2009-08-28 19:02 skrev David Byron:
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.

I just tried this by adding

libfoo_la_LDFLAGS += -export-symbols symfile

and manually creating an empty file named symfile in the example I posted
earlier.  Now the only symbol that gets exported is the one decorated with
dllexport.  Thanks for the workaround.

You're welcome :-)

This does raise the question of what to do when the symbol file is in
conflict with the decorations...Need to think about this some more.

There is not much to do, I think. The decorations may export symbols
and the -export-* options may export symbols, and I don't think there
is any way to stop the decorated symbols from being exported. I think
it is perfectly fine to export all symbols which has been *either*
decorated or singled out with the -export-* options.

The only thing that needs to change is what to do if there are
no -export-* options. In that case, all symbols should be exported
if there are *no* decorations (after all, what point is it to create
a dll w/o any exported symbols?), but if there are at least one
decorated symbol, only the decorated symbols should be exported.

So, in other words, what's needed is some check that is only
effective when there are no -export-* option. The check should
detect if there are any decorated symbols in any of the objects,
and if there are it should stop libtool from digging through
the objects for (more) symbols to export.

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

Or if using a version of gcc that supports
__attribute__((__visibility__("default"))) and have decorated the symbols
with that, yes?

Probably, but I wouldn't know. The pr-msvc-support branch should
(hopefully) not change anything wrt to gcc...

     #elif BUILDING_LIBFOO && defined _MSC_VER
     #define LIBFOO_DLL_EXPORTED __declspec(dllexport)
     #elif defined _MSC_VER
     #define LIBFOO_DLL_EXPORTED __declspec(dllimport)

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.

I agree that merging pr-msvc-support should come first...which of course
begs the question, what can I do to help get pr-msvc-support merged?

There is concern that the patches will interfere with other
platforms, but I think the main showstopper is that libtool 2.2.8
has to be released. Until then, the window is firmly closed IIUC.
A while back some people stated that it was perhaps time to simply
merge the branch and see what probelms crop up. Knock wood...

That said, what you can do is compare testsuite results from the
branch on non-msvc-setups with results from the master branch.

In particular I think Linux (and other "big" platforms) would
be interresting as well as a Linux->mingw cross. Since it's been
a while it would perhaps also be interesting to check for
regressions with mingw and cygwin. And the upcoming cygwin 1.7
would also be interesting.

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.

So far preprocessor logic looks like this:

#  define LIBFOO_DLL_EXPORTED  __attribute__((__visibility__("default")))
#elif defined _MSC_VER
#    if defined(PIC)
#      if defined(LIBFOO_STATIC)
#        error "LIBFOO_STATIC conflicts with PIC"
#      else
#        define LIBFOO_DLL_EXPORTED __declspec(dllexport)
#      endif
#    else
#    endif
#  else
#    if defined(LIBFOO_STATIC)
#    else
#      define LIBFOO_DLL_EXPORTED __declspec(dllimport)
#    endif
#  endif

The _MSC_VER part of this is supposed to read:

1. If building a shared lib: __declspec(dllexport)
2. else if building a static lib: nothing
3. else if linking against a static lib: nothing
4. else (linking with a shared lib): __declspec(dllimport)

The trick is figuring out each of these things is happening.  Distinguishing
1 + 2 from 3 + 4 is easy:


Distinguishing 1 from 2 relies on -DPIC from libtool.

so all that remains is distinguishing 3 from 4 which depends on
LIBFOO_STATIC.  At the moment I have some configure-time logic that helps in
my environment, but it's not a general solution.  Basically, if someone
wants to link against a static libfoo, define LIBFOO_STATIC and hope that at
link time the static lib is available.  It's not ideal but I couldn't come
up with anything better.  Definitely open to suggestions here.

The trouble is of course that you don't know at compile time if
you are going to link with a static library or a shared library,
so there is no foolproof way to set LIBFOO_STATIC.


reply via email to

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