[SOLVED] Confusion about cross-compiling kernel

I have a MacBook Pro running Mac OS X, and my Arch laptop.
They have different processors (but both Core 2 Duo).
How do I go about compiling the kernel on my Mac, for my Arch machine?
(I'm just going to try compiling the stock Arch kernel at first, then perhaps add the flag in .config for Core2Duo optimisations. Latest kernel.)
Last edited by chrispoole (2009-05-29 12:53:14)

If you're running an Intel Mac, maybe x-compiling won't be necessary.
I think you need to download a toolchain for your target architecture, set it up and compile the kernel *w/ that toolchain*, not w/ your regular one.
I'd suggest grabbing CRUX http://crux.nu/. Compiling the kernel is part of the standard installation process. CRUX is somewhat similar to Arch, w/ the notable omission of pacman.
If playing w/ kernel is all you want, set up some sandbox space and give it a go. No need for x-compiling etc.
Last edited by karol (2009-05-29 12:16:39)

Similar Messages

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.

[SOLVED] Confused about Mobility Radeon HD 3200

I've always found hard to find good information about this card - some sources, even, contradict themselves. All what I know is that it is an integrated graphics card and that it features the RS780M chipset. These are some tips I've got from the system logs:
grep -i r600 /var/log/Xorg.0.log
[ 23.353] (II) RADEON(0): [DRI2] DRI driver: r600
[ 23.353] (II) RADEON(0): [DRI2] VDPAU driver: r600
[ 24.099] (II) AIGLX: Loaded and initialized r600
dmesg | grep -i radeon
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux-hf root=UUID=ab92c2db-22b5-4fcb-a33f-2efe3f3f104c ro radeon.modeset=1 radeon.benchmark=0 radeon.tv=0 radeon.pm=0 init=/usr/lib/systemd/systemd quiet
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-linux-hf root=UUID=ab92c2db-22b5-4fcb-a33f-2efe3f3f104c ro radeon.modeset=1 radeon.benchmark=0 radeon.tv=0 radeon.pm=0 init=/usr/lib/systemd/systemd quiet
[ 1.463857] [drm] radeon kernel modesetting enabled.
[ 1.464337] radeon 0000:01:05.0: VRAM: 256M 0x00000000C0000000 - 0x00000000CFFFFFFF (256M used)
[ 1.464340] radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
[ 1.464779] [drm] radeon: 256M of VRAM memory ready
[ 1.464781] [drm] radeon: 512M of GTT memory ready.
[ 1.472494] radeon 0000:01:05.0: WB enabled
[ 1.472499] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000c00 and cpu addr 0xffff8800374a5c00
[ 1.472502] radeon 0000:01:05.0: fence driver on ring 3 use gpu addr 0x00000000a0000c0c and cpu addr 0xffff8800374a5c0c
[ 1.472570] [drm] radeon: irq initialized.
[ 1.472672] radeon 0000:01:05.0: setting latency timer to 64
[ 1.504277] [drm] radeon atom DIG backlight initialized
[ 1.504279] [drm] Radeon Display Connectors
[ 1.504311] [drm] radeon: power management initialized
[ 2.344989] fbcon: radeondrmfb (fb0) is primary device
[ 2.441483] radeon 0000:01:05.0: fb0: radeondrmfb frame buffer device
[ 2.441486] radeon 0000:01:05.0: registered panic notifier
[ 2.441502] [drm] Initialized radeon 2.30.0 20080528 for 0000:01:05.0 on minor 0
I also found good (?) information, or at least a clearly-explained article, here. After reading it, UVD appears as the AMD's counterpart of NVIDIA's VDPAU for video acceleration.
What I'm not sure about, is:
- Does it support video acceleration? I'd like to offload video processing to the GPU, but am not sure if my card and the open-source drivers support it or not. Wikipedia's article about VDPAU states it comes from NVIDIA, but then it says it has an open-source implementation.
- What has gallium to do with it? What gallium drivers should I enable in mesa? And what about DRI drivers?
I configured mesa as follows:
./configure --prefix=/usr \
--sysconfdir=/etc \
--with-dri-driverdir=/usr/lib/xorg/modules/dri \
--with-gallium-drivers=r600 \
--with-dri-drivers=radeon \
--with-llvm-shared-libs \
--enable-gallium-llvm \
--enable-egl \
--enable-gallium-egl \
--with-egl-platforms=x11,drm \
--enable-shared-glapi \
--enable-gbm \
--enable-glx-tls \
--enable-dri \
--enable-glx \
--enable-osmesa \
--enable-texture-float \
--enable-xa \
--enable-vdpau
Not sure if I missed something, though.
I am very confused about how Linux manages graphics, and what all those layers are for. DRM, DRI, VDPAU, VA-API, gl, gl3, xv, xvmc... it's a mess!
Thanks in advance.
Last edited by Kalrish (2013-06-16 17:54:04)

The feature matrix might help. The easy part to answer is that the 3D driver is split into two parts: DRM which is part of the kernel and DRI which is in userspace and comes from the mesa package.
Xv is an Xserver extension supported by pretty much all drivers. Found in the DDX (xf86-video-*), it uses features of the card to speed up the display of video (but not decoding). It can either do this by using the "video overlay" or creating a shader.
Now if you want to use Xv but also offload decoding to the card, you need a video acceleration API. The ones to choose from are XvMC, VA-API, VDAPU in increasing order of feature support. They were developed by Xorg, Intel, Nvidia respectively but anyone is free to implement them. I don't think it's correct to call UVD a counterpart of VDPAU. UVD is a bunch of registers on newer AMD cards. And if you sent bits to those registers in the right way, you can implement VDPAU.
The other way to implement VDPAU (say if the documentation for UVD registers was not released) is to use gallium. There is a gallium state tracker which can still do it at the expense of being slower. It is a hack whereby you convert video frames to polygon textures and make the OpenGL part of the card think that it's calculating part of a 3D scene when really it's decoding video.

[SOLVED] Confused about development packages

To build an embedded linux image using minifs utility, I need to install some development packages. The packages listed in the tutorial are named for Debian based distros, with the "-dev" suffix. Some of the listed packages are: libz-dev, libelf-dev, libelfg0-dev, libncurses-dev, etc.
I can't find these packages, and I'm a bit confused. I have read that these packages in Arch Linux have different suffixes denpending on the origin (-cvs, -git, etc.), but I can't find any packages with that suffixes. For example for ncurses:
$ pacman -Ss ncurses
core/ncurses 5.9-3 [instalado]
System V Release 4.0 curses emulation library
extra/cmus 2.4.3-1
A very feature-rich ncurses-based music player
extra/finch 2.10.1-1
A ncurses-based messaging client
extra/moc 20110528-5
An ncurses console audio player with support for the mp3, ogg, and wave
formats
extra/naim 0.11.8.3.2-2
An ncurses AOL Instant Messenger and IRC client.
extra/ncmpc 0.20-1
A ncurses (command line) interface for MPD
community/echat 0.04beta1-3
vypress compatible ncurses chat (can work without server)
community/ekg2 0.3.1-2
ncurses based Jabber, Gadu-Gadu, Tlen and IRC client
community/ncdu 1.8-1
Disk usage analyzer with an ncurses interface
community/rtorrent 0.8.9-2
Ncurses BitTorrent client based on libTorrent
community/ruby-ncurses 1.3.1-3
Module for interactive text console applications (ncurses)
community/sniffit 0.3.7.beta-11
very good packet sniffer for unix with ncurses interactive mode.
community/vifm 0.7.2-1
Ncurses based file manager with vi like keybindings
community/yacpi 3.0.1-3
ncurses-based acpi monitor.
No ncurses-cvs, ncurses-git, ncurses-svn or the like is found. How can I find development packages?
Last edited by doragasu (2012-03-09 22:38:03)

doragasu wrote:So in Arch, packages include not only binaries + resources, they also include header files? If I install for example ncurses, also header files for ncurses get installed?
headers, pkg-config, everything in one package, that is required for a compilation. we keep stuff simple
Last edited by wonder (2012-03-09 22:37:46)

[solved]confused about bootloader to use

I have a uuefi motherboard but in my BIOS drives some say ahci, not sure which bootloader I should use.
Last edited by tmccaffery (2013-04-04 20:21:29)

If you are comfortable with the old bios way of doing things, then I see no reason why you should force yourself into learning about UEFI if you don't have the desire to do so. Most UEFI boards have a legacy bios mode, so you can continue to use that if you please.
BTW, I use gummiboot, with rEFInd as a backup, and elilo as a backup to the backups (and just in case I have an old kernel w/o efistub). I also have direct firmware boot manager entries for each of my kernels, as well as both version of the UEFI shell as a super duper extra backup. That is one of the advantages of UEFI, you are not forced to use just a single bootloader, as they are stored in the EFI System Partition, which can be as big as you want it, instead of just the first 446 bytes of the disk like bios. This makes the necessity of crazy chainloading unnecessary, which is a real treat.

[solved] confusion about vim and its config files

Hi, Im getting really confused with vim and its /etc/vimrc config, and the per user ~/.vimrc.
On one of my PC's I have an untouched /etc/vimrc and a /home/jason/.vimrc which has:
syntax on
now, on that same PC, if I run
vim .vimrc
"syntax on" in green and yellow as expected, and if I run
sudo vim .vimrc
I also see
"syntax on" in green and yellow, but surely this is opening it as root?
*Edit
Even though there is no .vimrc in /root, and the system-wide /etc/vimrc is untouched/blank
On another PC I also have an untoched /etc/vimrc, and a /home/jason/.vimrc which has:
syntax on
Aswell, and:
vim .vimrc
has "syntax on" in green and yellow as expected, but this time:
sudo vim .vimrc
Has no colour?
I cant explain this, any ideas?
*Edit
To clarify, both PC's have an untouched /etc/vimrc and there is no /root/.vimrc file on either PC
Last edited by jrussell (2013-04-14 10:21:42)

siriusb wrote:
The configuration files in /etc are for system-wide settings. These are the default settings if not overridden by a user's own settings in their home directory.
So running vim as your regular user will use the settings from your home directory.
What does sudo? From man sudo
sudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy.
So if you didn't specify any setting in the home folder of the user you want to run vim as, and you don't have anything in /etc/vimrc, vim won't apply any custom settings.
I understand all of that, but on both my PC's I have a clean/untouched config /etc/vimrc, and both /root/.vimrc files do not exist, so howcome on one PC I get colour with sudo vim...., and on the other I dont?

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)

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

[Solved]Error compiling kernel from abs

Hello Everyone,
I've hit a wall trying to compile the kernel from the abs. I get this error message:
patching file fs/fat/inode.c
Hunk #1 succeeded at 800 (offset 74 lines).
HOSTCC scripts/basic/fixdep
/bin/sh: scripts/basic/fixdep: cannot execute binary file
make[2]: *** [scripts/basic/fixdep] Error 126
make[1]: *** [scripts_basic] Error 2
SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_32.h
SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_64.h
make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop.
make: *** Waiting for unfinished jobs....
HOSTCC scripts/basic/fixdep
SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_x32.h
SYSTBL arch/x86/syscalls/../include/generated/asm/syscalls_32.h
/bin/sh: scripts/basic/fixdep: cannot execute binary file
make[1]: *** [scripts/basic/fixdep] Error 126
make: *** [scripts_basic] Error 2
==> ERROR: A failure occurred in build().
Aborting...
While trying to figure this out I came across this post: https://bbs.archlinux.org/viewtopic.php?id=99089 and have tried the solutions presented. I did end up having to change my fstab to include defaults,
/dev/sda3 /home ext4 defaults,exec,rw,relatime,data=ordered 0 2
and the permissions on scripts/basic/fixdep are: -rwxr-xr-x which i think it correct.
Unfortunately, the problem still exists and I don't know how to continue trouble shooting. Can someone point me in a direction to troubleshoot this?
Last edited by magyarm (2012-12-20 01:55:00)

magyarm wrote:So now, I need to figure out a good way to handle multiple compilers on my system to prevent this from happening again. If anyone has any tips I would love to hear them.
Set up a file that you source from bash to prepend the cross compiler to your path, that would only be active for that shell, and when you're done just close it. Means you only activate the cross compiler when you need it.

[SOLVED] error compiling kernel 2.6.29

Hi,
Due to having the DVD-S card mentioned here
http://www.linuxtv.org/pipermail/linux- … 23265.html
I am trying to compile kernel 2.6.29.6 with the above mentioned patch but get an error:
include/sound/soc-dai.h: At top level:
include/sound/soc-dai.h:224:25: error: duplicate member ‘codec’
sound/soc/soc-core.c: In function ‘snd_soc_init_card’:
sound/soc/soc-core.c:1360:18: warning: variable ‘ac97’ set but not used
[-Wunused-but-set-variable]
make[2]: *** [sound/soc/soc-core.o] Error 1
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2
bash: vim include/sound/soc-dai.h
/* DAI runtime info */
struct snd_pcm_runtime *runtime;
struct snd_soc_codec *codec;
unsigned int active;
unsigned char pop_wait:1;
void *dma_data;
/* DAI private data */
void *private_data;
/* parent codec/platform */
union {
struct snd_soc_codec *codec;
struct snd_soc_platform *platform;
Note:
I found a solution:
http://mailman.alsa-project.org/piperma … 16949.html
Last edited by casacristo (2011-10-19 07:46:01)

I've solved the issue, infact there was a problem with the patch. Now I am able to compile the kernel.
Thanks anyway!

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

[SOLVED]Compiling kernel fails with segfault

Hi guys,
I'm out of answers.
The situation :
Compiling kernel randomly stops with : "segmentation fault" and never runs through.
Reissuing make will make it continue until it will fail at some other point.
Background:
The system feels completely unstable to say the least, but nothing 100 % reproduceable ( vuze(java) crash, firefox/chromuim flash sites crash every 120 seconds, X crashes once a day , for instance when moving tvtime around, kernel oops daily, sometimes hard lockups, logs of yesterdays oops : http://pastie.org/private/imrqdzdbejdb3jxn4czuw )
But only the kernel compile is 100 % reproduceable so this must be fixed asap.
Specs:
intel e8400,nvidia gtx260, 2 G ddr2,Gigabyte EP45-UD3R, "gigs of space", off. arch kernel 2.6.33-ARCH , x86_64, "bigtime" cooling :
cpu temps 50 C° max during compiling
What configs/packages are important ? I got paranoid and ditched my old makgepkg.conf and used a newer *.pacnew file , I used to have :MAKEFLAGS="-j3" but not in this config :
http://pastie.org/private/4ryshivi2hgyqenjlkicg
local packages:
local/gcc 4.5.0-1 (base-devel)
The GNU Compiler Collection
local/gcc-libs 4.5.0-1 (base)
Runtime libraries shipped by GCC for C and C++ languages
Anything else updated daily.
The blowup:
http://pastie.org/private/hoamev0sli7zapbr0xvpbq
What I tried:
fsck -f: it fixed two inodes, but still the same behavior
badblocks -nvs : three hours of badblock testing, 0 hits
memtest : two passed runs, no errors
stress from AUR, 15 minutes :
stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 15m
stress: info: [26841] dispatching hogs: 8 cpu, 4 io, 2 vm, 0 hdd
stress: info: [26841] successful run completed in 900s
Max coretemp was 52 C° during stress.
The usual footnote statement ^_^ :
On w7 _everything_ runs stable.
And not only stable , I'm able to OC this box to 4.5 GHz and game under w7 without a prop for hours, well this is what it was build for at some point.
Conclusion:
So I'd say hardware wise this box kicks ass and now software wise my Arch kicks me in the a**.
I doubt there is a faulty hardware part, but what else could it be ?
Last edited by tuxfusion (2010-05-17 22:48:06)

Update:
Trying to compile another big package just to have another result, gcc itself now :
- segfault after 4 m18 s
- segfault after 5 m50 s
Update²:
I think I found a faulty BIOS setting in my non-OC profile concerning DRAM termination, which said "normal" where "auto" would be correct.
My OC-profile has this setting correct and since I run this profile in Arch only it might explain that w7 did not fail.
Still have to verify this but i makes perfect sense, only gcc seems to trigger this. Compiling gcc still running with over 10 minutes in the game now.
After hitting 4.5 GHz with OC I must have reset the non OC-profile wrong.
*slams head on desk*
Last edited by tuxfusion (2010-05-17 13:10:04)

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)

Confused about extending the Sprite class

Howdy --
I'm learning object oriented programming with ActionScript and am confused about the Sprite class and OO in general.
My understanding is that the Sprite class allows you to group a set of objects together so that you can manipulate all of the objects simultaneously.
I've been exploring the Open Flash Chart code and notice that the main class extends the Sprite class:
public class Base extends Sprite {
What does this enable you to do?
Also, on a related note, how do I draw, say, a line once I've extended it?
Without extending Sprite I could write:
var graphContainer:Sprite = new Sprite();
var newLine:Graphics = graphContainer.graphics;
And it would work fine. Once I extend the Sprite class, I'm lost. How do I modify that code so that it still draws a line? I tried:
var newLine:Graphics = this.graphics;
My understanding is that since I'm extending the Sprite class, I should still be able to call its graphics method (or property? I have no idea). But, it yells at me, saying "1046: Type was not found or was not a compile-time constant: Graphics.

Thanks -- that helped get rid of the error, I really appreciate it.
Alas, I am still confused about the extended Sprite class.
Here's my code so far. I want to draw an x-axis:
package charts {
    import flash.display.Sprite;
    import flash.display.Graphics;
    public class Chart extends Sprite {
        // Attributes
        public var chartName:String;
        // Constructor
        public function Chart(width:Number, height:Number) {
            this.width = width;
            this.height = height;
        // Methods
        public function render() {
            drawAxis();
        public function drawAxis() {
            var newLine:Graphics = this.graphics;
            newLine.lineStyle(1, 0x000000);
            newLine.moveTo(0, 100);
            newLine.lineTo(100, 100);
I instantiate Chart by saying var myChart:Chart = new Chart(); then I say myChart.render(); hoping that it will draw the axis, but nothing happens.
I know I need the addChild method somewhere in here but I can't figure out where or what the parameter is, which goes back to my confusion regarding the extended Sprite class.
I'll get this eventually =)

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?

[SOLVED] Confusion about cross-compiling kernel

Similar Messages

Maybe you are looking for