> The portable way to specify which symbols you want to be > visible (with libtool) is to use -export-symbols or > -export-symbols-regex, IIUC. So, assuming you have some > visibility requirements you are better off using those > options anyway.
Lightbulb goes on a bit. Whatever happens with __declspec(dllexport) and msvc and -fvisibility/gcc, I still need to do something with -export-symbols if I want to be portable to non-msvc/non-gcc platforms. > Given that, and the fact that I have found no way to > detect which symbols have been dllexport-decorated, it > seemed best to export everything unless any of the above > options are given. I don't claim this is a proper solution, but there must be a way if the msvc linker does it. I tried compiling two different versions of this: int foo ( const char *bar ); int foo ( const char *bar) { printf("%s: %s\n",__FUNCTION__,bar); return 1; } and then again with __declspec(dllexport) in front of the declaration. $ dumpbin /directives no_dllexport.obj Microsoft (R) COFF/PE Dumper Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file no_dllexport.obj File Type: COFF OBJECT Linker Directives ----------------- /DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" Summary C .data 8D .debug$S 2F .drectve 20 .text $ dumpbin /directives with_dllexport.obj Microsoft (R) COFF/PE Dumper Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file with_dllexport.obj File Type: COFF OBJECT Linker Directives ----------------- /DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" /EXPORT:_foo Summary C .data 8D .debug$S 3C .drectve 20 .text So there is a difference. I don't know what's involved in teaching libtool about it, but if someone points me in the right direction I'll take a look. > gcc/ld does something equivalent if there are no dllexport > decorations at all, at least with the options libtool is > using (I think so anyway, but I may be wrong here too). So, > I suspect that fewer and fewer packages will have the > dllexport decorations and rely on auto-export instead. My only comment to this is here: http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shar ed-Libraries.html This page mentions that libtool uses a programmer-specified list of symbols to define what's exported but then goes on to describe the gnulib method that uses symbol decoration (my term). And then at the end it says: --- Note about other compilers: MSVC support can be added easily, by extending the definition of the macro mentioned above, to something like this: #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 --- Maybe I should have a discussion on the gnulib-list to add some clarification to this page, but if people use a combination of gnulib and libtool (or this gnulib mechanism and libtool), adding support for msvc means more than adjusting this macro. -DB _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool