Re: relocatable-lib-lgpl: Don't export symbols from static MSVC .obj files

[Bruno Haible]

Hi Simon,

> > -#define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
> > -#elif (defined _WIN32 && !defined __CYGWIN__) && BUILDING_SHARED && 
> > BUILDING_LIBFOO
> > -#define LIBFOO_DLL_EXPORTED __declspec(dllexport)
> > -#elif (defined _WIN32 && !defined __CYGWIN__) && BUILDING_SHARED
> > -#define LIBFOO_DLL_EXPORTED __declspec(dllimport)
> > +# define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
> > +#elif (defined _WIN32 && !defined __CYGWIN__) && @@BUILDING_SHARED@@ && 
> > BUILDING_LIBFOO
> > +# if defined DLL_EXPORT
> > +#  define LIBFOO_DLL_EXPORTED __declspec(dllexport)
> > +# else
> > +#  define LIBFOO_DLL_EXPORTED
> > +# endif
> > +#elif (defined _WIN32 && !defined __CYGWIN__) && @@BUILDING_SHARED@@
> > +# define LIBFOO_DLL_EXPORTED __declspec(dllimport)
> 
> The idea is that this code snippet would go into the public
> header file that is installed in /usr/include on people's system

Yes, exactly. The previous use of BUILDING_SHARED as a C macro would only
work with package-internal shared libraries (e.g. libgettextlib or
libgettextsrc in GNU gettext), not with documented shared libraries (e.g.
libintl or libgettextpo in GNU gettext).

> so using @@BUILDING_SHARED@@ in it does not seem to work.

Obviously @BUILDING_SHARED@ needs to be substituted before the file is
installed in /usr/include. That's what I meant by documenting
"BUILDING_SHARED is an Autoconf variable" and "AC_SUBST([BUILDING_SHARED])".

> I think it would
> be acceptable for the public header file to default to setting things up
> for using a shared library, but allow the user to specify a
> -DLIBFOO_STATIC_BUILD=1 or similar if she wants to build with a static
> libfoo.

I don't think this will work in practice. If a user has to define or
not define LIBFOO_STATIC_BUILD, LIBBAR_STATIC_BUILD, LIBXYZ_STATIC_BUILD,
and things crash if the define is not consistent with how she then later
links, it's too much of a hassle.

We install *one* header file foo.h both for libfoo.so and libfoo.a, and it
should therefore work with either.

For functions, the above definitions work:
  - In libfoo.so/.dll/.dll.lib the function is marked __declspec(dllexport)
    and thus exported, and the user gets it marked __declspec(dllimport).
    As it should be.
  - In libfoo.a/.lib the function is not marked __declspec, thus not exported.
    The user gets it marked __declspec(dllimport). MSVC warns but does the
    right thing.

For variables, in libfoo.a/.lib it should be marked with __declspec(dllexport)
as well (because there is only *one* header file foo.h and MSVC does not
do the right thing for variables like it does for functions). But to keep
things simple (and since variables in shared library APIs are generally to
be avoided) I didn't mention this in the doc.

> If there is no way in CPP to know if we're building code that will use
> libfoo as a shared library (symbols DLL_EXPORT or PIC?)

DLL_EXPORT and PIC are precisely these symbols, defined as *building* time,
not at consumption time.

Bruno