How to cross compile CDC CVM on Redhat6.2 for stong ARM??

Dear all:
Can you tell me how to cross compile CDC CVM on Redhat6.2 for stong ARM??I failed to find any
infomation on this problem.If you know ,please tell me.
Thanks

Hi:
Thank you for your advice. I'll give your advice to my boss.But is it possible to cross-compile CVM? If the answer is positive,how?
Thank you
Best RGDS

Similar Messages

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.

How to extract compiled stored procedure without line break for long statement

After I compiled stored procedure which contains long statement, the statement would cut into 2 rows into dba_source.
However, when I extract the codes from dba_source table, the source couldn't be compiled successfully because of
the broken lines.
For example, the following statement would be broken into 2 rows like this:
(line 1) gv_Message := 'Interface Description: Interface with Training '|| 'and Development Intran
(line 2) et (Evaluation Statistic Details)';

That's very strange. What did you originally compile it with (sql*plus, toad, etc...)? I was able to compile a procedure with the maximum line length (2499 characters see error SP2-0027) and there is no split. Is the procedure in a VALID state with that line break? Honestly, this seems very odd, possibly even a bug here somewhere.
Richard

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.

How to compile and install kaffe-1.0.6 on arm-linux??

hi,all:
Does anyone know the answer to my question?If you
do,could you tell me the answer? Places where to find
the answer is also wanted.
Thank you ,all guys.
hugh

If you are cross-compiling kaffe then you can use this:
CC=arm-linux-gnu-gcc \
AR=arm-linux-gnu-ar \
LD=arm-linux-gnu-ld \
NM=arm-linux-gnu-nm \
RANLIB=arm-linux-gnu-ranlib \
KAFFEH=/home/fire/kaffeh \
CFLAGS=-Os LDFLAGS=-s \
./configure \
--host=arm-linux-gnu \
--enable-shared \
--disable-debug \
--disable-xprofiling \
--disable-xdebugging \
--disable-feedback \
--without-profiling \
--without-libffi \
--without-x \
--without-stats \
--disable-gcj \
--prefix=/usr
make
make DESTDIR=~/distro install
Btw this will not compile kaffe with AWT support.

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

How can i compile a C program to run solaris 9 and 10?

Hi,
I need to compile a small C program to run on solaris 9 and 10. There is no C compiler on the target servers. I have compiled and tested the program on Linux over x86.
I hope you can advise on the way forward. I see the following options:
- install a C compiler, the lightest possible, on the target servers and compile the program
or
- set-up a sparc solaris (9 or 10) on top of virtualbox on my windows laptop, install the c compiler and then compile the program
Thanks in advance.
Gaby

To run an application on both Solaris 9 and 10, you need to build it on Solaris 9. The application will then run on Solaris 9 and 10. (If you build on Solaris 10, you cannot expect the application to work on 9.)
The most recent Studio version that can be run on Solaris 9 is Studio 12 (but not updates 1, 2, or 3).
You can still get Studio 12 here, but since it dates from 2007, I don't know for how much longer.
http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/ss12-136026.html
Studio does not do cross-compilation, so you need to build on a system of the same type as the target system -- SPARC or x86. I don't know whether Solaris 9 can be installed on Virtual Box, but you can try. If it works, you can install the compiler, build on that system, then deploy on other Solaris 9 and 10 x86 systems.
You can of course build the application on each of Solaris 9 and 10, but usually that is not necessary, and it complicates deployment and support.
I believe Solaris 9 is End Of Life, so it would be a good idea to upgrade S9 systems to S10 or S11. I realize that such a change might not be up to you. :-)

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

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

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

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 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 : CARCH flag

Hi all ! I just have a question about cross compiling. No real problem in fact
So, on the "Safe Cflags" wiki page (and on other Web pages, too), one can see lots of optimizations for various processors. But for each one, only CHOST and CFLAGS change. I don't understand what CARCH is used for, then...
"Specifies your computer architecture; possible values include "i686" or "x86_64". This should be automatically set on installation."
I think that if it never changes, this CARCH value only concern the computer which is compiling.
So, if I compile something, say, for an Athlon 64 from an Intel chip, my flags would be :
CARCH="i686"
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -O2 -pipe"
CXXFLAGS="${CFLAGS}"
And if I compile frequently for other architectures, I would have a couple of CHOST/CFLAGS for each foreign architecture, and only one CARCH, corresponding to my computer.
Am I right ?

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)

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)

Cross-compile generated C code

Hello,
I'm trying to cross-compile the C code generated from the uC SDK, but I'm getting undefined reference errors from the compiler.
I'm using an ARM7 based embedded board with uCLinux and buildroot as cross compiler. I was able to cross compile the labview runtime library by adapting the makefile from the m5329evb example so far. But now when I try to cross compile the c code of my VI the compiler gives undefined reference errors.
My question is, how do I make the the compiler use the built library and which parameters do I have to use?
Here is command I used to compile my VI:
~/buildroot/buildroot-atmel/toolchain_build_arm_small/gcc-4.1.2-final/gcc/gcc-cross vi1.c -I/home/michael/buildroot/CCodeGen/include/blockdiagram/ -I/home/michael/buildroot/CCodeGen/include/frontpanel/ -I/home/michael/buildroot/CCodeGen/include/comms/ -I/home/michael/buildroot/CCodeGen/include/os/unix -I/home/michael/test/CcodeGen/ -L/home/michael/buildroot/CCodeGen/libsrc/main/ -L/home/michael/buildroot/CCodeGen/libsrc/blockdiagram/ -L/home/michael/buildroot/CCodeGen/libsrc/os/unix /home/michael/test2/libs/rt.a -DCHeadless -DUnix -w -o vi1
Michael

Hi Michael,
lvEmbeddedMain.c is not a generated file. It is located in labview\CCodeGen\libsrc\main\lvEmbeddedMain.c. It is copied to the build folder in the labview\Targets\NI\Embedded\unix\unix_LEP_TargetPlugin\LEP_unix_CopySupportFiles.vi plug-in VI.
What symbols are undefined?
Michael P
National Instruments

How to cross compile CDC CVM on Redhat6.2 for stong ARM??

Similar Messages

Maybe you are looking for