[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: extra exports with libtool (pr-msvc-support)
From: |
David Byron |
Subject: |
RE: extra exports with libtool (pr-msvc-support) |
Date: |
Thu, 27 Aug 2009 09:40:09 -0700 |
> 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