search for: dllexport

Hello, while improving and extending support for dllexport/import I have noticed that the current way these are implemented is problematic and I would like some input on how to proceed. Currently dllexport/dllimport is treated as linkage type. This conflicts with inlined functions because there is no linkage for the combination of both. On first though, c...

Hi Nico, Reid, and Anton, I missed the discussion when I implemented dllexport/dllimport for our local tree. I essentially implemented your approach#1. I was trying to avoid the various external_linkage + some_attribute approaches because it seems that external_linkage would imply the external linkage without the dllimport/dllexport semantics, and there may be existing compil...

Hi all, I am trying to use llvm-gcc to link shared libraries on windows/mingw32. When I try to link libraries that contain functions declared with __declspec(dllexport) someFunction(); I get the link error: Cannot export _someFunction: symbol not found Removing the declspec directive solves the problem, but this is not a very feasible solution for me. Using 'regular' gcc does not have this problem. Should I consider this a bug? Thanks, Ronald

> I am trying to use llvm-gcc to link shared libraries on windows/mingw32. > When I try to link libraries that contain functions declared with >  __declspec(dllexport) someFunction(); > > I get the link error: > >  Cannot export _someFunction: symbol not found dllexport declspec should be put on the function definition, in this example there is nothing to export - dllexport without function body is meaningless. -- With best regards, Anton Korobeyni...

If building a static library, marking symbols as dllexport causes them to be exported from the final executable. For example, run objdump -x opus_demo.exe on a --disabled-shared build and look for the export table; there should not be one in a normal Win32 .exe file, but when linking static libopus, the exe exports all of the opus_* public functions. Use...

...evel1.c:28: C:/Users/clang/libunwind/src/config.h:26:11: warning: keyword is hidden by macro definition [-Wkeyword-macro] #define static_assert(__b, __m) \ ^ C:/Users/clang/libunwind/src/UnwindLevel1.c:350:1: warning: redeclaration of '_Unwind_RaiseException' should not add 'dllexport' attribute [-Wdll-attribute-on-redeclaration] _Unwind_RaiseException(_Unwind_Exception *exception_object) { ^ C:/Users/clang/libunwind/include\unwind.h:174:5: note: previous declaration is here _Unwind_RaiseException(_Unwind_Exception *exception_object); ^ C:/Users/clang/libunwind/src/U...

On 23.04.2013 19:10, Gao, Yunzhong wrote: > I missed the discussion when I implemented dllexport/dllimport for our local tree. I > essentially implemented your approach#1. I was trying to avoid the various > external_linkage + some_attribute approaches because it seems that external_linkage > would imply the external linkage without the dllimport/dllexport semantics, and there > ma...

> > I am trying to use llvm-gcc to link shared libraries on windows/mingw32. > > When I try to link libraries that contain functions declared with > >  __declspec(dllexport) someFunction(); > > > > I get the link error: > > > >  Cannot export _someFunction: symbol not found > dllexport declspec should be put on the function definition, in this > example there is nothing to export - dllexport without function body > is meaningless. Ok,...

On 01/23/17 01:01 AM, Erik de Castro Lopo wrote: > Dave Yeo wrote: > >> >GCC supports __declspec(dllexport) though it still needs a def file, >> >with no exports. Libtool doesn't currently and as flac uses libtool... > So you're happy with this patch? > > http://lists.xiph.org/pipermail/flac-dev/2017-January/006170.html > No. Lots of errors such as ../../include/FLAC...

The following patch changes export.h so that the dllimport/dllexport attributes work with mingw/mingw-w64 and others: - changes _declspec keyword to __declspec: the former may not be defined by some toolchains. - changes the _MSC_VER condition to universally _WIN32: MSVC, as well as GCC supports this. Attached patch: declspec.diff Regards. -- O.S. -----------...

Hi Nico, Thank you for your feedback. I'll try to answer your questions below. > What problems do you expect with another approach? I have a local > prototype that removes dllimport/export as linkage and uses function > attributes and an extension to globals. I decorate dllexported functions with > the Used attribute and it seems to work fine. This allows such functions to > have linkonce_odr and weak_odr linkage and not be discarded. My primary concern is what needs to be added to preserve current compiler behavior where necessary. All the other approaches appear to...

On 01/22/17 02:00 PM, Ozkan Sezer wrote: > Question: Does emx support __declspec(dllexport) so I can adjust > these changes? Because the emx build of the dll seems to have > exported_everything_ :( GCC supports __declspec(dllexport) though it still needs a def file, with no exports. Libtool doesn't currently and as flac uses libtool... Dave

...invasive way, but adds new linkage types > to an already large list. It also will require modifying all the existing code wrt linkonce semantics of "dllexpport_odr" and "dllimport_odr" stuff. Which might be nontrivial (it's hard to say anything in advance). After all dllexport is basically the same as external linkage and dllimport - as well (but just decl). So, instead of adding new entities here we'd think about the overall picture once again and make dllexport / dllimport as some sort of flags? Target-specific attributes seems the best solution here, but they ca...

On Wed, Oct 21, 2015 at 6:38 PM, Daniel Verkamp <daniel at drv.nu> wrote: > If building a static library, marking symbols as dllexport causes them > to be exported from the final executable. For example, run > objdump -x opus_demo.exe on a --disabled-shared build and look for the > export table; there should not be one in a normal Win32 .exe file, but > when linking static libopus, the exe exports all of the opus_* pub...

Ozkan Sezer wrote: > flac.exe built with mingw with or without the dllimport/dllexport patch > always requires libFLAC-8.dll (because flac/Makefile.am has libFLAC.la > in flac_LDADD and not libFLAC-static.la), and the patch doesn't make it > any more or any less dependent on any 'foreign' dlls: the patch doesn't > change the existent situation in that rega...

...type, so any > existing compiler codes that deal with that particular linkage type will > potentially have different behavior. Right. But normally LLVM API does not provide backward compatibility. The point is to make good code / API, not to fix the broken one with hinges and supports. > DLLExportLinkage with ExternalLinkage+DLLExport_attribute, then > codes that check hasExternalLinkage() will affect DLLExportLinkage > symbols as well, which may or may not be the right thing. In this case everything should work fine. If the behavior will be changed, then we'll find some subtle bug...

...--------- diff --git a/include/FLAC/export.h b/include/FLAC/export.h index 2232b41..185c282 100644 --- a/include/FLAC/export.h +++ b/include/FLAC/export.h @@ -59,11 +59,11 @@ #if defined(FLAC__NO_DLL) #define FLAC_API -#elif defined(_MSC_VER) -#ifdef FLAC_API_EXPORTS -#define FLAC_API _declspec(dllexport) +#elif defined(_WIN32) +#if defined(FLAC_API_EXPORTS) || defined(DLL_EXPORT) +#define FLAC_API __declspec(dllexport) #else -#define FLAC_API _declspec(dllimport) +#define FLAC_API __declspec(dllimport) #endif #elif defined(FLAC__USE_VISIBILITY_ATTR) diff --git a/include/FLAC++/export.h b/incl...

It seems that the DLL export directives for __cdecl and __stdcall functions are not correctly written in asm output. For example, when declaring a function like this: __declspec(dllexport) int __cdecl exportFunc1(int c); ASM output is: .def _exportFunc1; .scl 2; .type 32; .endef .text .globl _exportFunc1 .align 16, 0x90 _exportFunc1: movl 4(%esp), %eax ret .section .drectve,"r" .ascii " -export:_exportFunc1" GNU assembler fails with the mess...

...nts then flac.exe requires > libFLAC-8.dll, > which in turn requires libgcc_s_sjlj-1.dll. Adding "--disable-shared" makes > flac.exe standalone: it doesn't need those libraries thst are foreign to > Windows systems). flac.exe built with mingw with or without the dllimport/dllexport patch always requires libFLAC-8.dll (because flac/Makefile.am has libFLAC.la in flac_LDADD and not libFLAC-static.la), and the patch doesn't make it any more or any less dependent on any 'foreign' dlls: the patch doesn't change the existent situation in that regard. If I'm missi...

Erik de Castro Lopo wrote: > Ozkan Sezer wrote: > >> My apologies, obviously sent an old testing patch. Correct one is >> attached (declspec2.diff). Compilation tested using MinGW (gcc-3.4.5, >> binutils-2.20), and MinGW-w64 (gcc-4.5.4, binutils-2.21.90.) > > lvqcl, > > Can you please validate this new patch? It works, but only if i call ./configure without