similar to: [LLVMdev] Link error with TOOLLINKOPTS=-ldbghelp on MinGW

Henrik Bach wrote: >> From: John Criswell <criswell at cs.uiuc.edu> >> Date: Mon, 25 Oct 2004 15:38:52 -0500 > > >> >> When you run configure, you'd do something like this: >> >> configure --prefix=<...> LDFLAGS="-L<path where libdgbhelp is installed" >> >> If you modify Makefile.config directly, just add the

>From: John Criswell <criswell at cs.uiuc.edu> >Will this library be needed for tblgen or for all LLVM programs? And is it >a library you wrote for LLVM, or is it a MingW library? It's is generally needed for all programs or at least programs using Signals.o (from platform/Signals.cpp) and it is platform/MinGW specific. >TOOLLINKOPTS is used by configure to convey

>So, if I'm understanding you correctly, libdgbhelp is a library that >doesn't come with MinGW but can be installed on MinGW by the user if it is >needed. Am I correct? Yes. >If that's the case, I would say that it's the user's reponsibility to >install the library into /usr/lib or provide the configure script with the >appropriate -L options to find it

Hi LLVM'ers When linking tblgen tool I get below error message on MinGW. I have put TOOLLINKOPTS=-ldbghelp in Makefile.config. However, when rearranging library dbghelp to the end of the g++ line, tblgen gets linked. -------------------------- make[2]: Entering directory `/C/Projects/build/MinGW/llvm/utils/TableGen' Linking Debug executable tblgen /C/Projects/build/MinGW/llvm/mklib

Yes, that's my understanding, too. But I'm not controlling where my library -ldbghelp is put when g++ is called. I just put it in the TOOLLINKOPTS variable in Makefile.config. Henrik >From: Reid Spencer <reid at x10sys.com> > >John Criswell wrote: >> >>It seems that the -L path options are specified before the LLVM libraries >>(libSystem and

Henrik Bach wrote: > Hi LLVM'ers > > When linking tblgen tool I get below error message on MinGW. > > I have put TOOLLINKOPTS=-ldbghelp in Makefile.config. > > However, when rearranging library dbghelp to the end of the g++ > line, tblgen gets linked. It seems that the -L path options are specified before the LLVM libraries (libSystem and libsupport) are linked in.

Hi Jeff, We need to get getDirectoryContents and renameFile implemented from Unix/Path.cpp in Win32/Path.cpp, otherwise I can't get llvm-ar linked. Henrik. ============================================================= Henrik Bach Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= Got Freedom? Software Freedom Day

Hi When I run configure on Interix, I get these four error messages: ----------- ./configure[384]: test: Files/Microsoft: unexpected operator/operand ./configure[384]: test: Files/Microsoft: unexpected operator/operand ./configure[384]: test: Files/Microsoft: unexpected operator/operand ./configure[384]: test: Files/Microsoft: unexpected operator/operand checking for a BSD-compatible install...

I suspect those aren't the only two. I'll have to make a pass over Path.cpp to see what was added to the unix version and not to the win32 version. Henrik Bach wrote: > Hi Jeff, > > We need to get getDirectoryContents and renameFile implemented from > Unix/Path.cpp in Win32/Path.cpp, otherwise I can't get llvm-ar linked. > > Henrik. > > >

Hi Chris and Vikram, Thank you for your acknowlegdement of my and the other external contributors work, in your latest presentation of LLVM on Compiler Research Infrastructures: "The LLVM Compiler Framework and Infrastructure Tutorial", albeit we have done a little (except Reid) compared with you true unsung heroes at the LLVM team. Henrik

Hi, To link gccld it needs this patch to Path.cpp, too. Henrik. ============================================================= Henrik Bach Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/

============================================================= Henrik Bach LLVM Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= 'Nothing is impossible; The impossible just takes longer time :)' - Inventor of a new energy saver light bulp from Denmark. No software patents - Thank you Poland:

Yes, It looks like the PATH variable in the configure script at line 384 isn't getting quoted properly. The "Files/Microsoft" is probably part of "C:\Program Files\Microsoft\...". The spaces cause it to be interpreted as separate words so it fails. I don't have time to look at this in detail right now. Have a look at the configure script and see if you can figure

Hi Due to the mingw platform doesn't have the mmap function the above error emerges. The implementation without this function is left as an exercise. Does any one has an idea to implement this functionality? Henrik _________________________________________________________________ Find det, du s�ger p� MSN S�g http://search.msn.dk

Hi As shown below, the .\configure script found a version of alloca(): --------------------- configure:20831: checking for working alloca.h configure:20853: gcc -o conftest -g -O2 conftest.c -ldl >&5 configure:20856: $? = 0 configure:20859: test -s conftest configure:20862: $? = 0 configure:20873: result: yes configure:20883: checking for alloca configure:20925: gcc -o conftest -g -O2

I agree completely with you, Jeff. However, I think it somehow would be nice, if you guys could tell comming users that the win32 solution is geared toward VC++ 7.1 (and hence use of other tools are at their own risk). And, I think it also would be really cool, if you guys come up with a solution how to handle multiple VC++ x solutions/projects from the same source, possibly ranging from VC

On Thu, 7 Jul 2005, Henrik Bach wrote: > The 'pthread_once' is located in the native library binary file: > /usr/lib/libpthread.a. I've also included the path to the library in > LLVM_LIB_SEARCH_PATH environment variable. If libpthread.a is a static library, lli won't be successful loading it. Try relinking lli, but add this to its tools/lli/Makefile: TOOLLINKOPTS :=

>From: Chris Lattner >Date: Thu, 7 Jul 2005 11:26:48 -0500 (CDT) > >On Thu, 7 Jul 2005, Henrik Bach wrote: >>The 'pthread_once' is located in the native library binary file: >>/usr/lib/libpthread.a. I've also included the path to the library in >>LLVM_LIB_SEARCH_PATH environment variable. > >If libpthread.a is a static library, lli won't be

Hi LLVM'ers, I'm trying to build the DotGNU project with the LLVM-tools. After minor modifications of source and build code and some configure housekeeping, it seems that I've managed so far to build all the DotGNU tools. However, when extensively using the DotGNU tools I get this error message: make[1]: Entering directory `/home/hb/projects/build/LLVM/pnet-1-1/samples'

Hi, I spent a bit of time making llvm link on FreeBSD 5.1-RC1 (i686) tonight. (I didn't run any tests.) Here are the issues I ran into: 0. Need a llvm/Makefile.FreeBSD; Makefile.Linux unchanged worked OK 1. libdl doesn't exist; remove TOOLLINKOPTS=-ldl to link tools that use libdl 2. include/Support/DataTypes.h doesn't work for FreeBSD; I hacked a new version 3. alloca.h doesn't