Tried to cross compile llvm to ppc and llvm configure didn't like cross building in src tree so I created a build dir. Futhermore, llvm depends on perl but as far as I can see only llvm-config needs perl so I commented out perl. Some missing IUSE flags as well. Now it cross builds. Here is a diff of my small hack, figured it could be useful for others too: --- llvm-2.9-r2.ebuild 2012-07-03 17:01:28.000000000 +0200 +++ /root/llvm-2.9-r2.ebuild 2012-11-12 17:44:12.319422580 +0100 @@ -11,10 +11,11 @@ LICENSE="UoI-NCSA" SLOT="0" -KEYWORDS="amd64 ~ppc x86 ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos" -IUSE="debug +libffi llvm-gcc multitarget ocaml test udis86 vim-syntax" +KEYWORDS="amd64 ppc x86 ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos" +IUSE="debug +libffi llvm-gcc multitarget ocaml test udis86 vim-syntax amd64" -DEPEND="dev-lang/perl +#DEPEND="dev-lang/perl +DEPEND=" >=sys-devel/make-3.79 >=sys-devel/flex-2.5.4 >=sys-devel/bison-1.875d @@ -25,11 +26,13 @@ ocaml? ( dev-lang/ocaml ) udis86? ( amd64? ( dev-libs/udis86[pic] ) !amd64? ( dev-libs/udis86 ) )" -RDEPEND="dev-lang/perl +#RDEPEND="dev-lang/perl +RDEPEND=" libffi? ( virtual/libffi ) vim-syntax? ( || ( app-editors/vim app-editors/gvim ) )" S=${WORKDIR}/${PN}-${PV/_pre*} +ECONF_SOURCE=${S} pkg_setup() { # need to check if the active compiler is ok @@ -145,10 +148,13 @@ append-cppflags "$(pkg-config --cflags libffi)" fi CONF_FLAGS="${CONF_FLAGS} $(use_enable libffi)" + mkdir -p ${ECONF_SOURCE}/gentoo-build + cd ${ECONF_SOURCE}/gentoo-build econf ${CONF_FLAGS} || die "econf failed" } src_compile() { + cd ${ECONF_SOURCE}/gentoo-build emake VERBOSE=1 KEEP_SYMBOLS=1 REQUIRES_RTTI=1 || die "emake failed" pax-mark m Release/bin/lli @@ -158,6 +164,7 @@ } src_install() { + cd ${ECONF_SOURCE}/gentoo-build emake KEEP_SYMBOLS=1 DESTDIR="${D}" install || die "install failed" if use vim-syntax; then
Could you try one of the newest ebuilds? They use out-of-source builds already, so I suspect your root issue has been fixed.
Well, I am past this and don't need it ATM. Anyhow, the RDEPEND on perl is a blocker too, perhaps you can add an USE flag to skip perl?
Perl is only in RDEPEND if clang and static-analyzer are enabled.
Cross compiling amd64 to arm, I needed to patch for a successful emerge. The following link was helpful: http://llvm.org/docs/HowToCrossCompileLLVM.html. My system has a couple of elibtoolize patches, so if the attachment is insufficient, then check out https://bugs.gentoo.org/show_bug.cgi?id=572038 (attachments https://572038.bugs.gentoo.org/attachment.cgi?id=423412 and https://572038.bugs.gentoo.org/attachment.cgi?id=423414 for /usr/portage/eclass/ELT-patches/cross/link-ROOT-2.4.4 and /usr/portage/eclass/ELT-patches/cross/link-ROOT, respectively)
Created attachment 423458 [details, diff] CMake flags for cross compilation
Comment on attachment 423458 [details, diff] CMake flags for cross compilation >--- /usr/portage/sys-devel/llvm/llvm-3.7.1.ebuild 2016-01-09 19:01:02.000000000 +0000 >+++ llvm-3.7.1.ebuild 2016-01-20 21:11:18.701967929 +0000 ... >+ if use clang; then >+ mycmakeargs+=( >+ -DCLANG_TABLEGEN=/usr/bin/clang-tblgen >+ -DLLVM_ENABLE_PIC=False # Work around. See http://llvm.org/docs/HowToCrossCompileLLVM.html >+ ) >+ fi I haven't tested with clang, so I can't vouch for the sufficiency of this branch, but it conforms to the llvm maintained link.
(In reply to popham from comment #5) > Created attachment 423458 [details, diff] [details, diff] > CMake flags for cross compilation (In reply to popham from comment #6) > Comment on attachment 423458 [details, diff] [details, diff] > CMake flags for cross compilation > > >--- /usr/portage/sys-devel/llvm/llvm-3.7.1.ebuild 2016-01-09 19:01:02.000000000 +0000 > >+++ llvm-3.7.1.ebuild 2016-01-20 21:11:18.701967929 +0000 > ... > >+ if use clang; then > >+ mycmakeargs+=( > >+ -DCLANG_TABLEGEN=/usr/bin/clang-tblgen > >+ -DLLVM_ENABLE_PIC=False # Work around. See http://llvm.org/docs/HowToCrossCompileLLVM.html > >+ ) > >+ fi > > I haven't tested with clang, so I can't vouch for the sufficiency of this > branch, but it conforms to the llvm maintained link. The patch is fine. The only correction that I'd make is to omit the line with "-DLLVM_ENABLE_PIC=False". According to the LLVM notes, that should only be included when using LLVM/CLANG as a cross-compiler to compile itself. It should be unnecessary when cross-compiling it with gcc. And Gentoo, I believe, only supports gcc as a cross-compiler. I would also just add checks to make sure that "/usr/bin/llvm-tblgen" and "/usr/bin/clang-tblgen" exist and are executable (since it's possible to incorrectly attempt to cross-compile a HOST clang/llvm without having a BUILD clang/llvm).
Created attachment 433256 [details, diff] Updated patch for llvm-3.7.1-r1.ebuild Compiles and installs successfully with USE="clang" (CHOST=armv7a-hardfloat-linux-gnueabi CBUILD=x86_64-pc-linux-gnu).
Created attachment 437338 [details, diff] llvm-3.8.0-r2.ebuild.patch (In reply to Peter Levine from comment #7) > The only correction that I'd make is to omit the line > with "-DLLVM_ENABLE_PIC=False". According to the LLVM notes, that should > only be included when using LLVM/CLANG as a cross-compiler to compile > itself. It should be unnecessary when cross-compiling it with gcc. And > Gentoo, I believe, only supports gcc as a cross-compiler. On the other hand, I do believe that clang supports cross-compiling with the "multitarget" use flag and it isn't much trouble checking if ${CXX%++} == "clang".
I'm not saying it wouldn't work... but is there any reason you're suggesting the ++ stripping instead of comparing with clang++?
Created attachment 437408 [details, diff] llvm-3.8.0-r2.ebuild.patch (In reply to Michał Górny from comment #10) > I'm not saying it wouldn't work... but is there any reason you're suggesting > the ++ stripping instead of comparing with clang++? For some reason I was under the impression that since clang++ was a symlink to clang it had the potential to be called via ${CXX} for c++ code. That appears not to be the case as clang will not work with c++ code.
(In reply to Peter Levine from comment #11) > Created attachment 437408 [details, diff] [details, diff] > llvm-3.8.0-r2.ebuild.patch > > (In reply to Michał Górny from comment #10) > > I'm not saying it wouldn't work... but is there any reason you're suggesting > > the ++ stripping instead of comparing with clang++? > > For some reason I was under the impression that since clang++ was a symlink > to clang it had the potential to be called via ${CXX} for c++ code. That > appears not to be the case as clang will not work with c++ code. Please do [[ ${CXX} == *clang* ]] as it can be called as ${CHOST}-clang++, plus can take some args like '-m32'. Using just 'clang' wouldn't hurt and can help if someone is crazy enough to do 'clang -x c++' ;-).
Oh, @kde, could you look at the patch wrt cmake cross-compiling? Also, I think ${SYSROOT} should be used for host tools.
Created attachment 437438 [details, diff] llvm-3.8.0-r2.ebuild.patch (In reply to Michał Górny from comment #12) > Please do [[ ${CXX} == *clang* ]] as it can be called as ${CHOST}-clang++, > plus can take some args like '-m32'. Using just 'clang' wouldn't hurt and > can help if someone is crazy enough to do 'clang -x c++' ;-). OK. (In reply to Michał Górny from comment #13) > Also, I think ${SYSROOT} should be used for host tools. Correct me if I'm wrong but SYSROOT defaults to /usr/${CHOST} (at least in cross-wrappers) and llvm-tblgen and clang-tblgen need to be run at build time. Context of usage of HOST, BUILD, TARGET has often confused me and LLVM documentation uses "HOST" when they refer to "BUILD".
Created attachment 437458 [details, diff] llvm-3.8.0-r2.ebuild.patch Having just cross-compiled LLVM/clang with both gcc and LLVM/clang, the patch reflects the following changes: -DCMAKE_CXX_FLAGS="-I${EROOT}usr/include/" had the effect of stripping all CXXFLAGS and appending "-I${EROOT}usr/include/". The include is entirely unnecessary. With the -O[12] flags, however, gcc freezes about 1/3 of the way through. The best course of action is to "strip-flags" and "filter-flags -O*" as that will ensure at least arch dependent flags like -mcpu, -mfloat-abi, and -march still make it to CXXFLAGS. To cross-compile with LLVM/clang, appending -target ${CHOST} and --sysroot="${SYSROOT}" to the CFLAGS/CXXFLAGS was necessary.
Comment on attachment 437458 [details, diff] llvm-3.8.0-r2.ebuild.patch >--- llvm-3.8.0-r2.ebuild.old 2016-06-12 23:54:20.583749524 -0400 >+++ llvm-3.8.0-r2.ebuild 2016-06-13 19:37:05.757431300 -0400 >@@ -358,6 +358,28 @@ > #filter-flags -msahf -frecord-gcc-switches > fi > >+ if tc-is-cross-compiler; then >+ strip-flags >+ filter-flags -O* I don't think this really belongs here. If gcc hangs, it's a problem with gcc that needs to be solved in gcc. >+ [[ ${CXX} == *clang* ]] && \ >+ append-flags -target ${CHOST} --sysroot="${SYSROOT}" Unless I'm missing something, this really belongs in your CXXFLAGS/generic setup and not the ebuild... >+ [[ -x "/usr/bin/llvm-tblgen" ]] || \ >+ die "/usr/bin/llvm-tblgen not found or usable" >+ mycmakeargs+=( >+ -DCMAKE_CROSSCOMPILING=True >+ -DLLVM_TABLEGEN=/usr/bin/llvm-tblgen >+ ) >+ >+ if use clang; then >+ [[ -x "/usr/bin/clang-tblgen" ]] || \ >+ die "/usr/bin/clang-tblgen not found or usable" >+ mycmakeargs+=(-DCLANG_TABLEGEN=/usr/bin/clang-tblgen) This part looks good. Committed it. >+ [[ ${CXX} == *clang* ]] && \ >+ mycmakeargs+=(-DLLVM_ENABLE_PIC=False) What's the rationale for this?
(In reply to Michał Górny from comment #16) > Comment on attachment 437458 [details, diff] [details, diff] > llvm-3.8.0-r2.ebuild.patch > > >--- llvm-3.8.0-r2.ebuild.old 2016-06-12 23:54:20.583749524 -0400 > >+++ llvm-3.8.0-r2.ebuild 2016-06-13 19:37:05.757431300 -0400 > >@@ -358,6 +358,28 @@ > > #filter-flags -msahf -frecord-gcc-switches > > fi > > > >+ if tc-is-cross-compiler; then > >+ strip-flags > >+ filter-flags -O* > > I don't think this really belongs here. If gcc hangs, it's a problem with > gcc that needs to be solved in gcc. According to http://llvm.org/docs/HowToCrossCompileLLVM.html, if compiling with GCC, use '-DCMAKE_CXX_FLAGS=' with arch dependent flags like -march, -mcpu, -mfloat-abi, etc... This, however, has the same effect as redefining CXXFLAGS with those flags. Cross-compiling LLVM is unsupported for -O flags since they're not arch dependent. Since there is no flag-o-matic function "strip-all-flags-but-arch-dependent-ones" and since "strip-flags" does such a good job of stripping most non-arch-dependent flags, and since -O flags aren't technically supposed to be included and, having tested them, cause failures, I went this route. > >+ [[ ${CXX} == *clang* ]] && \ > >+ append-flags -target ${CHOST} --sysroot="${SYSROOT}" > > Unless I'm missing something, this really belongs in your CXXFLAGS/generic > setup and not the ebuild... From http://llvm.org/docs/HowToCrossCompileLLVM.html: > However, if you’re using Clang,... > In addition to the ones above, you’ll also need: > '-target arm-linux-gnueabihf' or whatever is the triple of your cross GCC. > '--sysroot=/usr/arm-linux-gnueabihf', '--sysroot=/opt/gcc/arm-linux-gnueabihf' > or whatever is the location of your GCC’s sysroot (where /lib, /bin etc are). > > >+ [[ ${CXX} == *clang* ]] && \ > >+ mycmakeargs+=(-DLLVM_ENABLE_PIC=False) > > What's the rationale for this? See http://llvm.org/docs/HowToCrossCompileLLVM.html and scroll to "Hacks" section, entry 1.
(In reply to Peter Levine from comment #17) > (In reply to Michał Górny from comment #16) > > Comment on attachment 437458 [details, diff] [details, diff] [details, diff] > > llvm-3.8.0-r2.ebuild.patch > > > > >--- llvm-3.8.0-r2.ebuild.old 2016-06-12 23:54:20.583749524 -0400 > > >+++ llvm-3.8.0-r2.ebuild 2016-06-13 19:37:05.757431300 -0400 > > >@@ -358,6 +358,28 @@ > > > #filter-flags -msahf -frecord-gcc-switches > > > fi > > > > > >+ if tc-is-cross-compiler; then > > >+ strip-flags > > >+ filter-flags -O* > > > > I don't think this really belongs here. If gcc hangs, it's a problem with > > gcc that needs to be solved in gcc. > > According to http://llvm.org/docs/HowToCrossCompileLLVM.html, if compiling > with GCC, use '-DCMAKE_CXX_FLAGS=' with arch dependent flags like -march, > -mcpu, -mfloat-abi, etc... > This, however, has the same effect as redefining CXXFLAGS with those flags. > Cross-compiling LLVM is unsupported for -O flags since they're not arch > dependent. Since there is no flag-o-matic function > "strip-all-flags-but-arch-dependent-ones" and since "strip-flags" does such > a good job of stripping most non-arch-dependent flags, and since -O flags > aren't technically supposed to be included and, having tested them, cause > failures, I went this route. Then you redefine your CXXFLAGS for this package, and don't force it for everyone. package.env. > > >+ [[ ${CXX} == *clang* ]] && \ > > >+ append-flags -target ${CHOST} --sysroot="${SYSROOT}" > > > > Unless I'm missing something, this really belongs in your CXXFLAGS/generic > > setup and not the ebuild... > > From http://llvm.org/docs/HowToCrossCompileLLVM.html: > > > However, if you’re using Clang,... > > In addition to the ones above, you’ll also need: > > '-target arm-linux-gnueabihf' or whatever is the triple of your cross GCC. > > '--sysroot=/usr/arm-linux-gnueabihf', '--sysroot=/opt/gcc/arm-linux-gnueabihf' > > or whatever is the location of your GCC’s sysroot (where /lib, /bin etc are). > > > > > >+ [[ ${CXX} == *clang* ]] && \ > > >+ mycmakeargs+=(-DLLVM_ENABLE_PIC=False) > > > > What's the rationale for this? > > See http://llvm.org/docs/HowToCrossCompileLLVM.html and scroll to "Hacks" > section, entry 1. This also mentions that it's a not a problem because they're using static libraries. But in Gentoo we're building shared libraries, and this makes it a problem since non-PIC libraries won't work e.g. on amd64.
(In reply to Michał Górny from comment #18) > (In reply to Peter Levine from comment #17) > > (In reply to Michał Górny from comment #16) > > > Comment on attachment 437458 [details, diff] [details, diff] [details, diff] [details, diff] > > > llvm-3.8.0-r2.ebuild.patch > > > > > > >--- llvm-3.8.0-r2.ebuild.old 2016-06-12 23:54:20.583749524 -0400 > > > >+++ llvm-3.8.0-r2.ebuild 2016-06-13 19:37:05.757431300 -0400 > > > >@@ -358,6 +358,28 @@ > > > > #filter-flags -msahf -frecord-gcc-switches > > > > fi > > > > > > > >+ if tc-is-cross-compiler; then > > > >+ strip-flags > > > >+ filter-flags -O* > > > > > > I don't think this really belongs here. If gcc hangs, it's a problem with > > > gcc that needs to be solved in gcc. > > > > According to http://llvm.org/docs/HowToCrossCompileLLVM.html, if compiling > > with GCC, use '-DCMAKE_CXX_FLAGS=' with arch dependent flags like -march, > > -mcpu, -mfloat-abi, etc... > > This, however, has the same effect as redefining CXXFLAGS with those flags. > > Cross-compiling LLVM is unsupported for -O flags since they're not arch > > dependent. Since there is no flag-o-matic function > > "strip-all-flags-but-arch-dependent-ones" and since "strip-flags" does such > > a good job of stripping most non-arch-dependent flags, and since -O flags > > aren't technically supposed to be included and, having tested them, cause > > failures, I went this route. > > Then you redefine your CXXFLAGS for this package, and don't force it for > everyone. package.env. > Have you taken a look at gcc_do_filter_flags() in toolchain.eclass? Isn't that what flag-o-matic is for? The expected, supported behavior for LLVM crosscompile is to define the CMAKE variable '-DCMAKE_CXX_FLAGS=' which should contain machine dependent flags. The LLVM build then uses those flags in the place of the CXXFLAGS variable. Stripping CXXFLAGS and not defining '-DCMAKE_CXX_FLAGS=' was the more permissive route. You could instead do an ewarn or use something like an "unsafe-optimizations" use-flag. This is a compiler. It's ultimately up to you and your tolerance for bug reports. > > > > > > >+ [[ ${CXX} == *clang* ]] && \ > > > >+ mycmakeargs+=(-DLLVM_ENABLE_PIC=False) > > > > > > What's the rationale for this? > > > > See http://llvm.org/docs/HowToCrossCompileLLVM.html and scroll to "Hacks" > > section, entry 1. > > This also mentions that it's a not a problem because they're using static > libraries. But in Gentoo we're building shared libraries, and this makes it > a problem since non-PIC libraries won't work e.g. on amd64. OK, then it should be omitted. I'm not sure of the consequences though.
(In reply to Peter Levine from comment #19) > (In reply to Michał Górny from comment #18) > > (In reply to Peter Levine from comment #17) > > > (In reply to Michał Górny from comment #16) > > > > Comment on attachment 437458 [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] > > > > llvm-3.8.0-r2.ebuild.patch > > > > > > > > >--- llvm-3.8.0-r2.ebuild.old 2016-06-12 23:54:20.583749524 -0400 > > > > >+++ llvm-3.8.0-r2.ebuild 2016-06-13 19:37:05.757431300 -0400 > > > > >@@ -358,6 +358,28 @@ > > > > > #filter-flags -msahf -frecord-gcc-switches > > > > > fi > > > > > > > > > >+ if tc-is-cross-compiler; then > > > > >+ strip-flags > > > > >+ filter-flags -O* > > > > > > > > I don't think this really belongs here. If gcc hangs, it's a problem with > > > > gcc that needs to be solved in gcc. > > > > > > According to http://llvm.org/docs/HowToCrossCompileLLVM.html, if compiling > > > with GCC, use '-DCMAKE_CXX_FLAGS=' with arch dependent flags like -march, > > > -mcpu, -mfloat-abi, etc... > > > This, however, has the same effect as redefining CXXFLAGS with those flags. > > > Cross-compiling LLVM is unsupported for -O flags since they're not arch > > > dependent. Since there is no flag-o-matic function > > > "strip-all-flags-but-arch-dependent-ones" and since "strip-flags" does such > > > a good job of stripping most non-arch-dependent flags, and since -O flags > > > aren't technically supposed to be included and, having tested them, cause > > > failures, I went this route. > > > > Then you redefine your CXXFLAGS for this package, and don't force it for > > everyone. package.env. > > > > Have you taken a look at gcc_do_filter_flags() in toolchain.eclass? Isn't > that what flag-o-matic is for? > > The expected, supported behavior for LLVM crosscompile is to define the > CMAKE variable '-DCMAKE_CXX_FLAGS=' which should contain machine dependent > flags. The LLVM build then uses those flags in the place of the CXXFLAGS > variable. Stripping CXXFLAGS and not defining '-DCMAKE_CXX_FLAGS=' was the > more permissive route. > > You could instead do an ewarn or use something like an > "unsafe-optimizations" use-flag. > > This is a compiler. It's ultimately up to you and your tolerance for bug > reports. > > > > > > > > > >+ [[ ${CXX} == *clang* ]] && \ > > > > >+ mycmakeargs+=(-DLLVM_ENABLE_PIC=False) > > > > > > > > What's the rationale for this? > > > > > > See http://llvm.org/docs/HowToCrossCompileLLVM.html and scroll to "Hacks" > > > section, entry 1. > > > > This also mentions that it's a not a problem because they're using static > > libraries. But in Gentoo we're building shared libraries, and this makes it > > a problem since non-PIC libraries won't work e.g. on amd64. > > OK, then it should be omitted. I'm not sure of the consequences though. (In reply to Michał Górny from comment #18) > (In reply to Peter Levine from comment #17) > > (In reply to Michał Górny from comment #16) > > > Comment on attachment 437458 [details, diff] [details, diff] [details, diff] [details, diff] > > > llvm-3.8.0-r2.ebuild.patch > > > > > > >--- llvm-3.8.0-r2.ebuild.old 2016-06-12 23:54:20.583749524 -0400 > > > >+++ llvm-3.8.0-r2.ebuild 2016-06-13 19:37:05.757431300 -0400 > > > >@@ -358,6 +358,28 @@ > > > > #filter-flags -msahf -frecord-gcc-switches > > > > fi > > > > > > > >+ if tc-is-cross-compiler; then > > > >+ strip-flags > > > >+ filter-flags -O* > > > > > > I don't think this really belongs here. If gcc hangs, it's a problem with > > > gcc that needs to be solved in gcc. > > > > According to http://llvm.org/docs/HowToCrossCompileLLVM.html, if compiling > > with GCC, use '-DCMAKE_CXX_FLAGS=' with arch dependent flags like -march, > > -mcpu, -mfloat-abi, etc... > > This, however, has the same effect as redefining CXXFLAGS with those flags. > > Cross-compiling LLVM is unsupported for -O flags since they're not arch > > dependent. Since there is no flag-o-matic function > > "strip-all-flags-but-arch-dependent-ones" and since "strip-flags" does such > > a good job of stripping most non-arch-dependent flags, and since -O flags > > aren't technically supposed to be included and, having tested them, cause > > failures, I went this route. > > Then you redefine your CXXFLAGS for this package, and don't force it for > everyone. package.env. So I just tested it with -O2 using a fresh stage-3 install. It compiled the first time without incident. The second time, in spite of freezing up for more than 15 minutes while linking 'bin/llvm-mc', it eventually continued. So I guess there is no serious problem with the CXXFLAGS after all. Sorry for the confusion.
Comment on attachment 437458 [details, diff] llvm-3.8.0-r2.ebuild.patch attempting to sanitize any target build flags (like CFLAGS or CXXFLAGS) and then re-use them to build build tools is always wrong. toolchain-funcs provides a bunch of BUILD_xxx variables and helper functions specifically for this purpose.
There is some cross code in the current versions, please open a new bug (with new patches) if there are still problems to be solved.
