Re: Questions on exporting functions from a shared library

[Jef Driesen]

Ralf Wildenhues wrote:
> * Jef Driesen wrote on Thu, Oct 02, 2008 at 05:08:55PM CEST:
> > mylib.exp: mylib.symbols
> > if XYZ
> >   $(CPP) -P -DMYLIB_XYZ_SUPPORT - < mylib.symbols | sed -e '/^$$/d' > $@
> > else
> >   $(CPP) -P - < mylib.symbols | sed -e '/^$$/d' > $@
> > endif
> >
> > CLEANFILES = mylib.exp
> > EXTRA_DIST = mylib.symbol
> >
> > One of the downside of this method is that I need to maintain the  
> > separate symbols file (not a real issue). But more important is that  
> > this setup is not supported by the msvc compiler. That compiler does not  
> > export any function by default, unless a DEF file or the dllexport  
> > attribute is used. But I don't know if it is possible to do a similar  
> > trick for msvc, and generate the DEF file on the fly. And I don't want  
> > to maintain two almost identical symbol files.
>
> Can you just ship the symbol file in the source tarball, and use the
> shipped file for msvc?  That hampers development of the code with msvc,
> but should work for distribution.

I am shipping the symbols file. In my Makefile.am, I have

EXTRA_DIST = mylib.symbol

to make sure the file is included in the tarball.

But with this approach, msvc users will need to (manually) generate a 
DEF file from it. And that is something I would like to avoid.

> > Note: How do can I detect whether the visibility attribute is supported?
>
> For example with the gnulib module 'visibility'.

How do I use this visibility.m4 file? Do I need to copy its contents 
into my configure.ac file?

> > where MYLIB_BUILD is always defined when building the library, and  
> > MYLIB_STATIC should be defined for static building and linking.
>
> Note that libtool defines PIC for you for the nonstatic code.

That macro is only defined when building the library, not when linking 
against it. But since it is possible to link against a shared library 
without any import attribute (just as I'm doing now with a symbols 
file), I could make that optional by requiring the user to define a 
MYLIB_DLLIMPORT when wanting to link against the DLL and take advantage 
of the dllimport attribute. Something like this:

#ifdef MYLIB_BUILD
#  ifdef PIC
#    define API EXPORT
#  else
#    define API
#  endif
#else
#  ifdef MYLIB_DLLIMPORT
#    define API IMPORT
#  else
#    define API
#  endif
#endif

This the way, the MYLIB_BUILD macro is still required, but I think it 
will also guard the PIC macro when another shared library wants to link 
against my shared library, in which case the PIC macro would also be 
defined (for the other other library).

BTW, what is the reason that when I use mylib_la_CFLAGS = -DMYLIB_BUILD, 
in Makefile.am, all my object files are named "mylib_la-myfile.o" 
instead of the regular "myfile.o"?

> > BTW, is it possible to force automake to link my examples against the  
> > static library, in case both the static and shared library are build?  
> > Now I'm using a separate build tree with ./configure --disable-shared,  
> > thus affecting the complete project, when I need statically linked 
> > examples.
>
> You can avoid using a separate tree, by adding -static to the link flags
> (either to each testprog_LDFLAGS, or AM_LDFLAGS if all tests reside in a
> separate directory).

Thanks!