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

Similar Messages

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?

Seperate include directory for i486-mingw32 cross-compiler toolchain

I've installed the mingw32 cross-compiler. I noticed that when using this compiler, a seperate, non-standard include directory is used. So instead of copying all of the dependencies headers to compile the software, is there an easier way of including both directories?
Thanks.

I've installed the mingw32 cross-compiler. I noticed that when using this compiler, a seperate, non-standard include directory is used. So instead of copying all of the dependencies headers to compile the software, is there an easier way of including both directories?
Thanks.

[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!

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

Compiler configure problems (cross compiling?)

When attempting to compile packages, I am receiving these errors:
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in `/tmp/yaourt-tmp-procyon/abs-htop/src/htop-1.0.3':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build htop.
I have not changed any cflags or other build variables. Why these errors?

I should add, this occurred after I restored my system from a backup.

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.

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)

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.

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)

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.

Cross-compiling desirable

Similar Messages

Maybe you are looking for