In trying to package up LLVM for Debian, it appears that x86_64 is no
longer a supported architecture -- so, my first question is, is that
correct? Best I can tell, the only thing that's supposed to work for
x86_64 is the C backend.
For Debian, I need to build everything from scratch. When trying to
build llvm-gcc4 from source, though, I get part way through the build
and am told that x86_64-unknown-linux-pc is an unsupported architecture.
What I have tried so far is this quick and dirty patch to
gcc/Makefile.in:
-------------------------------------------------------------------------
diff -urNad llvm-1.7~/llvm-gcc4-1.7.source/gcc/Makefile.in \
llvm-1.7/llvm-gcc4-1.7.source/gcc/Makefile.in
--- llvm-1.7~/llvm-gcc4-1.7.source/gcc/Makefile.in 2006-04-19
15:51:47.000000000 -0600
+++ llvm-1.7/llvm-gcc4-1.7.source/gcc/Makefile.in 2006-07-09
20:29:57.000000000 -0600
@@ -827,6 +827,7 @@
powerpc*-*-*) echo LLVMPowerPC.o;; \
sparc-*-*) echo LLVMSparc.o;; \
sparcv9-*-*) echo LLVMSparc.o;; \
+ x86_64-*-*-*) echo LLVMCBackend.o;; \
esac
LLVMTARGETOBJ := $(shell $(LLVMTARGETOBJCMD))
----------------------------------------------------------------------
Yes, it is a hack, but it does let me get further. I can get to this
point in compiling the C front-end:
----------------------------------------------------------------------
[...snip...]
gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H
-DENABLE_LLVM -D__STDC_LIMIT_MACROS -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include
-I/home/ahs3/tmp/llvm-1.7/llvm/include ../../gcc/cgraph.c -o cgraph.o
gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H
-DENABLE_LLVM -D__STDC_LIMIT_MACROS -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include
-I/home/ahs3/tmp/llvm-1.7/llvm/include ../../gcc/cgraphunit.c -o
cgraphunit.o
gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H
-DENABLE_LLVM -D__STDC_LIMIT_MACROS -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include
-I/home/ahs3/tmp/llvm-1.7/llvm/include ../../gcc/tree-nomudflap.c -o
tree-nomudflap.o
rm -rf libbackend.a
ar rc libbackend.a tree-chrec.o tree-scalar-evolution.o tree-data-ref.o
tree-cfg.o tree-dfa.o tree-eh.o tree-ssa.o tree-optimize.o tree-gimple.o
gimplify.o tree-pretty-print.o tree-into-ssa.o tree-outof-ssa.o
tree-ssa-ccp.o tree-vn.o tree-ssa-dce.o tree-ssa-copy.o tree-nrv.o
tree-ssa-copyrename.o tree-ssa-pre.o tree-ssa-live.o tree-ssa-operands.o
tree-ssa-alias.o tree-ssa-phiopt.o tree-ssa-forwprop.o tree-nested.o
tree-ssa-dse.o tree-ssa-dom.o domwalk.o tree-tailcall.o gimple-low.o
tree-iterator.o tree-phinodes.o tree-ssanames.o tree-sra.o
tree-complex.o tree-ssa-loop.o tree-ssa-loop-niter.o
tree-ssa-loop-manip.o tree-ssa-threadupdate.o tree-vectorizer.o
tree-vect-analyze.o tree-vect-transform.o tree-ssa-loop-ivcanon.o
tree-ssa-propagate.o tree-ssa-loop-ivopts.o tree-if-conv.o
tree-ssa-loop-unswitch.o alias.o bb-reorder.o bitmap.o builtins.o
caller-save.o calls.o cfg.o cfganal.o cfgbuild.o cfgcleanup.o
cfglayout.o cfgloop.o cfgloopanal.o cfgloopmanip.o loop-init.o
loop-unswitch.o loop-unroll.o cfgrtl.o combine.o conflict.o convert.o
coverage.o cse.o cselib.o tree-ssa-loop-prefetch.o
tree-ssa-loop-memset.o dbxout.o ddg.o tree-ssa-loop-ch.o
loop-invariant.o tree-ssa-loop-im.o debug.o df.o diagnostic.o dojump.o
dominance.o loop-doloop.o dwarf2asm.o dwarf2out.o emit-rtl.o except.o
explow.o loop-iv.o expmed.o expr.o final.o flow.o fold-const.o
function.o gcse.o genrtl.o ggc-common.o global.o graph.o gtype-desc.o
haifa-sched.o hooks.o ifcvt.o insn-attrtab.o insn-emit.o insn-modes.o
insn-extract.o insn-opinit.o insn-output.o insn-peep.o insn-recog.o
integrate.o intl.o jump.o langhooks.o lcm.o lists.o local-alloc.o
loop.o modulo-sched.o optabs.o options.o opts.o params.o postreload.o
postreload-gcse.o predict.o insn-preds.o pointer-set.o postreload.o
print-rtl.o print-tree.o profile.o value-prof.o var-tracking.o real.o
recog.o reg-stack.o regclass.o regmove.o regrename.o reload.o reload1.o
reorg.o resource.o rtl.o rtlanal.o rtl-error.o sbitmap.o sched-deps.o
sched-ebb.o sched-rgn.o sched-vis.o sdbout.o simplify-rtx.o sreal.o
stmt.o stor-layout.o stringpool.o targhooks.o timevar.o toplev.o
tracer.o tree.o tree-dump.o varasm.o varray.o vec.o version.o
vmsdbgout.o xcoffout.o alloc-pool.o et-forest.o cfghooks.o bt-load.o
pretty-print.o ggc-page.o web.o passes.o rtl-profile.o tree-profile.o
rtlhooks.o cfgexpand.o lambda-mat.o lambda-trans.o lambda-code.o
tree-loop-linear.o llvm-backend.o llvm-convert.o llvm-types.o
llvm-debug.o i386.o host-linux.o tree-inline.o cgraph.o cgraphunit.o
tree-nomudflap.o
ranlib libbackend.a
# APPLE LOCAL LLVM
g++ -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H -o
cc1-dummy c-parse.o c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o
c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o
c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o
c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-gimplify.o
tree-mudflap.o c-pretty-print.o dummy-checksum.o \
llvm-main.o
libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a ../libiberty/libiberty.a
-L/home/ahs3/tmp/llvm-1.7/llvm/Release/lib
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMCBackend.o -lLLVMScalarOpts
-lLLVMTransformUtils -lLLVMAnalysis
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMSelectionDAG.o
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMCodeGen.o -lLLVMTarget
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMBCWriter.o
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMbzip2.o
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMCore.o -lLLVMSupport -lLLVMSystem
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMCBackend.o: In function
`__static_initialization_and_destruction_0(int, int)':
Writer.cpp:(.text+0x379): undefined reference to
`llvm::FindUsedTypes::stub()'
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMCBackend.o: In function
`(anonymous
namespace)::CBackendNameAllUsedStructsAndMergeFunctions::runOnModule(llvm::Module&)':
(.text+0x3f45): undefined reference to `typeinfo for
llvm::FindUsedTypes'
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMCBackend.o: In function
`(anonymous
namespace)::CBackendNameAllUsedStructsAndMergeFunctions::runOnModule(llvm::Module&)':
(.text+0x3f9e): undefined reference to `typeinfo for
llvm::FindUsedTypes'
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMCBackend.o: In function
`llvm::AnalysisUsage&
llvm::AnalysisUsage::addRequired<llvm::FindUsedTypes>()':
(.text._ZN4llvm13AnalysisUsage11addRequiredINS_13FindUsedTypesEEERS0_v[llvm::AnalysisUsage&
llvm::AnalysisUsage::addRequired<llvm::FindUsedTypes>()]+0x5): undefined
reference to `typeinfo for llvm::FindUsedTypes'
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMCBackend.o: In function
`llvm::AnalysisUsage&
llvm::AnalysisUsage::addRequired<llvm::FindUsedTypes>()':
(.text._ZN4llvm13AnalysisUsage11addRequiredINS_13FindUsedTypesEEERS0_v[llvm::AnalysisUsage&
llvm::AnalysisUsage::addRequired<llvm::FindUsedTypes>()]+0x18): undefined
reference to `typeinfo for llvm::FindUsedTypes'
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMCBackend.o: In function
`llvm::FindUsedTypes&
llvm::Pass::getAnalysisID<llvm::FindUsedTypes>(llvm::PassInfo const*)
const':
(.text._ZNK4llvm4Pass13getAnalysisIDINS_13FindUsedTypesEEERT_PKNS_8PassInfoE[llvm::FindUsedTypes&
llvm::Pass::getAnalysisID<llvm::FindUsedTypes>(llvm::PassInfo const*)
const]+0x53): undefined reference to `typeinfo for llvm::FindUsedTypes'
/home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMCBackend.o:(.text._ZNK39_GLOBAL__N_Writer.cpp_00000000_B790B1D643CBackendNameAllUsedStructsAndMergeFunctions16getAnalysisUsageERN4llvm13AnalysisUsageE[(anonymous
namespace)::CBackendNameAllUsedStructsAndMergeFunctions::getAnalysisUsage(llvm::AnalysisUsage&)
const]+0x2): more undefined references to `typeinfo for llvm::FindUsedTypes'
follow
collect2: ld returned 1 exit status
make[3]: *** [cc1-dummy] Error 1
make[3]: Leaving directory
`/home/ahs3/tmp/llvm-1.7/llvm-gcc4-1.7.source/build/gcc'
make[2]: *** [all-gcc] Error 2
make[2]: Leaving directory
`/home/ahs3/tmp/llvm-1.7/llvm-gcc4-1.7.source/build'
make[1]: *** [stamp/build-stamp] Error 20
make[1]: Leaving directory `/home/ahs3/tmp/llvm-1.7'
make: *** [install-arch] Error 2
--------------------------------------------------------------------
My first question is: should I even attempt to get things working
for x86_64, or has it been tried and abandoned? The second question
is, is this even a reasonable approach? (I have to claim an apparent
lack of detailed understanding of the build system, at this point).
I'm more than willing to believe I've started going about this all
wrong...
Pointers, suggestions, RTFM are all greatly appreciated.
--
Ciao,
al
----------------------------------------------------------------------
Al Stone Alter Ego:
Open Source and Linux R&D Debian Developer
Hewlett-Packard Company http://www.debian.org
E-mail: ahs3 at fc.hp.com ahs3 at debian.org
----------------------------------------------------------------------
On Mon, 10 Jul 2006, Al Stone wrote:> In trying to package up LLVM for Debian, it appears that x86_64 is no > longer a supported architecture -- so, my first question is, is that > correct?Yes and no :(. It's not that it is unsupported, it is just that noone has tested it and made it work.> Best I can tell, the only thing that's supposed to work for > x86_64 is the C backend.Right. This isn't something new unfortunately, the X86 backend doesn't support x86-64 yet.> For Debian, I need to build everything from scratch. When trying to > build llvm-gcc4 from source, though, I get part way through the build > and am told that x86_64-unknown-linux-pc is an unsupported architecture. > What I have tried so far is this quick and dirty patch to > gcc/Makefile.in:This makes sense.> Yes, it is a hack, but it does let me get further. I can get to this > point in compiling the C front-end: > Writer.cpp:(.text+0x379): undefined reference to > `llvm::FindUsedTypes::stub()' > /home/ahs3/tmp/llvm-1.7/llvm/Release/lib/LLVMCBackend.o: In functionOkay, there are two problems with this. 1. llvm-gcc4, as of llvm-1.7, hardcoded in a list of libraries to link in, which apparently don't satisfy the dependencies needed by the C backend. This is easily solvable. If you use current llvm-gcc4 from svn, available here: http://llvm.org/docs/CFEBuildInstrs.html, a similar patch to the makefile will work better. The makefile will automatically infer that an extra lib is needed and link it in. 2. More seriously, this will cause 'llvm-gcc x.c -S -o x.s' to put C code into x.s, which will cause the assembler to barf (e.g. when -c is used). OTOH, "llvm-gcc -emit-llvm x.c -S -o x.ll" will work. Unfortunately, the former is used by the GCC build process. I don't know if the workarounds for #2 are really worth it at this point.> My first question is: should I even attempt to get things working > for x86_64, or has it been tried and abandoned? The second question > is, is this even a reasonable approach? (I have to claim an apparent > lack of detailed understanding of the build system, at this point). > I'm more than willing to believe I've started going about this all > wrong...My only suggestion is that it might be worth trying to map x86_64 to the X86 backend. It would "fix" #2 (x86 assembly would end up in .s files, though it probably won't work right because it is 32-bit). Some minor hacks might be needed in the x86 backend to accept the x86_64 target triple, but that would probably be easier. We're currently in crunch mode right now, but I'd like to build a proper x86-64 backend for LLVM one day when time permits. Perhaps in a couple of months I'll have more time to work on it. In the meantime, it would be quite reasonable to use llvm-gcc3 for the llvm1.7 debian package. Thanks Al! -Chris -- http://nondot.org/sabre/ http://llvm.org/
Reasonably Related Threads
- [LLVMdev] Merge-Cha-Cha
- [LLVMdev] Adding an object to llc (analysis pass)
- [LLVMdev] Boostrap Failure -- Expected Differences?
- [LLVMdev] link problem with llvm-pass
- [LLVMdev] newbie llc build problem: BreakCriticalEdges.cpp:44: undefined reference to `llvm::LoopSimplifyID'