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

[Gordon Henderson]

On Sun, 17 Jan 2010, Tzafrir Cohen wrote:

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

None of the cards I use require firmware loading.

OK - I build very precise and specific systems. Call me old fashioned if 
you like, but I compile a kernel with the exact requirements for my 
systems - no hotplug, no udev, no modules - just a precise kernel and a 
cut-down installation of my own devising, but it's based on Debian.

The hotplug check fails on my systems - not sure why, but I've always had 
to force it to no (as advised by the comments in the makefile!).

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

Comment in the Makefile under: dahdi-linux-complete-2.2.0.2+2.2.0/linux

# If you want to build for a kernel other than the current kernel, set KVERS

So I set KVERS in the environment. That is the only way to get the build 
process to find the modules directory for my target kernel (cross compiled 
on my build system). So

   # echo $KVERS
   2.6.32.3-dsx-geode


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

I doubt it, but am willing to check - it's a vanilla kernel off 
kernel.org, compiled as per the instructions - the way I've been doing it 
for ever. I use make menuselect, then select the options I want. Module 
loading is enabled. Make the kernel (make bzImage), then make modules and 
make modules_install. Not that there are any modules, but it populates 
/lib/modules/2.6.32.3-dsx-geode with the right stuff.

> Reminder: to make Kbuild print the full build lines, use:
>
>  make V=1

Actually, that's handy. I was grepping the output of 'ps' to find the gcc 
command lines to see what it was doing and make sure it was picking up 
-march=geode

>> (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?

WARNING: "voicebus_get_pci_dev" [/var/space/local/src/dsx/dahdi-linux-complete-2.2.0.2+2.2.0/linux/drivers/dahdi/dahdi_vpmadt032_loader.ko] undefined!

And there are a few more like that.

Maybe the warnings can be ignored, but my guess is that it's looking for a 
loader in a kernel that's not configured for hotplug.

>> 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?

Not at all.

> In this case those static device files will
> actually have to be created on the target system.

Yes, and I don't have a problem with that.

> I note you didn't really include the commands you used.

I don't think the commands I used are actually that relevant here, but 
since you asked:

   make
   vi

and a few other, cp, mv, and maybe tar to unpack things.

As I said above, it's just frustrating, but I suspect there are very, very 
few people actually doing this - maybe the blackfin people cross compile, 
who knows. I'm no a fan of the generic/general purpose instalaltion 
systems we have because I feel they're bloated and unneccessarily 
complicated - again, call me old if you like, but I have a lightweight 
system cut-down to the bare neccessities that runs entirely from RAM, 
blindlingly fast on relatively slow (500Mhz) processors - that's the way I 
like them and the way I've been working with systems, embedded and 
otherwise for the past 30 years. I'm appauled at the lazyness of a lot of 
todays modern programmers and systems builders, but maybe that's just 
me... (cue 4 yorkshiremen)

Gordon