similar to: [LLVMdev] Compiling LLVM 2.7 with MinGW GCC 4.5.0

> Could you post the errors message? Sounds like bug in mingw's gcc / ld. It's very long, maybe I should just attach the log? I only remember the first line saying: --export-dynamic is not supported for PE targets, do you mean --export-all-symbols? *or something similar to this* then a bunch of undefined references occur. -- View this message in context:

> Has anyone succeeded? I kept getting linker errors when building opt. The > only additional configure command I use is --enable-optimized. Could you post the errors message? Sounds like bug in mingw's gcc / ld. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

> Make sure you're using the correct perl - that one which comes with msys DTK I'm using msys perl for msys 1.0.11. Maybe I should revert back to msys 1.0.10? ________________________________ Dari: Anton Korobeynikov <anton at korobeynikov.info> Kepada: leledumbo <leledumbo_cool at yahoo.co.id> Cc: llvmdev at cs.uiuc.edu Terkirim: Sen, 27 September, 2010 13:45:47 Judul:

Good morning. I don't understand relation between output.log and error.log. It seems all LLVM libraries are not found on linking opt.exe. Please show us logs with command lines with make VERBOSE=1 It would be better only then to touch a few files. (eg. lib/Transforms/Scalar/GVN.cpp) The warning of --export-dynamic might be harmless, and you may add the option --enable-auto-import IIRC

> first line saying: --export-dynamic is not supported for PE targets, do you > mean --export-all-symbols? *or something similar to this* then a bunch of > undefined references occur. Make sure you're using the correct perl - that one which comes with msys DTK -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

reverting doesn't help. Here are the logs: http://old.nabble.com/file/p29834726/output.log output.log http://old.nabble.com/file/p29834726/error.log error.log which mingw gcc + binutils versions are known to work (or better, the one that you guys use)? -- View this message in context: http://old.nabble.com/Compiling-LLVM-2.7-with-MinGW-GCC-4.5.0-tp29810752p29834726.html Sent from the LLVM -

Good evening. Thank you. > configure: running /bin/sh ../../../projects/sample/configure --prefix=c:/llvm '--enable-optimized' '--enable-shared' '--enable-targets=host,x86,cpp' 'CFLAGS=-s -O4' 'CXXFLAGS=-s -O4 -Wl,--enable-auto-import' 'LDFLAGS=-s -O4' --cache-file=/dev/null --srcdir=../../../projects/sample --enable-shared/DLL was not

Attached is a result of configure and make VERBOSE=1: http://old.nabble.com/file/p29846487/output.log output.log http://old.nabble.com/file/p29846487/error.log error.log -- View this message in context: http://old.nabble.com/Compiling-LLVM-2.7-with-MinGW-GCC-4.5.0-tp29810752p29846487.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

Anybody having success building an LLVM.dll in this configuration? It's failing for me, in tools/llvm-shlib, with an error suggesting that the gcc ld doesn't understand the format of the exports map being generated. (plain configure && make works just fine, it's just this shared option that fails; google shows support for --enable-shared was added around 2.7 timeframe and

My test environment: 1. Installed mingw/MSYS from sourceforge.net/projects/mingw using the "Automated MinGW Installer" mingw-get-inst-20110802.exe (installed everything except Fortran). 2. Installed Python 2.7 from www.python.org/download using python-2.7.2.msi 3. MSYS bash path set to /c/MinGW/bin:/bin:/c/Python27:/c/WINDOWS/ system32:/c/WINDOWS:/c/WINDOWS/system32/wbem 4. Built

I'm a Windows user, and wish to run LLVM-Clang on Windows. In Visual Studio 2010, buidling was fairly straightforward via the solution file from CMake. However, there is no good document (thought I searched for an hour) how to compile LLVM with MinGW on Windows. I generated MinGW Makefile and build directories from CMake. I installed entire MinGW+MSys packages. I tried to run "make -f

When attempting to compile this simple testing tool http://github.com/oneclick/rubyinstaller/blob/fake/resources/tools/fakeruby.c I get the following: C:\Users\Jon\Documents\CDev\sandbox>llvm-gcc -Wall -o fakeruby.exe fakeruby.c Warning: resolving _GetModuleHandleA by linking to _GetModuleHandleA at 4 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable

Hello, Jeff. You wrote Saturday, April 29, 2006, 10:45:02 PM: JC> Yes, I know mingw doesn't support dbghelp. I can still rant about it :) ;) Well. Maybe this library will be included in some next versions of mingw's win32api package. Anyway, we can make such library just "on-fly" from the corresponding .dll. JC> This is what's already there. What changed? Maybe

Good midnight, Kevin. cygming/shared might have been broken since r112976, IIRC. (ToT, too) A trivial patch; --- a/Makefile.rules +++ b/Makefile.rules @@ -942,6 +942,11 @@ ifdef EXPORTED_SYMBOL_FILE # First, set up the native export file, which may differ from the source # export file. +# The option --version-script is not effective on GNU ld win32. +ifneq (,$(filter $(HOST_OS),Cygwin

2011/10/6 Aaron Ballman <aaron at aaronballman.com> > On Thu, Oct 6, 2011 at 2:09 PM, Ruben Van Boxem > <vanboxem.ruben at gmail.com> wrote: > > You're welcome! Please remember that MinGW-w64 does not mean it is > 64-bit. > > It provides both 32- and 64-bit headers/libs. The "w64" in the name was > > originally because that was the

i just downloaded LLVM 4.2 binaries for Mingw (including the GCC 4.2 front-end), and received the infamous "llvm-gcc: CreateProcess: no such file or directory" error message when trying to compile hello.c from the command-line.... i've already placed to bin directory containing llvm-gcc in my PATH, but still no luck....

On Thu, Oct 6, 2011 at 2:09 PM, Ruben Van Boxem <vanboxem.ruben at gmail.com> wrote: > You're welcome! Please remember that MinGW-w64 does not mean it is 64-bit. > It provides both 32- and 64-bit headers/libs. The "w64" in the name was > originally because that was the project's principal goal, among extending > the API completeness and compatibility with MSVC.

Hello, Dueky > But I could not make a success of compile to the "mingw-llvm-gcc in > windows". > I saw binary file "mingw-llvm-gcc for windows" , but I couldn't find > the "how to compile to the mingw-llvm-gcc in windows". In general, compilation of llvm-gcc for mingw is the same as compilation of llvm-gcc for any other platform. However, there are

I'm using LLVM-GCC to compile more of the apps I use on my Windows systems and have made mods to Makefile's to accomodate the following issues. Is there anything in the upcoming 2.7 release that make these mods unnecessary? 1) Explicitly passing the linker -Wl,--enable-stdcall-fixup. From an earlier post from Anton I recall that this may not required in 2.7. 2) As binutils windres

Hi Anton >> $ g++ -g tut1.cpp `llvm-config --cxxflags --ldflags --libs core` -o tut1 >> /mingw/lib/libLLVMSystem.a(Process.o):Process.cpp:(.text+0x8d): >> undefined reference to `GetProcessMemoryInfo at 12' >> collect2: ld returned 1 exit status > I believe you will need additional libraries like imagehlp and psapi. I have /lib/libimagehlp.a and /lib/libpsapi.a