search for: toollinkopt

...gt;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 it. But, how do I tell which library to link from the path? Because, the lib<library> is in the default library path of MinGW (like /usr/lib). Henrik _________________________________________________________________ Find det, du s�ger p� MSN S�g http://search....

...t; > >> >> 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 it. > > > But, how do I tell which library to link from the path? Because, the > lib<library> is in the default library path of MinGW (like /usr/lib). If libdgbhelp is in the default library path, a -L option should not be necessary, and in that c...

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 libsupport) are linked in. I think g++ may only search >&gt...

...> >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 additional linker flags needed >to use system libraries. These are typically system libraries for which a >-L option is not needed or has already been supplied to the configure >script. Ok. >For libraries internal to LLVM, we add the library to the...

>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: > 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. I think g++ may only search linker paths t...

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 --ta...

...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 := -lpthread -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/

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 exist and is not needed to use alloca(); #ifdef it out 4. no malloc.h and no mallinfo(); malloc doesn't track this stuff; #ifdef it out 5. isnan() may b...

...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 := -lpthread There is both a static (.a) and dynamic (.so) version of the library. The above advise worked for the static library. However, I think it is more convenient to use the dynamic version. How do I achieve that? Henrik. > >-Chris > >-- >http://nondot.org/sabre/ >ht...

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'

On Thu, 7 Jul 2005, Henrik Bach wrote: >> TOOLLINKOPTS := -lpthread > > There is both a static (.a) and dynamic (.so) version of the library. The > above advise worked for the static library. However, I think it is more > convenient to use the dynamic version. How do I achieve that? lli -load /path/to/libpthread.so foo.bc -Chris --...

...Your docs on Writing an LLVM Pass - Using gdb with dynamically loaded passes was very useful. I've done some instrumentation and collected profiles during runtime using library routines in a separate pass with opt tool. I used : In the tools/lli/Makefile , I included the following line TOOLLINKOPTS := -lpthread $opt -load ../../../mypass.so -myoption test.bc > test1.bc $lli -load ../../../mypass.so test1.bc using JIT and it worked perfectly. Now I am trying to generate static native code generation and then execute the native code program as: $opt -load ../../../mypass.so -myoption...

...stuff), and we don't use -DHAVE_CONFIG_H anyway. > # > #CPPFLAGS+=-DHAVE_CONFIG_H > #CCFLAGS+=-DHAVE_CONFIG_H > LDFLAGS+= > > # > # Removed since it prevents the tests from working properly. > # > #LIBS+=-ldl > > # > # Libraries needed by tools > # > TOOLLINKOPTS=-ldl > > # > # Path to the archiver program. > # > AR_PATH = /usr/bin/ar > > # > # The pathnames of the Flex and Bison programs, respectively. > # > BISON = bison > FLEX = flex > > # > # Paths to miscellaneous programs. > # > RPWD = /bi...

...> ifndef VERBOSE > VERB := @ > LIBTOOL += --silent > @@ -171,11 +140,13 @@ > STRIP_WARN_MSG = "(without symbols)" > endif > > +# Adjust linker flags for building an executable > ifdef TOOLNAME > LDFLAGS += -rpath $(TOOLDIR) -export-dynamic $(TOOLLINKOPTS) > endif > > -# TOOLLINKOPTSB to pass options to the linker like library search path etc > +# Use TOOLLINKOPTSB to pass options to the linker like library search > +# path etc. > # Note that this is different from TOOLLINKOPTS, these options > # are passed to the linker...

Hi John, I have attached my Makefile.config. I noticed that I did'nt have SRC_ROOT and OBJ_ROOT variables defined as such in my environment. But I noticed that this is defined in the Makefile.config by default to the same values. All the same, I tried defining both these variables in my .cshrc, but I still get the same error. The main directory for me is /home/llvm, and I have

Reid, I think it is the first time it is run that the errors occcur !? Not sure but that would seem logical. Aaron