search for: dumpspecs

...ied it and managed to only generate native code. I'm currently investigating an alternative approach to produce whole-program bitcodes: 1) add /tmp/wrap to PATH 2) create /tmp/wrap/gcc with the following contents #!/bin/sh exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@" 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real ld and does not pass any unknown flags to it. With this approach I was able to compile and run airstrike (a 2d dogfighting ga...

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=454 ------- Additional Comments From ldv@altlinux.org 2006-03-02 00:39 MET ------- Created an attachment (id=220) --> (https://bugzilla.netfilter.org/bugzilla/attachment.cgi?id=220&action=view) iptables-1.3.5-alt-link.patch Proposed patch. FC iptables package also attempts to address this issue, but their approach is worse: it

...ing an alternative approach to produce >> whole-program bitcodes: >> >> 1) add /tmp/wrap to PATH >> 2) create /tmp/wrap/gcc with the following contents >> >> #!/bin/sh >> exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@" >> >> 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs >> 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1 >> 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real >> ld and does not pass any unknown flags to it. >> >> With this approach I was able to com...

.... > I'm currently investigating an alternative approach to produce > whole-program bitcodes: > > 1) add /tmp/wrap to PATH > 2) create /tmp/wrap/gcc with the following contents > > #!/bin/sh > exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@" > > 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs > 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1 > 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real >   ld and does not pass any unknown flags to it. > > With this approach I was able to compile and run airstri...

...gt;> whole-program bitcodes: > >> > >> 1) add /tmp/wrap to PATH > >> 2) create /tmp/wrap/gcc with the following contents > >> > >> #!/bin/sh > >> exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@" > >> > >> 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs > >> 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1 > >> 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real > >> ld and does not pass any unknown flags to it. > >> > >> With this a...

...ing an alternative approach to produce >> whole-program bitcodes: >> >> 1) add /tmp/wrap to PATH >> 2) create /tmp/wrap/gcc with the following contents >> >> #!/bin/sh >> exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@" >> >> 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs >> 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1 >> 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real >> ld and does not pass any unknown flags to it. >> >> With this approach I was able to com...

...ing an alternative approach to produce >> whole-program bitcodes: >> >> 1) add /tmp/wrap to PATH >> 2) create /tmp/wrap/gcc with the following contents >> >> #!/bin/sh >> exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@" >> >> 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs >> 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1 >> 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real >> ld and does not pass any unknown flags to it. >> >> With this approach I was able to compi...

...urce/winsup/mingw/include -isystem /c/Temp/llvm-gcc4.2-2.6.source/winsup/w32api/include -B/c/Temp/msys-llv m-gcc/i686-pc-mingw32/bin/ -B/c/Temp/msys-llvm-gcc/i686-pc-mingw32/lib/ -isystem /c/Temp/msys-llvm-gcc/i686-pc-mingw32/include -isystem /c/Temp/msys-llvm-gcc/i6 86-pc-mingw32/sys-include -dumpspecs > tmp-specs mv tmp-specs specs if true ; then \ cat ../../llvm-gcc4.2-2.6.source/gcc/limitx.h ../../llvm-gcc4.2-2.6.so urce/gcc/glimits.h ../../llvm-gcc4.2-2.6.source/gcc/limity.h > tmp-xlimits.h; \ else \ cat ../../llvm-gcc4.2-2.6.source/gcc/glimits.h > t...

...elease event, serial 20, synthetic NO, window 0xe00001, root 0x3e, subw 0x0, time 443264060, (167,-11), root:(213,54), state 0x0, keycode 107 (keysym 0xffff, Delete), same_screen YES, XLookupString gives 1 bytes: "" Here are the specs for the gcc that compiled R: $ gcc -dumpspecs *asm: %{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} *asm_debug: %{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}} *asm_final: *asm_options: %a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O} *invoke_as: %{!S:-o %|.s | as %(asm_options) %|.s %A } *cpp: %{posix:-D_POS...

Hi, Kelly, Have you found the solution for this problem? I met a similar problem when I were trying to test MySQL 5.0 with LLVM. The following is my step, but still failed since llvm-ld can not recognize some gcc link flags. 1. during the configuration, use a script such as llvm-gcc.sh, at this time the script only invoke the gcc. This is necessary because the gnu configure will test the

...onv ../libiberty/libiberty.a > /llvm-gcc/obj/gcc/xgcc -B/llvm-gcc/obj/gcc/ > -B/llvm-gcc/../install//i686-pc-cygwin/bin/ > -B/llvm-gcc/../install//i686-pc-cygwin/lib/ > -isystem /llvm-gcc/../install//i686-pc-cygwin/include > -isystem /llvm-gcc/../install//i686-pc-cygwin/sys-include -dumpspecs > > tmp-specs > mv tmp-specs specs > if ; then \ > > cat ../../src/gcc/limitx.h ../../src/gcc/glimits.h ../../src/gcc/limity.h > tmp-xlimits.h; \ > else \ > cat ../../src/gcc/glimits.h > tmp-xlimits.h; \ > fi > make[1]: Leaving directory `/llvm-gcc/obj/gc...

If you're building llvm-gcc4, you don't need the runtime libraries, so I'd just stick with the "tools-only" build and declare success. If you're building llvm-gcc3, I'd suggest you switch to llvm-gcc4 :) However, the problem appears to be your PATH variable. In your path you have the following directory: C:/Program Files/Microsoft DirectX SDK (June

Hi! I'm trying to build LLVM under cygwin. I have the latest version of cygwin and CVS versions of llvm, llvm-test and llvm-gcc. make of tools only succeeded. make of frontend succeeded too but full make of llvm failed on crtend in llvm/runtime/GCCLibraries with the following message: llvm[0]: Compiling crtend.c for Debug build (bytecode) /bin/sh: -c: line 0: syntax error near unexpected

..../../intl/libintl.a -liconv ../libiberty/libiberty.a /llvm-gcc/obj/gcc/xgcc -B/llvm-gcc/obj/gcc/ -B/llvm-gcc/../install//i686-pc-cygwin/bin/ -B/llvm-gcc/../install//i686-pc-cygwin/lib/ -isystem /llvm-gcc/../install//i686-pc-cygwin/include -isystem /llvm-gcc/../install//i686-pc-cygwin/sys-include -dumpspecs > tmp-specs mv tmp-specs specs if ; then \ cat ../../src/gcc/limitx.h ../../src/gcc/glimits.h ../../src/gcc/limity.h > tmp-xlimits.h; \ else \ cat ../../src/gcc/glimits.h > tmp-xlimits.h; \ fi make[1]: Leaving directory `/llvm-gcc/obj/gcc' I though it was ld error, first, and...

Hi, It would be nice if it were easier for relative novices to build whole-program bitcodes for large, complex applications with hairy build systems. Several readers of this list have been trying various approaches for a few months but as far as I know we haven't yet found a good general solution. Approaches that have been tried include 1) placing wrappers for the usual tools (gcc, ar, as,