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

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

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 >

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

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

On Fri, Jul 24, 2015 at 12:05 PM, Nico Weber <thakis at chromium.org> wrote: > On Thu, Jul 16, 2015 at 8:08 AM, Nico Weber <thakis at chromium.org> wrote: > >> On Wed, Jul 15, 2015 at 10:45 AM, Russell Wallace < >> russell.wallace at gmail.com> wrote: >> >>> Basic test results on Windows 7, visual studio 2013 (64 bit): >>> >>>

Ó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

Ok, I have just found the cause of the error messages I am getting, and it now makes sense to me why the 'normal' build works fine on Windows, Linux and OS X, and why my personal build works on Linux and OS X, but not on Windows. However, I still don't understand why I am getting the error messages I am getting. Anyway, it has to do with wanting to export some classes and function,

On Fri, Apr 6, 2012 at 6:15 PM, Alan Garny <agarny at hellix.com> wrote: > Hi, > > From what I have seen on this mailing list and elsewhere, it would seem that > it isn’t possible to build LLVM as a shared library using Visual C++. Still, > I would imagine that quite a few people are or would be interested in it, > so… is there any plan to support this any time soon? This,

Óscar Fuentes <ofv at wanadoo.es> wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.comp.compilers.llvm.devel as well. > > nobled <nobled at dreamwidth.org> writes: > >> The LLVM 2.7 release notes say you can use ./configure --enable-shared >> to build LLVM as a shared library (libLLVM2.7.so), and the LLVM tools

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

> 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

I am trying to build Clang/LLVM with -DLLVM_BUILD_LLVM_DYLIB=ON and -DLLVM_LINK_LLVM_DYLIB=ON to reduce 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

The LLVM 2.7 release notes say you can use ./configure --enable-shared to build LLVM as a shared library (libLLVM2.7.so), and the LLVM tools will link against that instead of including the static libraries, so I was wondering: Is there a way to configure LLVM the same way using CMake (so it can work on Windows)? In the other direction, is there an equivalent ./configure flag to setting

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

Hi, >From what I have seen on this mailing list and elsewhere, it would seem that it isn't possible to build LLVM as a shared library using Visual C++. Still, I would imagine that quite a few people are or would be interested in it, so. is there any plan to support this any time soon? This, unless it's already supported in some way or another which I am not aware of.? I have been

On Wed, Jul 15, 2015 at 10:45 AM, Russell Wallace <russell.wallace at gmail.com > wrote: > Basic test results on Windows 7, visual studio 2013 (64 bit): > > Build clang with visual studio - okay > > Build clang with itself - okay > > Build Python - okay > > Build Ruby - fails on conftest.c, but 3.6 also failed so this is not a > regression bug > > Build

Folks, there is an issue pretty buried in the commits list that I suspect should have wider visibility. See r262188 and subsequent discussion. To summarize: it appears that mingw32 was unable to correctly produce a static data member when instantiated as a base class. The "fix" is to then explicitly instantiate the base class separately from its use in a base class. I think this is

On Fri, Mar 23, 2012 at 9:45 PM, JonY <jon_y at users.sourceforge.net> wrote: > On 3/23/2012 13:59, Glenn McCord wrote: >> Hi. I'm trying to get a project linking to libFLAC_static.lib but I >> get linker errors such as the following. >> >> The __imp__ prefix seems to imply that some kind of .dll usage is >> happening, which it shouldn't. >>