Binutils and GCC version interdependencies? (cross compiler)

Hi
I have started again with trying to set up a cross compiler for the i386-plan9 target.
There is a very old port of the GNU toolchain to Plan9, which can be found at:
http://plan9.bell-labs.com/sources/extra/gcc/gnusrc.tgz
I tried apply the changes made to binutils (the first step in setting up a cross compiler) in a modern release, but during make, there was a complaint about not finding the i386_plan9_vec (I had changed the bfd/config.bfd and all the other stuff I could find by googling).
Because of this, I have now built the old (2.11.2) binutils from the original port (some cleaning up and minor source changes were needed to build on modern glibc, typedef change of sbrk for example).
This temporary build can be found at:
https://aur.archlinux.org/packages/i386-plan9-binutils/
The purpose of building this old version temporarily was to move on to the next steps and get the compiler and C library working (the two following steps for a cross compiler) to at least have a proof-of-concept cross compiler set up.
What I wonder now is : What is the newest version of GCC that can be expected to work using binutils 2.11.2?
I have not found any tables with version dependencies anywhere.
If anyone is interested in helping out experimenting, a tip for easy testing on Plan9 is to run Plan9 under 9vx
https://aur.archlinux.org/packages/9vx-hg/
https://wiki.archlinux.org/index.php/9vx
and try to execute resulting binaries from the cross compiler (that is at least the way I am going to try it out until I know that it works, and then I plan to take the toolchain native).

W.F.Cody wrote:What I wonder now is : What is the newest version of GCC that can be expected to work using binutils 2.11.2?
Hrm...  that is around 2006...  gcc-4.0 was released then.   I'd guess a few version newer would work too.

Similar Messages

  • Cross-compiling desirable

    I would really like to see the ability in the Studio compilers to cross compile SPARC code on x86 and vice versa.
    This would incentivize the OpenSolaris engineering team to support cross-compilation as well, I believe.
    The reason for this is that my build host for SPARC is a lot slower than the Opteron system I have. I suspect that I'm not alone in this, and that some folks may have the reverse.
    Support for cross-compilation would probably also help ISVs out that want to support both ISAs. Imagine having a single build host to build a product for a bunch of platforms. Folks already do this for gcc.
    I realize that a link step or somesuch is going to require a copy of the OS libraries and headers be installed, but its easy to get those from OpenSolaris (or even a stock Solaris build just installed or copied to an alternate directory).
    The only thing we can't solve in OpenSolaris itself to do this is making the compilers (code generation, assembler, and optimization) able to cross-compile. If Studio had this feature (and it shouldn't be hard to add), then we'd be able to take the next step to enable cross-compilation of Solaris itself.

    I agree that it would be very desirable.
    I don't necessarily agree that it wouldn't be too hard; it depends on how the compiler was designed.
    That said, one could also envisage a cross-compiler to earlier versions of Solaris, which would be neat (and should in fact be easier to do than true cross compilation). Currently, production builds have to be done on a machine running the earliest version of Solaris that you want to support. Version-cross-compilation would allow you to do the build on a later version of Solaris, but generate a binary that would work from the earlier version.
    Just a thought.
    /lib

  • Cross-compiling

    I'm using the Clang compiler (on i686) and would like to cross-compile for x86-64.
    The command I'm using is:
    $ clang -ccc-host-triple x86_64-unknown-linux [...]
    It seems to generate valid 64-bit assembler code but it's compiled in x86 mode.
    /tmp/cc-J3OsmS.s: Assembler messages:
    /tmp/cc-J3OsmS.s:36: Error: bad register name `%rbp'
    /tmp/cc-J3OsmS.s:38: Error: bad register name `%rsp'
    /tmp/cc-J3OsmS.s:40: Error: bad register name `%rdi'
    /tmp/cc-J3OsmS.s:41: Error: bad register name `%rbp)'
    /tmp/cc-J3OsmS.s:186: Error: `movabs' is only supported in 64-bit mode
    What's the recommended way of solving it?
    Clang uses the GCC assembler. Can I specify a different one, say nasm?
    So far, I only managed to find GCC cross-compile packages for ARM and some other architectures but not for x86-64.
    Any help is appreciated.
    Last edited by tindzk (2010-08-01 12:03:27)

    Compiling your PKGBUILD worked perfectly, thanks. I also added "--enable-64-bit-bfd" (cf. http://wiki.osdev.org/GCC_Cross-Compiler_for_x86_64)
    Modifying the PATH variable spawns at least the right "as"...
    export PATH=/usr/lib/cross-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/:$PATH
    ...but the errors posted above still remain, because "as" is getting passed "--32".
    So after lots of experimenting I came up with the following parameters:
    CC = clang -include config.h
    CC += -ccc-host-triple x86_64-unknown-linux
    CC += -m64
    CC += -Wa,--64
    CC += -Wl,"-L/usr/lib/cross-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/lib"
    CC += -Wl,"-melf_x86_64"
    CC += -v
    It's very hackish because Clang doesn't support proper cross-compiling on Linux. By the way, other architectures seem to have much more sophisticated heuristics: http://clang.llvm.org/doxygen/ToolChain … ource.html
    This all works fine for the assembler and I also managed to eliminate some errors with "ld" but it's not working completely. "ld" gets called like this:
    /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/collect2 --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o a.out /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../crt1.o /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/crtbegin.o -L/usr/lib/gcc/i686-pc-linux-gnu/4.5.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/../../.. -L/usr/lib/cross-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/lib -melf_x86_64 /tmp/cc-AIbI5G.o /tmp/cc-UiUGe7.o /tmp/cc-Kj0Hnx.o /tmp/cc-AIILwX.o /tmp/cc-yj4RFn.o /tmp/cc-6KT0ON.o /tmp/cc-ooccYd.o /tmp/cc-GTVp7D.o /tmp/cc-0DiGg4.o /tmp/cc-C7lZpu.o /tmp/cc-6OUkzU.o /tmp/cc-QwMVIk.o /tmp/cc-cY4MSK.o /tmp/cc-E2WG2a.o /tmp/cc-YwgDcB.o /tmp/cc-SFTBm1.o /tmp/cc-ki0Cwr.o /tmp/cc-IOEGGR.o /tmp/cc-C7CMQh.o /tmp/cc-sCQV0H.o /tmp/cc-cAB7a8.o /tmp/cc-I2Olly.o /tmp/cc-KttCvY.o /tmp/cc-wwrVFo.o /tmp/cc-ujWgQO.o /tmp/cc-gqUE0e.o /tmp/cc-4Ra5aF.o /tmp/cc-24Mxl5.o /tmp/cc-WtH2vv.o /tmp/cc-oeaAGV.o /tmp/cc-KzU9Ql.o /tmp/cc-WheM1L.o /tmp/cc-ONPqcc.o /tmp/cc-AuW8mC.o /tmp/cc-4NYUx2.o /tmp/cc-MujJIs.o /tmp/cc-W5eATS.o /tmp/cc-6UBt4i.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/crtend.o /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../crtn.o
    Interestingly, I'm experiencing exactly the same issue described in the sources:
    // FIXME: Figure out some way to get gcc's libdir
    // (e.g. /usr/lib/gcc/i486-linux-gnu/4.3/ for Ubuntu 32-bit); we need
    // crtbegin.o/crtend.o/etc., and want static versions of various
    // libraries. If we had our own crtbegin.o/crtend.o/etc, we could probably
    // get away with using shared versions in /usr/lib, though.
    // We could fall back to the approach we used for includes (a massive
    // list), but that's messy at best.
    Can I still use the 32-bit crtend.o or will it conflict?
    However, the command fails with:
    /usr/lib/cross-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/libgcc.a when searching for -lgcc
    /usr/lib/cross-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/ld: cannot find -lgcc
    What do I need libgcc for? Can I disable it? Looks like I have to compile the complete GCC toolchain otherwise.
    Last edited by tindzk (2010-08-03 13:13:42)

  • TTClasses C++ Shared Objs Names And gcc Compiler Versions

    3 versions of the TTClasses libraries are shipped with TimesTen due to the fact that gcc 3.2, 3.4. and 4.1 produce binaries that are not compatible with each other. For instance with 7.0.2 has the following libraries:
    libttclasses.so.gcc323
    libttclasses.so.gcc346
    libttclasses.so.gcc410
    It appears the naming convention of these libraries indicates the gcc compiler version out to 3 digits that TimesTen used to create the libraries.
    As new releases of TimesTen occur, when will the names of these 3 libraries change, i.e. when will TimesTen use a different version of the gcc compiler?
    It appears that in 7.0.2, 7.0.2.2, and 7.0.3, the names of libraries don't change. Would it only be possible for them to change for a major release, i.e. 7.X. Could it change for a minor release like 7.0.3.X or 7.0.X?
    The reason that I'm asking this is as follows:
    - When the TimesTen installer is run, it checks version of the gcc compiler, then it creates a symbolic link to the appropriate lib for that version of the compiler. It names this link libttclasses.so.
    - Up to now we have been linking our programs with libttclasses.so.
    - However when TimesTen is run on a machine without a compiler (which is the situation in our QA and prod environment), it appears to create a link to the gcc 3.2 lib.
    - This is a problem for us on Red Hat 4.0 because the default compiler is 3.4 which is what we are using, but the installer is creating a link to libttclasses.gcc323 when there is no compiler on Red Hat 4.0.
    - This causes our programs to crash.
    - To eliminate this we are considering linking directly with the appropriate library, i.e. libttclasses.gcc346 in our case.
    - However, we dont want to have to recompile or relink or application for future minor releases of TimesTen, i.e. 7.0.3.X or 7.0.X.
    - If the names of these files could change in minor releases, then we'd need to relink.
    Does anyone know the answer to this?
    Thanks.

    As you say, the names of the libraries comes directly from the GCC version used to build them. These names (i.e. GCC vesions) will not change between minor releases. Over time and major releases will tend to drop support for older GCC versions and add support for newer versions.
    Our strong recommendation is that you change the symbolic link to make libttclasses.sp point to the correct library and then link with libttclasses.so. This is the simplest and most 'future proof' method.
    Chris

  • Good instructions for making a GCC cross compiler?

    Hi
    I think this might be the best place to ask this since people probably have been making cross compilers. I am interested in trying to make a cross compiler of GCC targetting Plan9/i386. There is an old 3.0 version of GCC (http://cm.bell-labs.com/sources/extra/gcc/) ported to Plan9.
    The thing that confuses me a bit about cross compilers is the use of binutils for the target architecture. How does that actually work? The host OS/architecture would not be able to execute those binaries. It feels a bit like a chicken-and-egg issure and I am not really sure how to get started. I have been trying to read up a bit on the PKGBUILDs for cross-arm but the whole theoretical issue of how to actually get the thing working in the first place is still a bit unclear to me.
    Some good instructions/links/help would be appreciated
    I could post my temporary PKGBUILD here if people want to help out with the actual build...

    A small update to my attempts:
    This is my binutils package, it has failed at multiple levels during my attempts. The binutils ported to Plan9 are relatively old so some stuff needs to be patched up to build. Now it fails on not being able to recognize arlex.o . This seems a bit odd I think.
    # Adapted from cross-arm-elf, cross-i686-pc-gnu and cross-i686-pc-mingw32
    pkgname=cross-i386-plan9-binutils
    pkgver=2.11.2
    pkgrel=1
    pkgdesc="The GNU Compiler Collection - Cross compiler for Plan9 i386 target"
    arch=('i686' 'x86_64')
    license=('GPL')
    url="http://plan9.bell-labs.com/wiki/plan9/porting_alien_software_to_plan_9/index.html"
    depends=('glibc' 'zlib')
    options=('!libtool' '!distcc' '!ccache')
    source=('http://plan9.bell-labs.com/sources/extra/gcc/gnusrc.tgz' \
    'bucommh.patch')
    md5sums=('39d23b7223b68de4cf333205257112ce' \
    '2945c4e40dbcd966217ed1349195e312')
    _target=i386-lucent-plan9
    _sysroot=/usr/lib/cross-${_target}
    build() {
    rm -rf ${srcdir}/build
    mkdir ${srcdir}/build #starting fresh
    msg "building and packaging binutils"
    cp -ar ${srcdir}/binutils-2.11.2/* ${srcdir}/build/
    cd ${srcdir}/build
    msg "cheating broken references to Plan9-ported GNU binutils"
    ln -s /usr/bin/ar "${_target}-ar"
    ln -s /usr/bin/as "${_target}-as"
    ln -s /usr/bin/ld "${_target}-ld"
    ln -s /usr/bin/ranlib "${_target}-ranlib"
    PATH=${srcdir}/build:$PATH
    CFLAGS='-O2 -static'
    msg "patching up stuff"
    cd ${srcdir}/build/binutils
    patch bucomm.h -i $srcdir/bucommh.patch
    msg "going back to build directory and start configure"
    cd ${srcdir}/build
    ./configure --prefix=${_sysroot} --bindir=/usr/bin \
    --with-sysroot=${_sysroot} \
    --build=$CHOST --host=$CHOST --target=${_target} \
    --with-gcc --with-gnu-as --with-gnu-ld \
    --enable-shared --without-included-gettext \
    --disable-nls --disable-debug
    msg "fixing some corrupt libraries"
    cp /usr/lib/libiberty.a ${srcdir}/build/libiberty/
    msg "finally making the actual binutils"
    cd ${srcdir}/build
    make
    make DESTDIR=$pkgdir/ install
    # clean-up cross compiler root
    rm -r ${pkgdir}/${_sysroot}/share/{info,man}
    # needed for gcc build
    install -dm755 ${pkgdir}/${_sysroot}/include
    this is the bucommh.patch:
    81c81
    < extern char *sbrk ();
    > extern void *sbrk ();
    Last edited by W.F.Cody (2011-09-13 18:57:17)

  • Cross compiling apps on solaris 8 for solaris 10 x86 and x64

    Hi All,
    We have a few applications built on Solaris 8. and we want to build the same apps on Solaris 10 x86 and x64 but the problem is clearcase does not support Solaris 10 yet.
    Can we cross compile the apps on Solaris 8 for Solaris 10 x86 and x64 ? and how ?
    waiting for any info on this.
    TIA,
    warm regards,
    Girish

    FYI, I noticed the reply on Sun Studio General Forum:
    If you build an app on one version of Solaris, the app will run on later Solaris versions. So in particular, you can build an x86 application on Solaris 8 and run it on Solaris 9 and 10.
    Unfortunately, an x64 application must be built on a Solaris x64 system, which first became available with Solaris 10.

  • Problems with GCC version - compiling OpenOffice

    I am trying to compile OpenOffice 4.1.1 to run on 10.6.8. When I run the ./configure it runs for a few seconds then shows the following error:
    "checking the GNU gcc compiler version... configure: error: found version "1.0.2", use version 3+ of the gcc compiler"
    If I run:
    gcc -v
    I get:
    gcc version 4.2.1 (Apple Inc. build 5659)
    Any ideas on how to fix this?
    Thanks

    I suppose the real incentive is to be able to just continue using 10.6. But it seems from other feedback that the problem with OpenOffice 4.1 is dependencies on libraries in 10.7, rather than the GCC version. I know that I could probably eventually code around those dependencies, but it would certainly involve more time and effort than I am currently able to devote to it.
    I have tried LibreOffice in the past, but frankly I found it so horrible and slow (I think because of its dependency on Java) that I ended up using the X11 version of OpenOffice - which in itself was not a terrific user experience, but was a lot better than the alternative.
    I will try the version you have mentioned, but I also note that this is planned to be obsolete by May next year, and is also the last version that will support 10.6 or 10.7 (10.8 will be the lowest requirement). Which will leave a fair number of 64-bit intel machines unsupported, since some of those are only able to run 10.7. Thanks for the feedback.

  • Xcode using wrong and different version of GCC for linking

    I have had this problem with Xcode for several versions now. I am working on plain old C code, but I am using OpenMP. The code compiles just fine with gcc-4.2. If I set up a target to compile the code with OpenMP support and using version 4.2 of gcc, it again compiles just fine...until it gets to the link phase. It then suddenly decides to try linking with gcc-4.0 instead of 4.2. And therefore, it fails because it can't find any of the OpenMP libraries. Anybody else have this issue? Is there a setting somewhere I'm missing? I've got a nasty hack where I made gcc-4.0 a softlink to gcc-4.2. It works, but this is of course distasteful. A real solution would be nice.
    Note, I have not tried creating a brand new project file..that's a lot of work as there are many files and targets involved. But I will try it if I have to.
    Current version of Xcode is 3.1.3. Thanks again.
    David

    Not really, unless the answer is to build a whole new project file. I found this discussion earlier, but it didn't really provide any new information except the idea of creating a new project file. But like I said, if I have to do this, I will. But I don't want to go through the effort if there is a simpler solution...and without knowing for sure that it will even work.
    Thank you very much for your reply.
    Is there some defaults file I can check for what linker is used for a target? Some file I can edit directly?

  • Fortran code for iOS using GCC cross-compiler

    Hello everyone!
    I have some Fortran application, and i want to compile it for iOS. I'm new in iOS development and  as i understand correctly i need to configure GCC (from gcc.gnu.org) with --target=arm-apple-darwin and --enable-languages=c,c++, fortran.
    With --target=arm-elf, --target=arm-apple-darwin i got error, that it's not supported.
    With --target=arm-none-eabi i got cannot compute suffix of object files: cannot compile Maybe is that because i'm setting wrong configure parameters.
    My question is : what is correct ./confgiure parameters to create gcc cross compiler for iOS platform, which supports FORTRAN.
    Is this the only (right?) way to build cross-compiler for iOS platform, or i could use existing LLVM-GCC? Thanks!

    jasonwryan, thanks for the reply,
    I've read the ARM Dev Guide as suggested but I don't believe this will do what I'm aiming to achieve. It seems the ARM Dev Guide will install the arm-linux-gnueabi, which allows cross-compiling applications to run on LINUX built for ARM. I need something like arm-none-eabi (or arm-none-gnueabi - the whole naming scheme is a mess at the moment) which is an ARM compiler for "bare metal" ARM devices. I am aiming to program a simple ARM Cortex M4 microcontroller as opposed to an ARM microprocessor running Linux. Hence arm-linux-gnueabi is quite overkill from my understanding and it might even not work.
    So, if someone could either confirm that what the ARM Dev Guide suggests is indeed what I need to program a bare metal ARM microcontroller, or recommend an alternative path, it would be very appreciated.
    Thanks,
    -Igor

  • Cloning use the different gcc version between source system and target sys

    Hi All,
    Our system is: Application tier and Database tier is split to two servers.
    We should run a cloning, but I found the different gcc version on application tier on source system and target system.
    The source application tier server is RedHat Linux ES3, gcc version is 3.2.3
    The target application tier server is RedHat Linux ES3, gcc version is 2.9.6
    There is the same gcc version on database tier on source system and target system, they are gcc 2.9.6.
    My question: Can I use the different gcc version between source system and target system when I run an erp cloning?
    Thanks & Regards
    Owen

    Not necessarily, you might get some errors if the version is higher and it is not supported by the OS. An example is Note: 392311.1 - usr/lib/gcc/i386-redhat-linux/3.4.5/libgcc_s.so: undefined reference to 'dl_iterate_phdr@GLIBC_2.2.4'
    To be on the safe side, make sure you have the same version (unless you want to give it a try).

  • Create a cross compiler for arm

    I am struggling with building a cross toolchain, essentially it boils down to building these packages (in thegiven order):
    binutils gcc-base newlib gcc
    When done I am trying to compile a dummy cpp algorithm (euler gcd/ggT search) with no includes.
    What the cross toolchain spits at me is the following:
    $ arm-unknown-eabi-gcc -march=armv5te ./euklidisch_ggt.c -o ./euklidisch_ggt.bin.armv5te
    /usr/bin/arm-unknown-eabi-ld: skipping incompatible /usr/lib/gcc/arm-unknown-eabi/4.5.2/../../../../arm-unknown-eabi/lib/libc.a when searching for -lc
    /usr/bin/arm-unknown-eabi-ld: skipping incompatible /usr/arm-unknown-eabi/lib/libc.a when searching for -lc
    /usr/bin/arm-unknown-eabi-ld: cannot find -lc
    collect2: ld returned 1 exit status
    I wrote a little script to build it (as I got pretty much fed up doing it all by hund, round #7 just failed again)
    Note: it is semi-automated, you will still be requested to give your passwd to agree with install and blah
    Note: use it with arg "cleanup" to get rid of old installed packages (run as root)
    Note: use it to compile as user
    #!/bin/bash
    BUILDERUSER=buildmonkey
    PREFIX="/usr"
    TARGET="arm-unknown-eabi"
    PKGBUILDDIR="/home/${BUILDERUSER}/PKGBUILD"
    PKGS="binutils gcc-base newlib gcc"
    export PREFIX
    export TARGET
    export BUILDERUSER
    export PKGS
    export PKGBUILDDIR
    function cleanup
    for j in ${PKGS}
    do
    export j
    echo "Removing package ${TARGET}-${j}"
    su -c'pacman -R ${TARGET}-${j}'
    done
    function compile_and_install
    cd ${PKGBUILDDIR}
    echo ""
    echo ""
    echo "Compileing ${TARGET}-${1} ... "
    echo ""
    echo ""
    cd ./${TARGET}-${1}
    rm ./${TARGET}-${1}*
    makepkg -f || return 1
    su -c 'pacman -U ./${TARGET}-${1}*'
    echo ""
    if [ "${1}" == "cleanup" ]; then
    echo "cleanup requested...."
    cleanup
    exit 0
    fi
    if [ "$(id -u)" == "0" ]; then
    echo "This script must not be run as root!!" 1>&2
    exit 1
    fi
    echo ""
    if [ -d "${PKGBUILDDIR}" ]; then
    echo "PKGBUILD directory is ${PKGBUILDDIR}"
    else
    echo "PKGBUILD directory ${PKGBUILDDIR} is missing!!"
    exit 1
    fi
    echo "PKGs are ${PKGS}"
    echo ""
    for i in ${PKGS}
    do
    compile_and_install ${i}
    done
    exit 0
    The packagebuilds are as following (hacked away versions of the ones existing in AUR, which give me linker errors)
    binutils
    pkgname=arm-unknown-eabi-binutils
    pkgver=2.21
    pkgrel=1
    pkgdesc="A set of programs to assemble and manipulate binary and object files"
    arch=(i686 x86_64)
    license=(GPL)
    options=(!libtool)
    url="http://sources.redhat.com/binutils"
    depends=('glibc' 'zlib')
    source=(ftp://ftp.gnu.org/gnu/binutils/binutils-${pkgver}.tar.bz2)
    md5sums=('c84c5acc9d266f1a7044b51c85a823f5')
    build() {
    cd $srcdir/binutils-${pkgver}
    [ $NOEXTRACT -eq 1 ] || ./configure\
    --prefix=${PREFIX} \
    --program-prefix=${TARGET}- \
    --enable-shared \
    --disable-multilib \
    --with-lib-path=${PREFIX}/lib/binutils/{TARGET} \
    --disable-nls \
    --target=${TARGET} \
    --build=${CHOST} \
    --host=${CHOST}
    # mkdir -p $pkgdir/${PREFIX}/lib/binutils
    sed -i 's|know (S_GET_VALUE (frag->tc_frag_data.last_map) < S_GET_VALUE (symbolP));|{know (S_GET_VALUE (frag->tc_frag_data.last_map) < S_GET_VALUE (symbolP));}|' gas/config/tc-arm.c || return 1
    make configure-host
    make tooldir=$pkgdir/${PREFIX}
    make prefix=$pkgdir/${PREFIX} tooldir=$pkgdir/${PREFIX} install
    mkdir -p $pkgdir/${PREFIX}/lib/binutils/${TARGET}
    cp -v include/libiberty.h $pkgdir/${PREFIX}/lib/binutils/${TARGET}
    rm -f $pkgdir/${PREFIX}/man/man1/{dlltool,nlmconv,windres}*
    rm -f $pkgdir/usr/bin/ar
    rm -f $pkgdir/usr/bin/as
    rm -f $pkgdir/usr/bin/ld
    rm -f $pkgdir/usr/bin/nm
    rm -f $pkgdir/usr/bin/objdump
    rm -f $pkgdir/usr/bin/ranlib
    rm -f $pkgdir/usr/bin/strip
    rm -f $pkgdir/usr/bin/objcopy
    rm -f $pkgdir/usr/lib/libiberty.a
    rm -rf $pkgdir/usr/share
    rm -rf $pkgdir/usr/lib/ldscripts
    gcc-base
    pkgname=arm-unknown-eabi-gcc-base
    pkgver=4.5.2
    pkgrel=1
    pkgdesc="The GNU Compiler Collection"
    arch=(i686 x86_64)
    license=('GPL' 'LGPL')
    url="http://gcc.gnu.org"
    depends=('arm-unknown-eabi-binutils' 'libmpc' 'libelf' 'cloog-ppl')
    options=(!libtool !emptydirs zipman docs !strip)
    source=(ftp://gcc.gnu.org/pub/gcc/releases/gcc-${pkgver}/gcc-core-${pkgver}.tar.bz2)
    md5sums=('aa9e36bec080452372bfba793428ee82')
    build() {
    cd $srcdir/gcc-$pkgver
    export CFLAGS="-O2 -pipe"
    export CXXFLAGS="-O2 -pipe"
    [ $NOEXTRACT -eq 1 ] || rm -rf build
    mkdir build
    cd build
    [ $NOEXTRACT -eq 1 ] || ../configure --prefix=${PREFIX} \
    --target=${TARGET} \
    --host=$CHOST \
    --build=$CHOST \
    --enable-shared \
    --disable-nls \
    --enable-languages=c \
    --enable-multilib \
    --with-local-prefix=${PREFIX}/lib/${TARGET} \
    --with-as=${PREFIX}/bin/${TARGET}-as \
    --with-ld=${PREFIX}/bin/${TARGET}-ld \
    --enable-softfloat \
    --with-float=soft \
    --with-newlib
    make all-gcc all-target-libgcc
    make DESTDIR=$pkgdir install-gcc install-target-libgcc
    rm -f $pkgdir/usr/share/man/man7/fsf-funding.7*
    rm -f $pkgdir/usr/share/man/man7/gfdl.7*
    rm -f $pkgdir/usr/share/man/man7/gpl.7*
    rm -rf $pkgdir/usr/share/info
    cp -r $pkgdir/usr/libexec/* $pkgdir/usr/lib/
    rm -rf $pkgdir/usr/libexec
    # strip it manually
    strip $pkgdir/usr/bin/* 2>/dev/null || true
    find $pkgdir/usr/lib -type f -exec arm-none-eabi-strip {} \; 2>/dev/null || true
    newlib
    pkgname=arm-unknown-eabi-newlib
    pkgver=1.19.0
    pkgrel=1
    pkgdesc="Newlib is a C library intended for use on embedded systems."
    arch=('i686' 'x86_64')
    groups=('devel')
    url="http://sourceware.org/newlib/"
    license=('GPL')
    depends=('arm-unknown-eabi-binutils' 'arm-unknown-eabi-gcc-base')
    source=(ftp://sources.redhat.com/pub/newlib/newlib-${pkgver}.tar.gz)
    md5sums=('0966e19f03217db9e9076894b47e6601')
    build() {
    cd ${srcdir}
    rm -rf build
    mkdir build
    cd build
    export CFLAGS="-O2"
    ../newlib-${pkgver}/configure \
    --target=${TARGET} \
    --prefix=${PREFIX} \
    --enable-interwork \
    --enable-multilib \
    --with-gnu-as \
    --with-gnu-ld \
    --with-float=soft \
    --disable-nls || return 1
    make || return 1
    make -j1 DESTDIR=${pkgdir} install || return 1
    rm -rf ${pkgdir}/usr/share/info
    return 0
    gcc:
    pkgname=arm-unknown-eabi-gcc
    pkgver=4.5.2
    pkgrel=1
    pkgdesc="The GNU Compiler Collection - Cross compiler for ARM target"
    arch=(i686 x86_64)
    license=('GPL' 'LGPL')
    url="http://gcc.gnu.org"
    #an installed libc/newlib is needed for libstdc++ compile
    depends=('arm-unknown-eabi-binutils>=2.18' 'cloog-ppl>=0.15.3' 'arm-unknown-eabi-newlib>=1.18.0')
    # cross-arm-none-eabi-gcc is an superset of cross-arm-none-eabi-gcc-base
    conflicts=('arm-unknown-eabi-gcc-base')
    provides=("arm-unknown-eabi-gcc-base=${pkgver}")
    options=(!libtool !emptydirs !strip zipman docs)
    source=(ftp://gcc.gnu.org/pub/gcc/releases/gcc-${pkgver}/gcc-${pkgver}.tar.bz2)
    md5sums=('d6559145853fbaaa0fd7556ed93bce9a')
    build() {
    cd ${srcdir}/gcc-$pkgver
    export CFLAGS="-O2 -pipe"
    export CXXFLAGS="-O2 -pipe"
    rm -rf build
    mkdir build
    cd build
    ../configure \
    --prefix=${PREFIX} \
    --target=${TARGET} \
    --build=${CHOST} \
    --host=${CHOST} \
    --disable-nls \
    --enable-multilib \
    --enable-languages=c,c++ \
    --enable-__cxa_atexit \
    --enable-interwork \
    --with-local-prefix=${PREFIX}/lib/${TARGET} \
    --with-as=${PREFIX}/bin/${TARGET}-as \
    --with-ld=${PREFIX}/bin/${TARGET}-ld \
    --with-newlib \
    --with-float=soft
    make all-gcc all-target-libgcc all-target-libstdc++-v3 || return 1
    make DESTDIR=${pkgdir} install-gcc install-target-libgcc install-target-libstdc++-v3 || return 1
    rm -f $pkgdir/usr/share/man/man7/fsf-funding.7*
    rm -f $pkgdir/usr/share/man/man7/gfdl.7*
    rm -f $pkgdir/usr/share/man/man7/gpl.7*
    rm -rf $pkgdir/usr/share/info
    rm -rf $pkgdir/usr/share/gcc-4.5.2
    cp -r $pkgdir/usr/libexec/* $pkgdir/usr/lib/ && \
    rm -rf $pkgdir/usr/libexec
    I already read linux from scratch howto for building cross compilers, though partly it contradicts with AUR comments especially in regard to --with-sysroot and --with-build-sysroot
    If someone can please shed some light on this, the gcc doc is not very helpfull
    Note: I know that a bare metal arm elf cross compiler exisis in the archlinux repository but that is not sufficient as I need different targets with some special options (where can I get the PKGBUILD from packages within the ABS?)

    Current targets are armv7vfpv3 and armv5te softfloat, this compiler(s) (afaik softfloat and hardfloat can not be put into one compiler, correct me if I am wrong) will be used as basis for kernel compileing for these architectures plus the basic packages (afaik called bootstrapping).
    And I knew it was not really newby stuff, but .. well .. after searching like 5 mins for an appropriate subforum I gave up and posted it just here, sorry
    The point is this is the basis for a lot of core packages and I just want to do it right (and atm it ain't working at all )
    Last edited by drahnr (2011-04-05 22:36:11)

  • Cross compiling for ARM (Android)

    Hello, everyone. I just rooted my Android phone (an LG Ally), and decided that a fun way to try and use my newfound freedom would be to cross-compile some programs for it like Busybox, Lua, a fresh copy of Python, and possibly even pacman. (Being able to use makepkg to compile phone software would be awesome.)
    I found the cross-arm-elf-binutils and cross-arm-gcc-base packages in community, so now the question is...how do I use them? From what I understand, it essentially comes down to bulding the software like normal, but using the executables from the cross-compiling package instead of the system installed ones. Is that basically right? Can you recommend any articles on cross-compiling in general, and for Android in particular?

    You should check out the Android NDK documentation.  The NDK comes with a cross compiler specifically for android, with the correct versions of libraries, etc.  It comes with some examples showing how to build stuff for it.
    EDIT: There is also an AUR package for it.
    Last edited by tom5760 (2011-04-04 15:56:25)

  • Problems cross-compiling imagemagick with mingw32

    I am trying to cross-compile imagemagick dlls for Windows with mingw32.
    I installed the mingw32 package and ran
    ./configure --host=i486-mingw32 --with-perl=no --enable-static=no
    The output shows something like this:
    JPEG v1           --with-jpeg=yes        no (failed tests)
    JPEG-2000         --with-jp2=yes        no (failed tests)
    LCMS v1           --with-lcms=yes        no (failed tests)
    LCMS v2           --with-lcms2=yes        no
    LQR               --with-lqr=yes        no
    Magick++          --with-magick-plus-plus=yes    yes
    OpenEXR           --with-openexr=yes        no
    PERL              --with-perl=no        no
    PNG               --with-png=yes        no (failed tests)
    RSVG              --with-rsvg=yes        yes
    TIFF              --with-tiff=yes        no (failed tests)
    In config.log the test failures are shown as follows:
    configure:27841: checking for jpeg_read_header in -ljpeg
    configure:27866: i486-mingw32-gcc -std=gnu99 -std=gnu99 -o conftest.exe   -g -O2 -Wall -I/usr/include/freetype2    -D_DLL -D_MT  -I/usr/include   -L/usr/lib conftest.c -ljpeg     -lX11   -lm   >&5
    /usr/lib/gcc/i486-mingw32/4.5.0/../../../../i486-mingw32/bin/ld: cannot find -lX11
    collect2: ld returned 1 exit status
    The compiler/linker configuration looks correct to me:
    X11 Configuration:
          X_CFLAGS        = -I/usr/include
          X_PRE_LIBS      =
          X_LIBS          = -L/usr/lib
          X_EXTRA_LIBS    =
    Options used to compile and link:
      PREFIX          = /usr/local
      EXEC-PREFIX     = /usr/local
      VERSION         = 6.6.4
      CC              = i486-mingw32-gcc -std=gnu99 -std=gnu99
      CFLAGS          = -g -O2 -Wall
      CPPFLAGS        = -I/usr/local/include/ImageMagick -D_DLL -D_MT
      PCFLAGS         = -D_DLL -D_MT
      DEFS            = -DHAVE_CONFIG_H
      LDFLAGS         = -L/usr/lib
      MAGICK_LDFLAGS  = -L/usr/local/lib -L/usr/lib
      LIBS            = -lMagickCore -lfontconfig -lX11 -pthread -lrsvg-2 -lm -lgdk_pixbuf-2.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lgdi32 -lm
      CXX             = i486-mingw32-g++
      CXXFLAGS        = -g -O2
      FEATURES        =
    Why can't it find the X11 library?

    I am trying to cross-compile imagemagick dlls for Windows with mingw32.
    I installed the mingw32 package and ran
    ./configure --host=i486-mingw32 --with-perl=no --enable-static=no
    The output shows something like this:
    JPEG v1           --with-jpeg=yes        no (failed tests)
    JPEG-2000         --with-jp2=yes        no (failed tests)
    LCMS v1           --with-lcms=yes        no (failed tests)
    LCMS v2           --with-lcms2=yes        no
    LQR               --with-lqr=yes        no
    Magick++          --with-magick-plus-plus=yes    yes
    OpenEXR           --with-openexr=yes        no
    PERL              --with-perl=no        no
    PNG               --with-png=yes        no (failed tests)
    RSVG              --with-rsvg=yes        yes
    TIFF              --with-tiff=yes        no (failed tests)
    In config.log the test failures are shown as follows:
    configure:27841: checking for jpeg_read_header in -ljpeg
    configure:27866: i486-mingw32-gcc -std=gnu99 -std=gnu99 -o conftest.exe   -g -O2 -Wall -I/usr/include/freetype2    -D_DLL -D_MT  -I/usr/include   -L/usr/lib conftest.c -ljpeg     -lX11   -lm   >&5
    /usr/lib/gcc/i486-mingw32/4.5.0/../../../../i486-mingw32/bin/ld: cannot find -lX11
    collect2: ld returned 1 exit status
    The compiler/linker configuration looks correct to me:
    X11 Configuration:
          X_CFLAGS        = -I/usr/include
          X_PRE_LIBS      =
          X_LIBS          = -L/usr/lib
          X_EXTRA_LIBS    =
    Options used to compile and link:
      PREFIX          = /usr/local
      EXEC-PREFIX     = /usr/local
      VERSION         = 6.6.4
      CC              = i486-mingw32-gcc -std=gnu99 -std=gnu99
      CFLAGS          = -g -O2 -Wall
      CPPFLAGS        = -I/usr/local/include/ImageMagick -D_DLL -D_MT
      PCFLAGS         = -D_DLL -D_MT
      DEFS            = -DHAVE_CONFIG_H
      LDFLAGS         = -L/usr/lib
      MAGICK_LDFLAGS  = -L/usr/local/lib -L/usr/lib
      LIBS            = -lMagickCore -lfontconfig -lX11 -pthread -lrsvg-2 -lm -lgdk_pixbuf-2.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lgdi32 -lm
      CXX             = i486-mingw32-g++
      CXXFLAGS        = -g -O2
      FEATURES        =
    Why can't it find the X11 library?

  • Cross Compiling with distcc

    I have a 64-bit server and a 32-bit desktop.  I would like to run a distcc server on the 64-bit machine to cross-compile 32-bit software so my 32-bit machine can step up its guns.  I noticed that there are cross32-binutils and cross32-gcc packages in the AUR, so I assume that I can use them with distcc, but can I and how?  I want to avoid running a 32-bit chroot as much as possible (I think it's silly).

    Okay, I got it up and running ... I have two problems though, one I posted here (not trying to double-post).
    I am having the same issue.  I want to start distccd, but when I run schroot /etc/rc.d/distccd start, it says [DONE] as usual, but the daemon doesn't come up in ps -A.  if I manually chroot into /opt/arch32, I can issue the same command and it'll stay running.  I'm assuming that schroot sandboxes the environment, and when the command releases the terminal, it kills all the processes associated to it.
    How can I keep daemons running when they are started by schroot?
    My other issue is that dictccd only uses one core.  I have a hyperthreaded dual-core system on my server that constitutes as four cores, and when I'm in the 32-bit chroot, htop does in fact see four cores and appears to be using them.  The client machine is set to -j7 also, so it should be utilizing the 2+4(+1) cpus, but it isn't and I'm not sure why.

  • Rebuilding gcc and gcc-libs for i586

    Hi. A quick question, if you don't mind. I'm trying to rebuild (or should I say update?) just about everything on an i586, but I'm a little stuck between gcc and gcc-libs.
    This is from the PKGBUILD for gcc-libs ...
    makedepends=('binutils>=2.18-3' 'gcc>=4.2.2')
    And this is from the PKGBUILD for gcc ...
    depends=('binutils>=2.18-3' "gcc-libs>=${pkgver}")
    where $(pkgver) is the same as the gcc version, or 4.2.2. So on the surface it appears I can't compile either one since each one seems to be a dependency for the other (and makepkg spits out an error to that effect, for both, when I try).
    Is there a graceful or correct way to rebuild both packages? Is there another package I'm overlooking that will handle both of them?
    As you can imagine, I'd like to do this correctly the first time, since the trial-and-error method involves hours off my life.
    Cheers and thanks in advance.
    Last edited by k.mandla (2007-12-18 00:21:50)

    makepkg will halt without a -d flag, and the build process snags and stops with -d.
    The gcc version is 4.1.1. I started with an installation of Lowarch, hoping that I could hopscotch my way up to a current system. It's gone well so far, but this part is turning prickly.
    I compiled both packages for i586, plus glibc-2.7 and binutils-2.18, overnight on my "fast" machine (1Ghz ... ), so later today I'll see if copying them across and installing en masse helps at all. Judging from the wiki pages, it should help.
    Thanks for the tips, by the way. Compiling is not my favorite thing, but I'm learning a lot.
    Last edited by k.mandla (2007-12-19 23:31:17)

Maybe you are looking for