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.

Similar Messages

Cross compiling with crosstool-ng-hg

Is anyone successfully using crossng-hg to cross compile x86 on x86_64? I know the most popular solution is to simply use linux32 chroot /path/to/target but I'm interested in learning what other options are out there.

karol wrote:Did looking at 'Known issues.txt' or build.log gave any clues?
Nope. Shall I post my build.log?

Cross compile kernel

I have compiled a few kernels in an environment in which it's designed to run on - but cross compiling is completely new to me. However - I will persevere because I have wanted to learn this for a while now.
The target system is an arm based board for a NAS. I am using QEMU to install and configure a Debian system but it requires a working kernel in order to boot.
I have installed the arm-elf-gcc-base package (which I assume is the toolchain - am I wrong on this?) but I don't know where to go from there.
How do I invoke this particular toolchain to compile a kernel for the target arch?
Any other pointers or 'gotchas' would be greatly appreciated.
Thank you.

Which board is it?
Even if you manage to cross compile, kernel will need some extra configuration or patching to boot in qemu.
I have Raspberry Pi and qemu needs custom kernel to boot RPi images, but it's almost useless since there is
no support for network adapter. I have never cross compiled anything for it, but you might want to read on RPi
kernel cross compilation since there is a lot of documentation and you probably need just a different toolchain.
What I'm doing is distributed cross compiling via distcc. That way most of work gets done on my laptop, but it's
still quite slow because makepkg doesn't support distcc pump for distributing pre-processing.
I'm using toolchain provided by Arch Linux ARM project because I run Arch on RPi. If you can find crosstool config for
your board, making toolchain shouldn't be too difficult. This should get you started.

How to cross compile 32bit packages on Arch64 via distcc?

Is there a way to cross compile 32 bit packages on Arch64 via distcc?
Use 32bit chroot on Arch64, maybe?
If anyone has done such things, please tell me how.
Thank you very much!

Themaister wrote:http://wiki.archlinux.org/index.php/Arc … bit_system <--- good place to start
That's exactly what I followed to make a 32bit chroot on a 64bit machine. Then just use pacman inside the chroot to install the base-devel group, and you can start compiling packages from AUR, exactly the same way as you usually do. That's what I do (I have eee laptop on which it's pain to compile, so I use my 64bit machine for compiling). Then just transfer the newly created packages to the 32bit machine and install...
I don't use distcc for that, so can't help you with this, sorry.

[SOLVED] mingw32 cross compile won't link with static libraries

Hi all,
I'm trying to cross compile an app I have written to i486-mingw32. I'm running Arch 64-bit (under which it compiles fine natively), and I have installed the mingw32 binaries along with mingw32-boost-static from AUR.
All seems well, but unfortunately when I cross compile my code libtool refuses to link to the static Boost libraries:
*** Warning: Trying to link with static lib archive /usr/i486-mingw32/lib/libboost_filesystem-mt-s.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because the file extensions .a of this argument makes me believe
*** that it is just a static archive that I should not use here.
This then leads to undefined references as the library is not linked in. But as I *want* the static version of the library, does anyone know how to tell libtool to accept the .a file and link it?
Last edited by Malvineous (2011-05-02 02:44:48)

Just to follow up on this, I discovered the problem. It turns out libtool was doing the correct thing, and refusing to link the static library in with the shared one (otherwise later this could result in something being defined multiple times.) The undefined references were unrelated to the error above, and the code that was causing them (in a different Boost header file) could be easily #defined out.
When the time came to link the actual executables, libtool did include all the necessary libraries and everything worked as it should!

Problem with legacy cross compiler - Killed.

OK, so we have some legacy cross compilers, particularly pSOS and Lynx2.4 which work successfully on Solaris 10. We installed a Server with Solaris 11 and every time we try to invoke the compiler with a make command it just responds "Killed". I've been searching but making no headway on why this occurs. What am I missing? :/
Build scripts, etc.. all work well. For some reason the older gcc is not handling the transfer to Solaris 11 right now.
Thanks,
Ted

Looks like I got it working by changing from compiling options to javac.

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?

Debugging mingw cross-compiled JNI code with drmingw

Hi there... I've been googling up a storm but so far no luck so I thought I'd throw the question out and hope for some answers. I have a chunk of native code in linux and now cross-compiled to win32 using mingw. When there is an exception in the native code, the VM exits. I'm getting java dumping its stack traces (eg. hs_err_pidXXXXX.log files), but those only have hex addresses for the native DLL because the mingw symbols aren't understood.
Example:
C [lhext.dll+0x47dcc]
C [lhext.dll+0x37408]
j some.jni.method.call.i.cant.easily.cut.and.paste
I tried to load the drmingw exchndl.dll in my native code, which I thought should dump stack traces to a file when the exception occurs, but it seems like java is controlling the exception handling and bypassing the exchndl.dll library, so the net result is no useful stack trace output.
Does anyone have a good method to do this (aside from attaching gdb in windows, which is inconvenient if this happens in the field)? Or a method to extract a call stack using the hex dll addresses from a mingw cross-compiled dll?

Hi there... I've been googling up a storm but so far no luck so I thought I'd throw the question out and hope for some answers. I have a chunk of native code in linux and now cross-compiled to win32 using mingw. When there is an exception in the native code, the VM exits. I'm getting java dumping its stack traces (eg. hs_err_pidXXXXX.log files), but those only have hex addresses for the native DLL because the mingw symbols aren't understood.
Example:
C [lhext.dll+0x47dcc]
C [lhext.dll+0x37408]
j some.jni.method.call.i.cant.easily.cut.and.paste
I tried to load the drmingw exchndl.dll in my native code, which I thought should dump stack traces to a file when the exception occurs, but it seems like java is controlling the exception handling and bypassing the exchndl.dll library, so the net result is no useful stack trace output.
Does anyone have a good method to do this (aside from attaching gdb in windows, which is inconvenient if this happens in the field)? Or a method to extract a call stack using the hex dll addresses from a mingw cross-compiled dll?

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)

Announcing availability of x86 hosted cross compiler for SPARC/Solaris

We are pleased to announce the release for GCC For Sun Systems 4.2.0 cross compilers!
This is a Solaris/x86 hosted compiler with target code generation for
SPARC/Solaris systems. If you develop on your OpenSolaris, or Solaris
x86 laptop or desktop, you can now start compiling your sources for
SPARC systems. Almost all features available in the
native SPARC GCC For Sun Systems 4.2.0 compiler are available
for use in the cross compiler. Please refer to the mini cross compiler howto
page for additional details on install and usage, and gotchas in cross
development environment.
Please continue to provide us your feedback and issues, which helps
us make the product better.
Thanks
GCCFSS team

Can GCCFSS also cross compile from in reverse - from SPARC to x86/x64?
Thank you

License for cross-compilation for solaris 10 sparc on Linux x86

I'd like to do cross-compilation for solaris 10 sparc on Linux x86 using gcc (for linux). To do that, I have to copy libraries (/lib/64) and includes (/usr/include) from a sparc machine to my linux machine.
The compilation will be run on about (up to) 50 Linux machines (by various developers). We also have 3 solaris-10-SPARC machines.
I wonder if Solaris license allows me to copy the includes and libs to perform compilation elsewhere.
I also checked "OTN License Agreement for Oracle Solaris", but it looks like Oracle allows for installing "the programs" on up to 3 machines, but I need it on 50.
Thanks for any suggestions or redirections to a proper place where I can get an answer.
Marek

When installing Solaris 10 01/06 on a Dell 1850 I receive an error message during the install saying "no disk found". I assume that the drive/controller is not recognized. The Dell 1850 is listed under the HCL for Solaris 10 10/06. I don't believe I can use the Solaris(TM) Device Driver for the LSI MegaRAID Adapter floppy with 1/06. I don�t have any other Solaris boxes up so I can�t build a jump start server. Any suggestions?

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.

Cross compiling in Embedded /LabVIEW

Hi,
I am trying to create an embedded Unix UI App .I have installed cygwin with cross compiling gcc.
while trying to build an app i get the following errors:
In file included from C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/blockdiagram/MemCheck.h:24,
                 from C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/blockdiagram/LVCCG.h:37,
                 from C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/blockdiagram/LVCGenIncludes.h:15,
                 from /cygdrive/d/EddyCurrent/Microprocessor/Unix UI/Unix_UI/UI_Application/lvEmbeddedMain.c:20:
C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/blockdiagram/LVCritSect.h:22: Invalid token in expression
In file included from C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/blockdiagram/CCGDataSupport.h:40,
                 from C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/frontpanel/CCGChartGraphSupp.h:16,
                 from C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/frontpanel/CCGCtlSupport.h:22,
                 from C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/blockdiagram/LVCGenIncludes.h:17,
                 from /cygdrive/d/EddyCurrent/Microprocessor/Unix UI/Unix_UI/UI_Application/lvEmbeddedMain.c:20:
C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/blockdiagram/CCGFXPSupport.h:573: badly punctuated parameter list in `#define'
C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/blockdiagram/CCGFXPSupport.h:623: badly punctuated parameter list in `#define'
In file included from C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/comms/CCGCommsSupport.h:19,
                 from C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/blockdiagram/LVCGenIncludes.h:19,
                 from /cygdrive/d/EddyCurrent/Microprocessor/Unix UI/Unix_UI/UI_Application/lvEmbeddedMain.c:20:
C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/comms/CCGTcpUdpSupport.h:24: Invalid token in expression
C:/Program Files/National Instruments/LabVIEW 2009/CCodeGen/include/comms/CCGTcpUdpSupport.h:36: Invalid token in expression
make: *** [/cygdrive/d/EddyCurrent/Microprocessor/Unix UI/Unix_UI/UI_Application/lvEmbeddedMain.o] Error 1
How to overcome this error?All are header file errors.
This is the first time i am trying to cross compile.
without cross compiling i can build my app. But how to do with cross compiling....
I have followed the steps gn in Microprocessor SDK Porting labview to new platform.
can anyone help me pls.........
regards,
Indumathi.C
LabVIEW Developer.

Hi Anshul,
Its not possible with "Query Browser". One thing possible which is possible is,it need not be a single row, you can divide the labels in any number of rows and any number of columns. See the below example. The yellow highlighted ones are the labels of chart, the greyish ones are the corresponding values for the labels. The sequence will be the same.
If you dont need this way, then there are two best ways to achieve cross tab functionality.
One thing you can do is, you can directly connect the Bex queries to the Dashboard using BICS Net weaver connection.
But this way you can only Publish-Launch in BW. The dashboard cannot be made available in Infoview/Launch Pad.
Other way is through Webi and BIWS connection. As Suman has mentioned.
This way it ll be available in Infoview/Launch Pad and BW as well.
Thanks,
Sara

Problem in GCCFSS cross compiler

I have followed the instructions of using gccfss as a cross compiler. But when I compile my HelloWorld.c I encountered the following error:
ld fatal: file /usr/lib/libc.so: wrong ELF machine type: EM_386
Can anyone help me?

All
I have gccfss installed along with target (sparc) machine's /usr/include and /usr/lib directory contents.
I'm trying a simple "Hello" {color:#0000ff}cross-compile{color} exercise below and getting linking {color:#ff0000}error(s){color:#000000}.
Any ideas/suggestions?
Thank you in advance, Attila.
NB: I tried setting/defining LD_LIBRARY_PATH environment variable to point to copy of target system's library directories but get "wrong ELF machine type" errors because gccfss is referencing /usr/lib directory instead.
{color}{color}{color:#ff0000}{color:#0000ff}
$ /opt/gccfss/gcc/bin/gcc -L/opt/sparc/usr/lib -L/opt/sparc/usr/lib/mdb/proc -L/opt/sparc/usr/lib/mdb/proc/sparcv9 hello.c{color}
Undefined first referenced
symbol in file
exit /opt/gccfss/gcc/bin/../lib/gcc/sparc-sun-solaris2.10/4.2.0/crt1.o
puts /tmp/ccobWhgs.o
_exit /opt/gccfss/gcc/bin/../lib/gcc/sparc-sun-solaris2.10/4.2.0/crt1.o
bzero /opt/sparc/usr/lib/mdb/proc/libc.so
mdb_snprintf /opt/sparc/usr/lib/mdb/proc/libc.so
mdb_printf /opt/sparc/usr/lib/mdb/proc/libc.so
atexit /opt/gccfss/gcc/bin/../lib/gcc/sparc-sun-solaris2.10/4.2.0/crt1.o
mdb_lookup_by_obj /opt/sparc/usr/lib/mdb/proc/libc.so
strcat /opt/sparc/usr/lib/mdb/proc/libc.so
strcpy /opt/sparc/usr/lib/mdb/proc/libc.so
mdb_alloc /opt/sparc/usr/lib/mdb/proc/libc.so
mdb_vread /opt/sparc/usr/lib/mdb/proc/libc.so
sig2str /opt/sparc/usr/lib/mdb/proc/libc.so
mdb_free /opt/sparc/usr/lib/mdb/proc/libc.so
mdb_warn /opt/sparc/usr/lib/mdb/proc/libc.so
strerror /opt/sparc/usr/lib/mdb/proc/libc.so
mdb_get_xdata /opt/sparc/usr/lib/mdb/proc/libc.so
_environ /opt/gccfss/gcc/bin/../lib/gcc/sparc-sun-solaris2.10/4.2.0/crt1.o
ld: fatal: Symbol referencing errors. No output written to a.out
collect2: ld returned 1 exit status{color}

[SOLVED] cross compiling libopenfst makepkg error

Hello there,
I am trying to cross compile openfst on my 64 bit arch setup since it is taking too long on my raspberry pi (which also happily runs arch). I thought I would be ok with the following makepkg to get me a binary package which I could transfer to my pi and then install with pacman-U:
# Maintainer: Christoph Drexler <chrdr at gmx dot at>
pkgname=openfst
pkgver=1.4.1
pkgrel=1
pkgdesc="Library for constructing, combining, optimizing, and searching weighted finite-state transducers (FSTs)"
arch=('i686' 'x86_64' 'armv6h')
url="http://www.openfst.org/"
license=('APACHE')
depends=('gcc-libs' 'glibc')
options=(!libtool)
source=("http://openfst.cs.nyu.edu/twiki/pub/FST/FstDownload/${pkgname}-${pkgver}.tar.gz")
md5sums=('ca8f1730b9b9b281e515611fa9ae23c0')
build() {
cd ${srcdir}/${pkgname}-${pkgver}
#export CXX=arm-linux-gnueabi-g++
#export CC=arm-linux-gnueabi-gcc
# Options according to http://openfst.cs.nyu.edu/twiki/bin/view/FST/ReadMe
OPTIONS="--prefix=/usr --disable-dependency-tracking"
OPTIONS+=" --enable-bin" # Enable fst::script and command-line binaries; Default: yes
OPTIONS+=" --enable-compact-fsts" # Enable all CompactFst classes; Default: no
OPTIONS+=" --enable-const-fsts" # Enable all ConstFst classes; Default: no
OPTIONS+=" --enable-far" # Enable FAR (FST Archive) extension; Default: no
OPTIONS+=" --enable-linear-fsts" # Enable Linear{Tagger,Classifier}Fst extensions; Default: no
OPTIONS+=" --enable-lookahead-fsts" # Enable LookAheadFst classes; Default: no
OPTIONS+=" --enable-pdt" # Experimental push-down transducer extensions; Default: no
OPTIONS+=" --host=arm-linux-gnueabi" # Experimental push-down transducer extensions; Default: no
OPTIONS+=" --build=x86_64" # Experimental push-down transducer extensions; Default: no
LIBS="-ldl" ./configure $OPTIONS
make
package() {
cd ${srcdir}/${pkgname}-${pkgver}
make DESTDIR=${pkgdir} install
(basically adding the host and build option)
However, I get an error in the output:
==> Making package: openfst 1.4.1-1 (Sun Jan 11 16:13:22 CET 2015)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found openfst-1.4.1.tar.gz
==> Validating source files with md5sums...
openfst-1.4.1.tar.gz ... Passed
==> Extracting sources...
-> Extracting openfst-1.4.1.tar.gz with bsdtar
==> Removing existing $pkgdir/ directory...
==> Starting build()...
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-linux-gnueabi-strip... arm-linux-gnueabi-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for arm-linux-gnueabi-g++... arm-linux-gnueabi-g++
checking whether the C++ compiler works... no
configure: error: in `/home/tom/openfst-1.4.1/src/openfst-1.4.1':
configure: error: C++ compiler cannot create executables
See `config.log' for more details
==> ERROR: A failure occurred in build().
Aborting...
the error being that the C++ compiler cannot create excecutables makes sense since they are not meant to be excecuted on x86_64 but for armv6h (cross compilation). I have checked with arm-linux-gnueabi-g++ and its excecutables I can run on my pi so this should be ok. I am guessing that I am either missing an option to disable the compiler check, or I should change the configure script and remove this check, but I cannot figure out how to do either...
//edit: I'm not sure this topic is in the right place btw, maybe it should be in scripting...
Last edited by tomzooi (2015-01-11 18:23:35)

that seems to do the trick, I'm not gonna test it since my pi just finished compiling it locally (which took 12+hours or so), but the compile seems to work since they are not excecutable on 64 bit, so pkgbuild for raspi cross compilation using makepkg -s:
# Maintainer: Christoph Drexler <chrdr at gmx dot at>
pkgname=openfst
pkgver=1.4.1
pkgrel=1
pkgdesc="Library for constructing, combining, optimizing, and searching weighted finite-state transducers (FSTs)"
arch=('i686' 'x86_64' 'armv6h')
url="http://www.openfst.org/"
license=('APACHE')
depends=('gcc-libs' 'glibc')
options=(!libtool !buildflags)
source=("http://openfst.cs.nyu.edu/twiki/pub/FST/FstDownload/${pkgname}-${pkgver}.tar.gz")
md5sums=('ca8f1730b9b9b281e515611fa9ae23c0')
build() {
cd ${srcdir}/${pkgname}-${pkgver}
# Options according to http://openfst.cs.nyu.edu/twiki/bin/view/FST/ReadMe
OPTIONS="--prefix=/usr --disable-dependency-tracking"
OPTIONS+=" --enable-bin" # Enable fst::script and command-line binaries; Default: yes
OPTIONS+=" --enable-compact-fsts" # Enable all CompactFst classes; Default: no
OPTIONS+=" --enable-const-fsts" # Enable all ConstFst classes; Default: no
OPTIONS+=" --enable-far" # Enable FAR (FST Archive) extension; Default: no
OPTIONS+=" --enable-linear-fsts" # Enable Linear{Tagger,Classifier}Fst extensions; Default: no
OPTIONS+=" --enable-lookahead-fsts" # Enable LookAheadFst classes; Default: no
OPTIONS+=" --enable-pdt" # Experimental push-down transducer extensions; Default: no
OPTIONS+=" --host=arm-linux-gnueabi" # Experimental push-down transducer extensions; Default: no
OPTIONS+=" --build=x86_64" # Experimental push-down transducer extensions; Default: no
LIBS="-ldl" ./configure $OPTIONS
make
package() {
cd ${srcdir}/${pkgname}-${pkgver}
make DESTDIR=${pkgdir} install
to get some stuff which I think I can ignore:
strip: Unable to recognise the format of the input file `./usr/bin/fstprint'
strip: Unable to recognise the format of the input file `./usr/bin/farprintstrings'
strip: Unable to recognise the format of the input file `./usr/bin/fstmap'
strip: Unable to recognise the format of the input file `./usr/bin/fstsynchronize'
strip: Unable to recognise the format of the input file `./usr/bin/fstdraw'
strip: Unable to recognise the format of the input file `./usr/bin/fstepsnormalize'
strip: Unable to recognise the format of the input file `./usr/bin/fstdisambiguate'
strip: Unable to recognise the format of the input file `./usr/bin/fstunion'
strip: Unable to recognise the format of the input file `./usr/bin/pdtexpand'
strip: Unable to recognise the format of the input file `./usr/bin/fstminimize'
strip: Unable to recognise the format of the input file `./usr/bin/fsttopsort'
strip: Unable to recognise the format of the input file `./usr/bin/pdtreplace'
strip: Unable to recognise the format of the input file `./usr/bin/fstreverse'
strip: Unable to recognise the format of the input file `./usr/bin/fstsymbols'
strip: Unable to recognise the format of the input file `./usr/bin/farequal'
strip: Unable to recognise the format of the input file `./usr/bin/fstequal'
strip: Unable to recognise the format of the input file `./usr/bin/fstcompile'
strip: Unable to recognise the format of the input file `./usr/bin/fstshortestpath'
strip: Unable to recognise the format of the input file `./usr/bin/farinfo'
strip: Unable to recognise the format of the input file `./usr/bin/fstrandgen'
strip: Unable to recognise the format of the input file `./usr/bin/fstshortestdistance'
strip: Unable to recognise the format of the input file `./usr/bin/fstarcsort'
strip: Unable to recognise the format of the input file `./usr/bin/fstrmepsilon'
strip: Unable to recognise the format of the input file `./usr/bin/fstconvert'
strip: Unable to recognise the format of the input file `./usr/bin/fstreplace'
strip: Unable to recognise the format of the input file `./usr/bin/farcompilestrings'
strip: Unable to recognise the format of the input file `./usr/bin/fstencode'
strip: Unable to recognise the format of the input file `./usr/bin/fstpush'
strip: Unable to recognise the format of the input file `./usr/bin/pdtshortestpath'
strip: Unable to recognise the format of the input file `./usr/bin/fstinfo'
strip: Unable to recognise the format of the input file `./usr/bin/fstrelabel'
strip: Unable to recognise the format of the input file `./usr/bin/fstinvert'
strip: Unable to recognise the format of the input file `./usr/bin/fstconcat'
strip: Unable to recognise the format of the input file `./usr/bin/fstintersect'
strip: Unable to recognise the format of the input file `./usr/bin/pdtreverse'
strip: Unable to recognise the format of the input file `./usr/bin/fstclosure'
strip: Unable to recognise the format of the input file `./usr/bin/fstdeterminize'
strip: Unable to recognise the format of the input file `./usr/bin/fstcompose'
strip: Unable to recognise the format of the input file `./usr/bin/fstlinear'
strip: Unable to recognise the format of the input file `./usr/bin/pdtcompose'
strip: Unable to recognise the format of the input file `./usr/bin/farcreate'
strip: Unable to recognise the format of the input file `./usr/bin/fstdifference'
strip: Unable to recognise the format of the input file `./usr/bin/fstloglinearapply'
strip: Unable to recognise the format of the input file `./usr/bin/fstprune'
strip: Unable to recognise the format of the input file `./usr/bin/pdtinfo'
strip: Unable to recognise the format of the input file `./usr/bin/fstproject'
strip: Unable to recognise the format of the input file `./usr/bin/farextract'
strip: Unable to recognise the format of the input file `./usr/bin/fstequivalent'
strip: Unable to recognise the format of the input file `./usr/bin/fstconnect'
strip: Unable to recognise the format of the input file `./usr/bin/fstreweight'
strip: Unable to recognise the format of the input file `./usr/lib/libfst.so.3.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact8_acceptor-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact8_string-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/libfstfar.so.1.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/const16-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact8_weighted_string-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/arc_lookahead-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/const64-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/libfstlinearscript.so.1.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact16_string-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact16_unweighted-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/libfstlookahead.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/linear_classifier-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/linear_tagger-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact16_acceptor-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/libfstcompact.so.1.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/olabel_lookahead-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/const8-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact16_weighted_string-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact16_unweighted_acceptor-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact64_string-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/libfstconst.so.1.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/ilabel_lookahead-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact64_unweighted-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact64_weighted_string-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/libfstfarscript.so.1.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact8_unweighted_acceptor-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/libfstpdtscript.so.1.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact8_unweighted-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact64_unweighted_acceptor-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/fst/compact64_acceptor-fst.so.0.0.0'
strip: Unable to recognise the format of the input file `./usr/lib/libfstscript.so.1.0.0'
I will check soon I hope , for now will mark it as solved.

Cross Compiling with distcc

Similar Messages

Maybe you are looking for