similar to: [LLVMdev] [PATCH] LLVM 3.0 broken in lib/Support/Windows/DynamicLibrary.inc

Hi all, I'm hitting the same problem as in this[1] thread. I use release_37 branch on 64-bit Windows 7. The problem is here: #ifdef __MINGW32__ #include <imagehlp.h> #else #include <dbghelp.h> #endif <skip> typedef BOOL (WINAPI *fpEnumerateLoadedModules)(HANDLE,PENUMLOADED_MODULES_CALLBACK64,PVOID); imagehlp.h doesn't define PENUMLOADED_MODULES_CALLBACK64 type. I

I use the one from mingw.org, installed by the recommended way with mingw-get-setup.exe. Sly. On 30.08.2015 06:10, Yaron Keren wrote: > Which mingw distribution exactly do you use? > > 2015-08-30 0:46 GMT+03:00 Slycelote via llvm-dev <llvm-dev at lists.llvm.org>: > >> Hi all, >> >> I'm hitting the same problem as in this[1] thread. I use release_37

Hello there, I'm having a problem compiling llvm with vc++ 2005 and windows sdk6.1. It seems that the Platform SDK supplied with vc++2005 uses PSTR for the first param of PENUMLOADED_MODULES_CALLBACK64 typedef (dbghelp.h) and the windows sdk 6.1 (also windows sdk 6.0a that ships with vc++2008) uses PCSTR. The _MSC_VER macro guard for ELM_Callback(...) kinda kills the possibility of using

I've come across a couple errors when building LLVM 2.1 in VC++ 2005. 1) CodeGen/RegisterCoalescer.cpp is not included in the project 2) System/Win32/DynamicLibrary.inc - ELM_Callback is declared with a PSTR ModuleName argument. This causes a compile error - the callback typedef specifies PCSTR. Also, I'd like to suggest adding the following to config.h, to eliminate the spurious

I use VS2005/Vista, which works well... Thx, Seung ---- Original message ---- >Date: Wed, 20 Feb 2008 12:02:29 +0800 >From: "Xi Wang" <xi.wang at gmail.com> >Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio 2005? >To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > >Hi there, > >Did anyone try

Hi Ruben, > I don't know since when, but this file has been changed to remove all the > trickery (aka defines) needed for MinGW-w64 (and probably everything else > that as forgotten) to succesfully compile it. Will you please check which commit introduces the breakage? Thanks! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State

Hello all, Is there anyone has tried LLVM 2.1 on Visual Studio 2005? I did but not succeed due to some build errors. I seem to remember I read somewhere on this list it's compiled on VS2005 so I wonder... Have a good night. Thx, Seung

Not really. I'm pretty much leaving the win32 directory up to Jeff Cohen these days. I don't have a way to replicate the problem. Reid. On Wed, 2004-12-29 at 12:46, Henrik Bach wrote: > Reid, > > I'm just curious to know if these errors are on your new year list :) > ---------------- > make[1]: Entering directory `/C/projects/build/MinGW/llvm-1-1/lib/System' >

I have no way of duplicating mingw problems either, but in this case the fix is obvious and has been committed. Reid Spencer wrote: >Not really. I'm pretty much leaving the win32 directory up to Jeff Cohen >these days. I don't have a way to replicate the problem. > >Reid. > >On Wed, 2004-12-29 at 12:46, Henrik Bach wrote: > > >>Reid, >>

Reid, I'm just curious to know if these errors are on your new year list :) ---------------- make[1]: Entering directory `/C/projects/build/MinGW/llvm-1-1/lib/System' llvm[1]: Compiling DynamicLibrary.cpp for Debug build In file included from c:/projects/src/llvm-1/llvm/lib/System/DynamicLibrary.cpp:25: c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp:22: warning:

I'm using llvm::sys::DynamicLibrary to export Symbols from my host-application to a JIT instance. Now I was wondering what the scope of this DynamicLibrary is, because I think I never attached it to the JIT or the module. Would it be possible to use the exported symbols even from a separate process (e.g. a forked off JIT), as long as the host app is running? -Frank

Hi, We need to support unloading of shared libraries. I'd like to continue using sys::DynamicLibrary. Few questions: * Is there a fundamental reason not to implement UnloadLibrary? * Would it be necessary to implement some fancy symbol use-check for unloading, or would it be fine to make this a "use at your own risk" operation? At least as a first implementation? * I would also

Hi, Attached patch moves code around; it should not have a functional effect. It formalizes a few concepts that were spread over several files before, depending on platform. It removes historical leftovers. Symbol lookup now happens in three easy phases, on all platforms: * explicitly provided symbols through AddSymbol() * shared libraries * platform provided "special" symbols. No

--- src/wave_out.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/wave_out.c b/src/wave_out.c index 57b5703..0f871b9 100644 --- a/src/wave_out.c +++ b/src/wave_out.c @@ -71,7 +71,7 @@ Box ( const char* msg ) */ static void CALLBACK -wave_callback ( HWAVE hWave, UINT uMsg, DWORD dwInstance, DWORD dwParam1, DWORD dwParam2 ) +wave_callback ( HWAVEOUT hWave, UINT

Hello, I'm new on DSP and i want to implant speex echo canceller on the Blackfin DSK version of speex to work on the BF533 EZ-KIT LITE But i can perform the echo canceller to work This is my code, so if somebody can tell me where i'm wrong //----------------------------------------------------------------------------- // CallBackFunction() - Gets called by the audio pseudo-driver

This patch cleans up some 80-odd warnings I was seeing when compiling the xenpci driver, all completely trivial. It also replaces the use of asm for calling cpuid with the __cpuid compiler intrinsic, and modifies calling code accordingly. I''m pretty sure my mailer going to mangle the inline patch (below) so I''m attaching the pristine version. (will try to fix for next time) --

When building LLVM/Clang, I get the following build failure: [ 4%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.obj In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33: M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:48:17: error: redefinition of '_IMAGEHLP_LINE64' typedef struct _IMAGEHLP_LINE64 { ^

OK thanks - I see how to do that now. I'm still unable to compile the patched wine. I think the problem is that I'm not sure exactly what the patch should contain. I have tried the below patch but the compile barfs: > > diff --git a/dlls/iphlpapi/iphlpapi_main.c b/dlls/iphlpapi/iphlpapi_main.c > index 547b666..d19bff7 100644 > --- a/dlls/iphlpapi/iphlpapi_main.c > +++

The Wine development release 1.1.15 is now available. What's new in this release (see below for details): - Gecko engine update. - Better region support in GdiPlus. - Support for cross-compilation in winegcc. - Beginnings of MS Text Framework support. - Many fixes to the regression tests on Windows. - Various bug fixes. The source is available from the following locations:

I'm trying to compile LLVM with musl libc library. The compilation process fails on the following: x86_64-linux-musl-g++ -DGTEST_HAS_RTTI=0 -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support -Iinclude -I../include -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter