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

>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

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> >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 necessary -L option to >TOOLLINKOPTS. I believe that should fix

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

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

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, I'm able to build the llvm tools on the MinGW platform: burg, fpcmp, tblgen, llvm-as, llvm-dis, opt, gccas, llc, llvm-link, lli, gccld, llvm-stub, analyze and extract. I wonder if these tools are sufficient to start build the cfrontend? Henrik. _________________________________________________________________ Undg� pop-ups med MSN Toolbar - http://toolbar.msn.dk hent den gratis!

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

Hi, I didn't get a clear idea what to do whit this problem: OptimizerDriver.cpp seems to be unix platform specific. However, I'm compiling this on MinGW. Shouldn't this be moved to lib/System/<platform>? Any suggestions? -------------------------- c:/Projects/src/llvm/tools/bugpoint/OptimizerDriver.cpp:28:22: sys/wait.h: No such file or directory

Hi, I cannot find windows either... In previous llvm sources windows.h was found in: 'include/llvm/Config'. ------ Build started: Project: support, Configuration: Release Win32 ------ Compiling... randtable.c c:\projects\src\llvm-1\llvm\lib\Support\bzip2\bzlib.h(117) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory huffman.c ----------------

>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, Is it necessary to use the VC6.1+ `__time64_t' type instead of __time_t in win32/TimeValue.cpp? --------------- In file included from c:/projects/src/llvm-1/llvm/lib/System/TimeValue.cpp:51: c:/projects/build/MinGW/llvm-1-1/lib/System/platform/TimeValue.cpp: In member function `std::string llvm::sys::TimeValue::toString() const':

Hi I noticed that these defines (line 35 to 37) are hardcoded in the DataTypes.h include file: ---------------- #define HAVE_SYS_TYPES_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_STDINT_H 1 ---------------- Shouldn't they have be defined by the configure script into llvm/Config/config.h? Henrik _________________________________________________________________ Undg� pop-ups med MSN Toolbar

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'

Replace __time_t with time_t in my question. I've compiled function: std::string TimeValue::toString() const { // Alas, asctime is not re-entrant on Windows... //hb: __time64_t ourTime = this->toEpochTime(); time_t ourTime = this->toEpochTime(); //hb: char* buffer = ::asctime(::_localtime64(&ourTime)); char* buffer = ::asctime(::localtime(&ourTime)); std::string

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

Hell I''m new to Qdisc programming and I was wondering, what is the difference between using an internal Qdisc (like e.g. TBF does) vs. not using internal Qdisc (like e.g. SFQ does)? Can someone give me a quick rundown of pro and cons? with regards R.harper _________________________________________________________________ Undgå pop-ups med MSN Toolbar - http://toolbar.msn.dk hent den

The problem with building the frontend on Windows is that gcc cannot be bootstrapped using Window's native compiler -- i.e. VC++ -- unlike every other platform. It can be built on Windows using gcc, of course, but even then only if the entire GNU environment is present. The real problem is that the bootstrapped frontend binaries built using gcc may not properly link with LLVM binaries built

I'm not sure. Perhaps Jeff Cohen knows as he wrote this. Reid. On Tue, 2004-12-14 at 11:51, Henrik Bach wrote: > Hi, > > Is it necessary to use the VC6.1+ `__time64_t' type instead of __time_t in > win32/TimeValue.cpp? > > --------------- > In file included from > c:/projects/src/llvm-1/llvm/lib/System/TimeValue.cpp:51: >

On Tue, 2 Nov 2004, Jeff Cohen wrote: > The problem with building the frontend on Windows is that gcc cannot be > bootstrapped using Window's native compiler -- i.e. VC++ -- unlike every > other platform. It can be built on Windows using gcc, of course, but > even then only if the entire GNU environment is present. Yeah, annoying. Unfortunately we're not up to fixing GCC :)