search for: mklib

Hi, What is mklib trying to do with lli.exe.exp? However, lli.exe gets linked anyway. -------------- llvm[2]: Linking Debug executable lli /C/projects/build/MinGW/llvm-1-1/mklib: /C/projects/build/MinGW/llvm-1-1/Debug/bin/.libs//C/projects/build/MinGW/llvm-1-1/Debug/bin/lli.exe.exp: No such file or directory llv...

...ail/llvmdev/2005-February/003300.html ) >> let external project (I am test it at my YAFL frontend for LLVM) build >> using installed LLVM version instead using LLVM obj/src dirs. > > I think the patch looks basically sane. The one wierd thing I notice is > the replacement of mklib with libtool. Ops... I must be more careful. Updated patch attached. I use for build libtool "ltmain.sh (GNU libtool) 1.5.10" without problems. But I add code to preserve use $(LLVM_OBJ_ROOT)/mklib if LLVM_OBJ_ROOT set In other cases if $(LLVM_OBJ_ROOT)/mklib using important it installa...

.../c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/Common Files/Teleca Shared:/mingw:/c/downloads:/c/llvm1.8/generated-llvm/obj/Debug/bin:/c/llvm1.8-mingw32/bin:/c/llvm1.8-frontend/bin:/mingw/bin And this is the error I get while running configure: . . . appending configuration tag CXX to mklib appending configuration tag F77 to mklib checking for llvm-gcc.exe... /c/llvm1.8-mingw32/bin/llvm-gcc.exe checking for llvm-g++.exe... /c/llvm1.8-mingw32/bin/llvm-g++.exe *checking tool compatibility... configure: error: g++|icc required but not found* I searched the file system and couldn't...

...ail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003300.html ) > let external project (I am test it at my YAFL frontend for LLVM) build using > installed LLVM version instead using LLVM obj/src dirs. I think the patch looks basically sane. The one wierd thing I notice is the replacement of mklib with libtool. However, this is definitely something Reid should review. I think he's currently out of town but will be back next week. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/

FYI, The changes to make libtool appear as mklib have now also been committed. If you want to have support for mklib in your build tree, here's what you do: cd $objdir rm libtool $srcdir/configure --prefix=... --llvmgccdir=... After configure runs, you should have a "mklib" script in your $objdir and the Makefile.rules have been c...

Aviv Peretz wrote: > > Hi, > > > I finally gave up building on Linux, in the meantime, and tried to > build this version straight on Windows, using mingw32. > > > .... > > appending configuration tag CXX to mklib > appending configuration tag F77 to mklib > checking for llvm-gcc.exe... /c/llvm1.8-mingw32/bin/llvm-gcc.exe > checking for llvm-g++.exe... /c/llvm1.8-mingw32/bin/llvm-g++.exe > *checking tool compatibility... configure: error: g++|icc required but > not found* > > > I sea...

>> Also I have in Makefile.rules (but not include in patch) some >> modification for simplify used common Makefile.rules in LLVM projects and >> non-LLVM project (guarding some LLVM specific parts by ifdef >> LLVM_OBJ_ROOT/LLVM_SRC_ROOT vars). > > I'm not sure about this, perhaps Reid would like to comment? > Patch attached. This patch with header

...------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From rspencer at x10sys.com 2004-10-12 19:58 ------- The difficulty I had turned out to be the name of "mklib" instead of "libtool". The Makefiles use "mklib" but I was constantly regenerating libtool under various circumstances. The real problem was our version of ltmain.sh which didn't match our version of libtool.m4. Both these files have been committed as well as changes to...

...t;> I think at building, for example, llvm-java use >> llvm-java/autoconf/install-sh is more correct (synchronized version with >> other autoconf files and configure in project sources) > > I think that it just leads to confusion. LLVM should provide the core > set of tools (mklib, install-sh, mkinstalldirs, etc.) needed by the > makefile system (since LLVM owns the makefile system). LLVM projects > that want to use this system should use its facilities and not override > them. If someone doesn't want to do that, then it shouldn't be regarded > as an LLVM...

...g, for example, llvm-java use > >> llvm-java/autoconf/install-sh is more correct (synchronized version with > >> other autoconf files and configure in project sources) > > > > I think that it just leads to confusion. LLVM should provide the core > > set of tools (mklib, install-sh, mkinstalldirs, etc.) needed by the > > makefile system (since LLVM owns the makefile system). LLVM projects > > that want to use this system should use its facilities and not override > > them. If someone doesn't want to do that, then it shouldn't be regarded...

...300.html ) >>> let external project (I am test it at my YAFL frontend for LLVM) >>> build using installed LLVM version instead using LLVM obj/src dirs. >> >> >> I think the patch looks basically sane. The one wierd thing I notice >> is the replacement of mklib with libtool. > > Ops... I must be more careful. Updated patch attached. > > I use for build libtool "ltmain.sh (GNU libtool) 1.5.10" without problems. > But I add code to preserve use $(LLVM_OBJ_ROOT)/mklib if LLVM_OBJ_ROOT set > In other cases if $(LLVM_OBJ_ROOT)/mk...

...-DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -fvisibility=hidden -DGALLIUM_RBUG -DGALLIUM_TRACE target.c -o target.o /bin/sh ../../../../bin/mklib -o nouveau_dri.so.tmp -noprefix -linker 'g++' -ldflags '' \ target.o ../../../../src/mesa/drivers/dri/common/utils.o ../../../../src/mesa/drivers/dri/common/dri_util.o ../../../../src/mesa/drivers/dri/common/xmlconfig.o ../../../../src/gallium/state_tr...

Hi I'm compiling: /usr/local/src/llvm/lib/Support/SlowOperationInformer.cpp on MinGW. However, it stops complaining about that SIGALRM is undeclared: -------------------------- @ /usr/local/build/llvm/mklib --tag=disable-shared --silent --tag=CXX --mode=compile g++ -c -I/usr/local/build/llvm/lib/Support -I/usr/local/src/llvm/lib/Support -I/usr/local/build/llvm/include -I/usr/local/src/llvm/include -I../../include -I/usr/local/src/llvm/include -D__MINGW -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -Wall -W...

...00693.html saying that the PR 12544 is not really the corresponding issue :) The correct one is PR 13392: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13392 Interesting fact is that -O2 (or -O3) goes somehow around this problem. It looks like -O2 is not used here: /home/vak/ssrc/llvm/mklib --tag=disable-shared --silent --mode=compile g++ -c -I/home/vak/ssrc/llvm/lib/Support -I/home/vak/ssrc/llvm/lib/Support -I/home/vak/ssrc/llvm/include -I/home/vak/ssrc/llvm/include -I../../include -I/home/vak/ssrc/llvm/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -Wall -W -Wwrite-strings -Wno-unused...

Hi, > AsmWriterEmitter.cpp:(.text+0x78): undefined reference to `__dso_handle' > AsmWriterEmitter.cpp:(.text+0x8c): undefined reference to `__cxa_atexit' This is not connected with that warning. Something is wrong with your compiler / linker. Either it does not provide needed libraries, or broken in other way. > AsmWriterEmitter.cpp:(.text+0x25e): undefined reference to

...omponent: Drivers/DRI/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: jojo170387 at gmail.com Mesa compilation fails if configured with: ./configure --with-dri-drivers=,swrast,nouveau --with-gallium-drivers=,swrast,nouveau Error message: /bin/sh ../../../../bin/mklib -o nouveau_dri.so.tmp -noprefix -linker 'g++' -ldflags ' -L/usr/lib64/llvm -lpthread -lffi -ldl -lm ' \ target.o ../../../../src/mesa/drivers/dri/common/utils.o ../../../../src/mesa/drivers/dri/common/dri_util.o ../../../../src/mesa/drivers/dri/common/xmlconfig.o ../../.....

...OOLLINKOPTS=-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 --tag=disable-shared --tag=CXX --mode=link g++ -I/C/Projects/build/MinGW/llvm/utils/TableGen -I/C/Projects/build/MinGW/llvm/../../../src/llvm/utils/TableGen -I/C/Projects/build/MinGW/llvm/../../../src/llvm/include -I/C/Projects/build/MinGW/llvm/include -I/C/Projects/build/MinGW/llvm/include -...

...lib/Support/SlowOperationInformer.cpp > on MinGW. However, it stops complaining about that SIGALRM is undeclared: Is there an alarm() syscall on MinGW? And if so, what signal does it send (according to the MinGW docs)? -- John T. > -------------------------- > @ /usr/local/build/llvm/mklib --tag=disable-shared --silent --tag=CXX > --mode=compile g++ -c -I/usr/local/build/llvm/lib/Support > -I/usr/local/src/llvm/lib/Support -I/usr/local/build/llvm/include > -I/usr/local/src/llvm/include -I../../include > -I/usr/local/src/llvm/include -D__MINGW -D_GNU_SOURCE > -D__S...

Kenneth Boyd <zaimoni at zaimoni.com> writes: >>> * I am seeing desynchronization between the configure-generated >>> Makefiles and the CMakeFile.txt files. [e.g., llc; makefile doesn't >>> have asmprinter, CMakeFile.txt does]. That much I should be able to >>> construct a patch for "blind", if no-one gets to it first. >>>

...>> However, it stops complaining about that SIGALRM is undeclared: > > > Is there an alarm() syscall on MinGW? And if so, what signal does it > send (according to the MinGW docs)? > > -- John T. > >> -------------------------- >> @ /usr/local/build/llvm/mklib --tag=disable-shared --silent --tag=CXX >> --mode=compile g++ -c -I/usr/local/build/llvm/lib/Support >> -I/usr/local/src/llvm/lib/Support -I/usr/local/build/llvm/include >> -I/usr/local/src/llvm/include -I../../include >> -I/usr/local/src/llvm/include -D__MINGW -D_GNU_SO...