[asterisk-users] Cross compiling Asterisk, Dahdi..

[Tzafrir Cohen]

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