similar to: [LLVMdev] x86 asm dllexport output for mingw targets

Alen, > It seems that the DLL export directives for __cdecl and __stdcall > functions are not correctly written in asm output. So, this is for all functions then, right? :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

https://bugs.freedesktop.org/show_bug.cgi?id=49815 Bug #: 49815 Summary: nouveau segfaults in p_atomic_dec_zero Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component:

https://bugs.freedesktop.org/show_bug.cgi?id=48890 Bug #: 48890 Summary: dmesg full of DATA_ERROR SEMANTIC_PTSZ_OVER_LIMIT errors on nouveau driver Classification: Unclassified Product: xorg Version: git Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal

Hi, I'm playing around with LLVM and stumbled upon this issue while while performing "make install". The build itself was successful. I'm using the latest git version. #make install -- Installing: /home/alesko/llvm-install/bin/llvm-mc -- Installing: /home/alesko/llvm-install/bin/sancov -- Installing: /home/alesko/llvm-install/bin/opt -- Installing:

> On Dec 9, 2015, at 1:56 PM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Not sure, but my guess is that the ocaml documents targets aren’t being included in the ALL target, which is resulting in them not being built before the install action. I think you're right. Running "make ocaml_doc" then rerunning "make install" completed the

https://bugs.freedesktop.org/show_bug.cgi?id=70212 Priority: medium Bug ID: 70212 Assignee: nouveau at lists.freedesktop.org Summary: glxinfo triggers assert in cso_release_all after 3f0627c2ad6 Severity: normal Classification: Unclassified OS: All Reporter: awatry at gmail.com

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

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

Hi, there are a couple of possible issues around array_pod_sort from STLExtras.h . Firstly, qsort() needs a comparator that returns zero on equal inputs. ConstantIntSortPredicate in SimplifyCFG.cpp (where the sort is being used to bring duplicate values together) fails this requirement. All the others look ok. Secondly, on Windows qsort() needs its callback to use __cdecl calling convention,

> Yuck... what about the C runtime? I can compile a C/C++ program on Unix > and copy the bytecode file over to Windows and then (eventually) > generate assembler that NASM can turn into a binary. But what to link > against? Microsoft's C runtime library? C++ runtime is even worse, as > name mangling is completely different. Then there's __cdecl vs > __fastcall. VC++

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

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

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

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

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

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

> 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

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? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo

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