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

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

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.

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

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

I agree with this.

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

I also agree with this in spirit but considering -export-symbols with an
empty file makes the language to specify this precisely more complex I
think.

> But before you do anything major, make sure you are
> prepared to assign the copyrights of the new code to the
> FSF...

Thanks for the pointer.  Yes, I'm prepared to assign copyright.

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

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

-DB