search for: __declspec

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 ../../in...

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

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

...irective is needed. I would name it dllimport_inline or something similar. While it makes sense to mimic MSVC behavior and MSDN doc for C++ codes, it is not very clear to me what should be the correct semantics when a C99 inline function carries a dllimport/dllexport declspec. For example, inline __declspec(dllimport) int foo() { return 100; } extern inline int foo(); Currently clang ignores the dllimport attribute, so what's left will be: inline int foo() { return 100; } extern inline int foo(); // this declaration demands an out-of-line definition The second declaration with the "extern&q...

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

...d 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 take this class as an example: struct __declspec(dllexport/dllimport) X { X() {} }; Such constructs with empty or simple inline functions can be found for example in Microsoft headers or even libc++ headers. Ignoring the dllexport/import attribute for such functions would seem most sensible (and can be implemented easily), but MSVC does t...

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

...LAC/export.h >>> @@ -69,6 +69,9 @@ >>> #elif defined(FLAC__USE_VISIBILITY_ATTR) >>> #define FLAC_API __attribute__ ((visibility ("default"))) >>> >>> +#elif defined (__WATCOMC__) && defined (__OS2__) >>> +#define FLAC_API __declspec(__cdecl) >>> + >>> #else >>> #define FLAC_API >> >> As I said, I don't know much about emx, but the wrong thing >> about the above is that it doesn't use dllexport therefore nothing >> will be exported with this. > > It should w...

...suggestions? Thanks and best regards, Florian (Stuttgart, GERMANY) #include <windows.h> #include "theora/theora.h" theora_state enc_state; int enc_width, enc_height; ogg_stream_state enc_stream; theora_state dec_state; int dec_width, dec_height; ogg_stream_state dec_stream; __declspec (dllexport) void startenc(int width, int height, int bitrate) { ogg_stream_init(&enc_stream, 290482); enc_width = width; enc_height = height; theora_info ti; theora_info_init(&ti); ti.width=width; ti.height=height; // must be /16 ti.frame_width=width; ti.frame_height=hei...

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 -------------- diff --git a/include/FLAC/export.h b/include/FLAC/export.h ind...

The attached set of patches adds support for OS/2 using Watcom compiler (tested with Open Watcom 1.9). My only interest was building a working dll (the last patch in the set adds a makefile for it), therefore I did not touch other places: If there is interest, I can do so. Regards. -- O.S. -------------- next part -------------- A non-text attachment was scrubbed... Name:

Óscar Fuentes <ofv at wanadoo.es> writes: > Michael Spencer <bigcheesegs at gmail.com> writes: > > The problem is that MSVC++ requires sprinkling > > __declspec(dllexport/dllimport) all over the code, and we really don't > > want to deal with maintaining that, as most developers have little to > > no experience with Windows DLLs. > > BTW, you don't put __declspec(dllexport) / __declspec(dllimport) on the > code, but macros that...

...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 determine whether we are building a DLL and only specify __declspec(dllexport) in that case. --- include/opus_defines.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/opus_defines.h b/include/opus_defines.h index 10ff838..11b172d 100644 --- a/include/opus_defines.h +++ b/include/opus_defines.h @@ -65,7 +65,7 @@ extern "C" {...

Owen Anderson <resistor at mac.com> writes: > On May 13, 2008, at 6:38 PM, Óscar Fuentes wrote: >> Last time I checked, building LLVM on Windows (MinGW or MSVC) did not >> produce dlls. >> >> Has this changed? >> >> I was succesful converting the libraries produced by MinGW to dlls, >> though. > > It's a little bit immaterial whether

GCC is smart enough to realize it doesn't return. That's because the declaration of abort() is decorated with __attribute__((__noreturn__)). So is GCC smarter than VC++? As it turns out, in VC++ the declaration of abort() is decorated with __declspec(noreturn). Whidbey is not stricter than 2003, it is merely buggier. VC++ has always complained about functions failing to return a value; this is not new in Whidbey. What is new is that it no longer pays attention to __declspec(noreturn). That is why it is difficult to justify supporting Whi...

Happy new year to all! The attached patch adds TLS support for x86_64-pc-win32 and x86-pc-win32. Implemented is the implicit TLS model (__declspec(thread) in Visual C++). Please review. Thanks! Regards Kai -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tls20120101.diff URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120101/b46065cb/attachment.ksh>

...educe the size of toolchain. I am getting LINK error 1181 about `lib\LLVM.lib` not found. After investigating, `lib\LLVM.lib` is supposed to be produced along with `bin\LLVM.dll`. `bin\LLVM.dll` is indeed produced, but it does not contain any exported symbols (10KB only) because LLVM does not use `__declspec(dllexport)` and `__declspec(dllimport)`, so lib.exe refuses to produce `lib\LLVM.lib`. If I just build static-linked Clang/LLVM (default), it works fine. Windows bot of WebAssembly waterfall is also affected: https://github.com/WebAssembly/waterfall/commit/2051fd4cdb2b4017e66dfcd70203d40f3d0b461d...

...the function. The visible global state is the set of all data that is not defined or referenced outside of the compilation scope, and their address is not taken." Phil On Thu, Nov 17, 2016 at 9:50 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > If I understood it correctly, __declspec(noalias) is not the same as > specifying restrict on each parameter. > > > > It means in the mentioned example a, b & c don't modify or reference any > global state, but they are free to alias one another. > > > > You could specify restrict on each one to indic...

...have > been able to build LLVM as a shared library using Autotools and GCC (through > MinGW) on Windows (as well as on Linux and Mac OS X), so it would really be > a shame if the same couldn’t be done using Visual C++… > > Cheers, Alan. The problem is that MSVC++ requires sprinkling __declspec(dllexport/dllimport) all over the code, and we really don't want to deal with maintaining that, as most developers have little to no experience with Windows DLLs. There may be a work around for this, which I partially implemented in the past. You have a script which automatically generates a ....

...; In file included from ..\lib\CORE\perl.h:3060: >>> In file included from .\win32thread.h:4: >>> ./win32.h(284,25) : error: 'selectany' can only be applied to data >>> items with external linkage >>> >> >> That line is: >> extern const __declspec(selectany) union { unsigned __int64 __q; double >> __d; } __PL_nan_u = { 0x7FF8000000000000UI64 }; >> >> If it's written like so, clang-cl accepts it: >> union U { unsigned __int64 __q; double __d; }; >> extern const __declspec(selectany) U __PL_nan_u = { >>...