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

[Peter Rosin]

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

> > >      #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
> > 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:
>
> #if defined(BUILDING_LIBFOO) && HAVE_VISIBILITY
> #  define LIBFOO_DLL_EXPORTED  __attribute__((__visibility__("default")))
> #elif defined _MSC_VER
> #  if BUILDING_LIBFOO
> #    if defined(PIC)
> #      if defined(LIBFOO_STATIC)
> #        error "LIBFOO_STATIC conflicts with PIC"
> #      else
> #        define LIBFOO_DLL_EXPORTED __declspec(dllexport)
> #      endif
> #    else
> #      define LIBFOO_DLL_EXPORTED
> #    endif
> #  else
> #    if defined(LIBFOO_STATIC)
> #      define LIBFOO_DLL_EXPORTED
> #    else
> #      define LIBFOO_DLL_EXPORTED __declspec(dllimport)
> #    endif
> #  endif
> #else
> #  define LIBFOO_DLL_EXPORTED
> #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:
>
> libfoo_la_CPPFLAGS += -DBUILDING_UTILS
>
> 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.

Cheers,
Peter