[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions on exporting functions from a shared library

From: Jef Driesen
Subject: Re: Questions on exporting functions from a shared library
Date: Wed, 08 Oct 2008 10:24:46 +0200
User-agent: Thunderbird (X11/20080925)

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' > $@
  $(CPP) -P - < mylib.symbols | sed -e '/^$$/d' > $@

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, 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 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 PIC
#    define API EXPORT
#  else
#    define API
#  endif
#    define API IMPORT
#  else
#    define API
#  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, 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).


reply via email to

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