Displaying 20 results from an estimated 1500 matches similar to: "[LLVMdev] Link error with TOOLLINKOPTS=-ldbghelp on MinGW"
2004 Oct 25
1
[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
2004 Oct 25
0
[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
2004 Oct 25
2
[LLVMdev] Link error with TOOLLINKOPTS=-ldbghelp on MinGW
>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
2004 Oct 25
1
[LLVMdev] Link error with TOOLLINKOPTS=-ldbghelp on MinGW
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
2004 Oct 23
2
[LLVMdev] Link error with TOOLLINKOPTS=-ldbghelp on MinGW
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
2004 Oct 25
0
[LLVMdev] Link error with TOOLLINKOPTS=-ldbghelp on MinGW
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.
2004 Nov 02
5
[LLVMdev] LLVM tools sufficient to build the cfrontend for windows from MinGW?
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!
2005 Jul 07
0
[LLVMdev] External function 'pthread_once' could not be resolved
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 :=
2004 Oct 18
1
[LLVMdev] Compiling errors from OptimizerDriver.cpp when compiling on MinGW
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
2004 Dec 21
3
[LLVMdev] VC++: Cannot open include file: 'windows.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
----------------
2005 Jul 07
2
[LLVMdev] External function 'pthread_once' could not be resolved
>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
2004 Dec 14
2
[LLVMdev] __time_t type instead of __time64_t in win32/TimeValue.cpp
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':
2004 Sep 25
2
[LLVMdev] Hardcoded HAVE_* defines in the DataTypes.h include file
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
2005 Jul 07
5
[LLVMdev] External function 'pthread_once' could not be resolved
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'
2004 Dec 14
1
[LLVMdev] __time_t type instead of __time64_t inwin32/TimeValue.cpp
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
2003 Jun 08
1
[LLVMdev] summary of LLVM on FreeBSD status.
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
2005 Apr 27
3
Internal Qdisc
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
2004 Nov 02
0
[LLVMdev] LLVM tools sufficient to build the cfrontend for windows from MinGW?
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
2004 Dec 14
0
[LLVMdev] __time_t type instead of __time64_t in win32/TimeValue.cpp
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:
>
2004 Nov 02
1
[LLVMdev] LLVM tools sufficient to build the cfrontend for windows from MinGW?
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 :)