similar to: [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

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 --------------

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:

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

> 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

Here's another one. On Thu, Nov 2, 2017 at 9:54 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > We're getting there... Some minor comments: > > 1) The public header file should not have an > #ifdef ENABLE_EXPERIMENTAL_AMBISONICS > since that would require the user code to define it. > > Done > 2) Why do you have #define

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

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

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

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

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

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

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 >

Hello, Opus currently always sets default visibility for exported functions when OPUS_BUILD macro is set. However, it is not a desirable behavior when libopus is statically linked with the final binary (e.g. libxul.so in firefox), since all symbols get exported even with -fvisibility=hidden. In firefox, this problem is partially solved by wrapping translation units with #pragma visibility

Ensure that elements of the array that correspond to unavailable features are set to NULL; previously, they would be left uninitialized. Since the corresponding names array elements were explicitly set to NULL, the uninitialized callback pointers would not actually be dereferenced; however, the uninitialized callbacks elements would still be read in vp_find_vqs_msix() and used to calculate the

Ensure that elements of the array that correspond to unavailable features are set to NULL; previously, they would be left uninitialized. Since the corresponding names array elements were explicitly set to NULL, the uninitialized callback pointers would not actually be dereferenced; however, the uninitialized callbacks elements would still be read in vp_find_vqs_msix() and used to calculate the

With gcc-3.3, building opus fails with the following error: In file included from silk/float/pitch_analysis_core_FLP.c:38: celt/pitch.h:53: error: invalid use of `restrict' This is because __restrict is broken with gcc < 3.4. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6392 Therefore, disable restrict with gcc versions older than 3.4. --- include/opus_defines.h | 6 +++++- 1 file

Ensure that elements of the callbacks array that correspond to unavailable features are set to NULL; previously, they would be left uninitialized. Since the corresponding names array elements were explicitly set to NULL, the uninitialized callback pointers would not actually be dereferenced; however, the uninitialized callbacks elements would still be read in vp_find_vqs_msix() and used to

Ensure that elements of the callbacks array that correspond to unavailable features are set to NULL; previously, they would be left uninitialized. Since the corresponding names array elements were explicitly set to NULL, the uninitialized callback pointers would not actually be dereferenced; however, the uninitialized callbacks elements would still be read in vp_find_vqs_msix() and used to

Hi Drew, I've had some time to dig more deeply into your patch. Here's some more in-depth comments: 1) I note that your OpusMSEncoder struct in private.h adds a subframe_mem[] that's not in opus_multistream_encoder.c. I assume it's due to a merge problem (that field was removed some time ago), but can you confirm/fix the issue? 2) I noticed your patch adds many OPUS_EXPORT