similar to: [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.

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

I made my first attempt to build on an x86_64-unknown-linux-gnu system. Is this supposed to work? I get libtools errors (below). The problem seems to be that it finds a 32-bit libltdl rather than the 64-bit libltdl. /home/dag> ls /usr/lib/libltdl.so.3.1.0 /usr/lib/libltdl.so.3.1.0 /home/dag> ls /usr/lib64/libltdl.so.3.1.0 /usr/lib64/libltdl.so.3.1.0 Is this a known problem?

On Mon, Sep 17, 2007 at 12:25:40PM -0700, Chris Lattner wrote: > On Mon, 17 Sep 2007, Emil Mikulic wrote: > >> The 2.1 pre-release (version 1) is available for testing: > >> http://llvm.org/prereleases/2.1/version1/ > > > > I suspect the utils/TableGen/FileParser.h.cvs in the tarball may be > > stale. I tried building LLVM without bison installed and got:

On Mon, 17 Sep 2007, Emil Mikulic wrote: >> The 2.1 pre-release (version 1) is available for testing: >> http://llvm.org/prereleases/2.1/version1/ > > I suspect the utils/TableGen/FileParser.h.cvs in the tarball may be > stale. I tried building LLVM without bison installed and got: Can you try it again without bison with these files:

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

>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

Jeff & others A couple words on how lib/System works that might help you. 1. The configure script identifies the build host and puts it in the $build variable. We use that to determine the basic kind of platform and put it in a variable named $OS. The value of $OS can be: Linux, FreeBSD, Interix, SunOS, Darwin, etc. 2. The platform name is used to create a link from

>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

>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

Reid, >As for Interix support in general, I'm having a hard time determining >which variant of Unix Interix implements. It seems to be partially Posix >1 and partially Posix 2 based. Do you have any further information >related to the specific standards supported by Interix? I don't want to >incorrectly categorize the Interix support. I've discussed this subject with

Jeff/Vladimir: As with Interix, I've recently added support for FreeBSD into lib/System. Currently, the implementation of FreeBSD just uses the "generic Unix" implementation which probably should work on FreeBSD. If not, I would appreciate it if you could make patches in the FreeBSD directory. If you do, don't forget that you need to remove anything that doesn't work in the

On OS X 10.5.5 I get an error that ld doesn't support -export-dynamic: dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ ../src/configure --prefix=`pwd`/../install && make VERBOSE=1 ... dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ make VERBOSE=1 for dir in lib/System lib/Support utils lib/VMCore lib tools/llvm-config tools docs; do \ if [ ! -f

For those of you who haven't noticed, I'm planning to commit a major change to the Makefile rules tomorrow evening (Tuesday) if there are no complaints about it between now and then. This needs testing on Darwin. I've heard back from Linux on many platforms and even FreeBSD, which is fantastic, but I'm told that lots of LLVMers are running Darwin and I haven't heard a peep

On Fri, 3 Dec 2004, Reid Spencer wrote: > Could someone please apply this patch to the Win32 support so that > Morten and Jeff can handle the recent changes? I can't do it because > I"m on the road with only email access. I'd be happy to do it. Can someone send me the patch as an attachment off-list? -Chris > > <Tool > >

On Mon, 30 Aug 2004 21:27:26 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > On Mon, 30 Aug 2004 20:48:45 -0700 > Jeff Cohen <jeffc at jolt-lang.org> wrote: > > > When I ran configure after updating, I get various errors. First: > > > > % ../configure --enable-jit --with-llvmgccdir=/home/llvm/cfrontend/x86/llvm-gcc > > checking for a

On Fri, Sep 14, 2007 at 11:42:18PM -0700, Tanya Lattner wrote: > LLVMers, > > The 2.1 pre-release (version 1) is available for testing: > http://llvm.org/prereleases/2.1/version1/ I suspect the utils/TableGen/FileParser.h.cvs in the tarball may be stale. I tried building LLVM without bison installed and got: gmake[2]: Entering directory

Hi all, I'm building the LLVM 2.0 pre-release on a brand new FreeBSD 6.2 install. Without the bison package installed, the build breaks: $ tar zxf llvm-2.0.tar.gz $ mkdir objdir $ cd objdir $ ../llvm-2.0/configure $ gmake [...] gmake[2]: Entering directory `/usr/home/emil/objdir/utils/TableGen' llvm[2]: Compiling AsmWriterEmitter.cpp for Release build llvm[2]: Compiling

On Mon, 2004-08-30 at 21:46, Jeff Cohen wrote: > This isn't my day... > > gmake[2]: Entering directory `/usr/home/llvm/obj/utils/TableGen' > Bisoning FileParser.y > Flexing /usr/home/llvm/obj/../utils/TableGen/FileLexer.l > gmake[2]: Leaving directory `/usr/home/llvm/obj/utils/TableGen' > gmake[2]: Entering directory `/usr/home/llvm/obj/utils/TableGen' >

Could someone please apply this patch to the Win32 support so that Morten and Jeff can handle the recent changes? I can't do it because I"m on the road with only email access. Thanks, Reid. -----Forwarded Message----- > From: Morten Ofstad <morten at hue.no> > To: Reid Spencer <reid at x10sys.com> > Subject: Updated LLVM Visual Studio project files > Date: Thu,