Is there a proper, documented way to cross compile DAHDI and Asterisk for
a processor/system other than the one you're currently typing on?
Now.. I have been doing this for some time, but it's been really
frustrating every time I change/upgrade, etc.
I've just tried to compile DAHDI for an AMD Geode system on my development
system which is Intel Atom. Building the kernel is easy - been doing that
for years, but DAHDI is just hard and does the wrong thing.
So I start by hardwiring HOTPLUG to no because my target device doesn't
support nor need it. Then setting KVERS to be the correct thing, and this
is picked up by the Makefile, but I really want -march=geode and the only
way I've found to get this is to edit Kbuild directly. (And comment out
all the modules I really don't want to build like torisa, xpp, etc. Even
then it still barfed on the VPMADT032 loader, so I just commented that
whole section out.
Now, at install time, it's fiddling with system files on my build box that
it really should not be touching at all - output from make:
[ `id -u` = 0 ] && /sbin/depmod -a 2.6.32.3-dsx-geode || :
install -d /etc/udev/rules.d
build_tools/genudevrules > /etc/udev/rules.d/dahdi.rules
build_tools/genudevrules: line 3: udevinfo: command not found
build_tools/genudevrules: line 7: udevadm: command not found
install -m 644 drivers/dahdi/xpp/xpp.rules /etc/udev/rules.d/
for hdr in kernel.h user.h fasthdlc.h wctdm_user.h dahdi_config.h; do \
install -D -m 644 include/dahdi/$hdr
/usr/include/dahdi/$hdr; \
done
rmdir: failed to remove `/usr/include/zaptel': No such file or directory
make: [install-include] Error 1 (ignored)
I don't use udev on my build system, nor my target systems so why is it
bothering... But I feel there really ought to be a means to tell it that
it's not building for the local system, so don't fiddle with local
files...
Bah!
OK. I appreciate that probably no-one actually bothers to compile a custom
kernel, nor tune dahdi/asterisk to the underlying hardware, and
probably no-one does a "true" cross compile but even so...
It's just being a frustrating afternoon.
(Although I would appreciate hearing from people who do cross compile
"properly" for other chips - eg. compile for ARM on an Intel, etc.)
Gordon
Jean-Denis Girard
2010-Jan-16 17:00 UTC
[asterisk-users] Cross compiling Asterisk, Dahdi..
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Gordon Gordon Henderson a ?crit :> Is there a proper, documented way to cross compile DAHDI and Asterisk for > a processor/system other than the one you're currently typing on?Here is what I'm doing for building dahdi modules on my x86_64 system, for geode target. In dahdi linux directory: make KVERS=2.6.33-rc3-git3-sysnux KSRC=/home/jdg/RPM/BUILD/linux Then install in /tmp/dahdi: make DESTDIR=/tmp/dahdi ARCH=i386 KVERS=2.6.33-rc3-git3-sysnux KSRC=/home/jdg/RPM/BUILD/linux install-modules Then I make a tar of /tmp/dahdi, and extract that archive on the geode target. I don't know if it's the proper way to do it, but it works fine for me. Thanks, - -- Jean-Denis Girard SysNux Syst?mes Linux en Polyn?sie fran?aise http://www.sysnux.pf/ T?l: +689 50 10 40 / GSM: +689 79 75 27 -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAktR8KoACgkQuu7Rv+oOo/jTVgCcDGNON+UlFwz59ykMFV1aQWEy gpEAn1MNPrqYfUoTowdjUbMexGqTvkz9 =RD6g -----END PGP SIGNATURE-----
On Sat, Jan 16, 2010 at 03:54:44PM +0000, Gordon Henderson wrote:> > Is there a proper, documented way to cross compile DAHDI and Asterisk for > a processor/system other than the one you're currently typing on? > > Now.. I have been doing this for some time, but it's been really > frustrating every time I change/upgrade, etc. > > I've just tried to compile DAHDI for an AMD Geode system on my development > system which is Intel Atom. Building the kernel is easy - been doing that > for years, but DAHDI is just hard and does the wrong thing. > > So I start by hardwiring HOTPLUG to no because my target device doesn't > support nor need it.HOTPLUG is a slightly misleading name. If it is enabled, it means firmware loading from userspace is enabled in the kernel. If so, drivers for some digium cards will not include the firmware inside them. Most system I know support firmware loading. If you don't use those cards, those drivers will simply be smaller (as they don't include the firmware blobs). In short: leave this one for automatic detection.> Then setting KVERS to be the correct thing,Hmm... I'm not really sure if KVERS is still used (if you explicitly set KSRC, that is).> and this > is picked up by the Makefile, but I really want -march=geode and the only > way I've found to get this is to edit Kbuild directly.Kbuild should do that for you. Or rather: if you used that for building the kernel, it should also be used for DAHDI. If this doesn't work, I suspect your kernel tree is misconfigured. Reminder: to make Kbuild print the full build lines, use: make V=1> (And comment out > all the modules I really don't want to build like torisa, xpp, etc. Even > then it still barfed on the VPMADT032 loader, so I just commented that > whole section out.What error did you get?> > Now, at install time, it's fiddling with system files on my build box that > it really should not be touching at all - output from make: > > [ `id -u` = 0 ] && /sbin/depmod -a 2.6.32.3-dsx-geode || : > install -d /etc/udev/rules.d > build_tools/genudevrules > /etc/udev/rules.d/dahdi.rules > build_tools/genudevrules: line 3: udevinfo: command not found > build_tools/genudevrules: line 7: udevadm: command not found > install -m 644 drivers/dahdi/xpp/xpp.rules /etc/udev/rules.d/ > for hdr in kernel.h user.h fasthdlc.h wctdm_user.h dahdi_config.h; do \ > install -D -m 644 include/dahdi/$hdr > /usr/include/dahdi/$hdr; \ > done > rmdir: failed to remove `/usr/include/zaptel': No such file or directory > make: [install-include] Error 1 (ignored) > > I don't use udev on my build system, nor my target systems so why is it > bothering... But I feel there really ought to be a means to tell it that > it's not building for the local system, so don't fiddle with local > files...You don't use udev at all? In this case those static device files will actually have to be created on the target system.> > Bah! > > OK. I appreciate that probably no-one actually bothers to compile a custom > kernel, nor tune dahdi/asterisk to the underlying hardware, and > probably no-one does a "true" cross compile but even so... > > It's just being a frustrating afternoon. > > (Although I would appreciate hearing from people who do cross compile > "properly" for other chips - eg. compile for ARM on an Intel, etc.)I note you didn't really include the commands you used. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen at xorcom.com +972-50-7952406 mailto:tzafrir.cohen at xorcom.com http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir