search for: dllexporting

Displaying 20 results from an estimated 169 matches for "dllexporting".

2013 Mar 26
6
[LLVMdev] Feedback required on proper dllexport/import implementation
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, combining both doesn't make sense, but
2013 Apr 23
0
[LLVMdev] Feedback required on proper dllexport/import implementation
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 compiler codes that rely on
2009 Oct 11
3
[LLVMdev] Problems linking shared library with __declspec(dllexport)
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
2009 Oct 11
0
[LLVMdev] Problems linking shared library with __declspec(dllexport)
> 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
2015 Oct 22
3
[PATCH] win32: only use dllexport when building DLL
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 the libtool-defined DLL_EXPORT flag to
2020 Aug 15
5
Supporting libunwind on Windows 10 (32bit; 64bit) for MSVC and Clang
Hello. I was trying to compile https://github.com/llvm/llvm-project/tree/master/libunwind using: - MSVC - Clang I wasn't able to configure this project for using MSVC (directly or via clang-cl): >cmake -G Ninja -DLLVM_PATH="C:/Users/clang/llvm-project-10.0.1/llvm" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX="C:\Users\clang\libunwind_llvm" ../libunwind --
2013 Apr 23
2
[LLVMdev] Feedback required on proper dllexport/import implementation
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 > may
2009 Oct 12
1
[LLVMdev] Problems linking shared library with __declspec(dllexport)
> > 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 >
2017 Jan 23
1
os/2 support using Watcom
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
2014 May 24
2
make dllimport/dllexport attributes work with mingw (and others)
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. -------------- next part --------------
2013 May 07
0
[LLVMdev] Feedback required on proper dllexport/import implementation
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 >
2017 Jan 23
4
os/2 support using Watcom
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
2013 Mar 27
0
[LLVMdev] Feedback required on proper dllexport/import implementation
Hi Nico, We already discussed this on IRC, I just wanted to mention something explicitly. > 1. Add additional linkage type(s) for the combinations to > GlobalValue::LinkageTypes. > > This appears to be the least 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
2016 Apr 09
0
[PATCH] win32: only use dllexport when building DLL
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
2014 May 25
1
make dllimport/dllexport attributes work with mingw (and others)
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 regard. If
2013 May 07
1
[LLVMdev] Feedback required on proper dllexport/import implementation
> My primary concern is what needs to be added to preserve current > compiler behavior where necessary. All the other approaches appear > to involve adding flags or attribute to an existing linkage 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
2014 May 24
2
make dllimport/dllexport attributes work with mingw (and others)
On 5/24/14, lvqcl <lvqcl.mail at gmail.com> wrote: > Ozkan Sezer <sezeroz at gmail.com> ?????(?) ? ????? ?????? Sat, 24 May 2014 > 10:16:15 +0400: > >> - changes the _MSC_VER condition to universally _WIN32: MSVC, as well >> as GCC supports this. > > MSYS/MinGW 4.8.3, 4.9.0 can't compile code from git after this patch: > > format.c:47:22: error:
2012 Feb 07
2
[LLVMdev] x86 asm dllexport output for mingw targets
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
2014 May 25
0
make dllimport/dllexport attributes work with mingw (and others)
On 5/25/14, lvqcl <lvqcl.mail at gmail.com> wrote: > 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, >>
2014 May 25
2
make dllimport/dllexport attributes work with mingw (and others)
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