[Xorp-users] Report: XORP-CT cross-compilation with PPC

Sat Jul 17 11:51:54 PDT 2010

Sorry for lately replying, I was confirming some of the answers...

Unfortunately I think I will only be able to execute "git diff" on Monday as
I'm not going to lab this weekend.

I don't have the original builder virtual machine with our XORP SConstruct
file here...

> I used syntax like this when cross-compiling to ARM.  Could you try this
and see if it works?

It seems to work now. Sorry for that...

I think that other commands were not doing well due to a bad library
LINKFLAGS specification. Our toolchain was initially trying to link with an
old libpcap that didn't have send_packet() function. We just cross-compiled
a new libpcap version and replaced it on toolchain.

>Can you give me some details on the OSPF issue?  I don't understand what
you wrote above.

We were initially trying to use xorp without OSPF module on a PIM-SSM
environment. So we disabled things like static RP or bootstrap options.

We statically defined routes on the closed environment system giving them
some "hand-write" metrics.

When we executed the xorp_rtmgr on our config (IGMP, PIM, FIB2MRIB), it
seems that xorp got lost since it recognized the path from client nodes with
higher metrics rather than the smaller one. So it constructed an undesirable
tree from SSM requirements point of view.

Maybe it's just a weak configuration of xorp config file. We got it really
simple. I have attached our final working (whith OSPF) simple config file on
this message. If we remove the OSPF configuration, XORP doesn't understand
the system static metrics.

> What is your goal for size?

We have to take it on less possible space. I think something ~5MB would be
fine.

By simple examining the lib dir on xorp install path, I realized that what
is most space-used is what we really need on multicast task. Do you think
STL could be a space bottleneck on this case?

I'll try following your other tips on IPv6 and libxipc batch code. If I
manage to get it, I'll post my patches.

On Fri, Jul 16, 2010 at 11:45 AM, Ben Greear <greearb at candelatech.com>wrote:

> On 07/16/2010 05:33 AM, Juarez Paulino wrote:
>
>> I think my previous mail didn't get into the list because I have used
>> some formatting.
>>
>> So here comes a copy... I hope it can helps someone.
>>
>
> Thanks for the detailed email!
>
> If it's not too much trouble, can you send the changes as a diff?
>
> git diff > /tmp/foo.patch
>
> If the list won't take it, send directly to me.
>
>
> I think some of these can be rolled in as is, and I can add some
> compile-time args to deal with things like endian-ness checks.
>
> I have a few more comments inline below:
>
>
>   > Our buildroot toolchain already had all of them.
>>  >
>>  >
>>  > 2) Merging cross-compilation environment on SConstruct:
>>  >
>>  > We couldn't get SCons to work with previous export/guest/build
>> options like:
>>  >
>>  > $ export
>> CC=/opt/ppc83xx-linux-uclibc/usr/bin/powerpc-83xx-linux-uclibc-gcc \
>>  > export
>> CXX=/opt/ppc83xx-linux-uclibc/usr/bin/powerpc-83xx-linux-uclibc-g++ \
>>  > export
>> RANLIB=/opt/ppc83xx-linux-uclibc/usr/bin/powerpc-83xx-linux-uclibc-ranlib
>> \
>>  > scons \
>>  > # :( dont work yet...
>>  >
>>  > or:
>>  >
>>  > $ export
>> CC=/opt/ppc83xx-linux-uclibc/usr/bin/powerpc-83xx-linux-uclibc-gcc \
>>  > export
>> CXX=/opt/ppc83xx-linux-uclibc/usr/bin/powerpc-83xx-linux-uclibc-g++ \
>>  > export
>> RANLIB=/opt/ppc83xx-linux-uclibc/usr/bin/powerpc-83xx-linux-uclibc-ranlib
>> \
>>  > scons build=i686-pc-linux-gnu host=powerpc-83xx-linux-uclibc
>>  > # :P dont work either...
>>
>
> I used syntax like this when cross-compiling to ARM.  Could you try this
> and see if it works?  If not, plz send me the output of the failed
> attempt.  Replace my paths with your tools, and change build=
> accordingly.
>
>  scons build=arm-unknown-linux-gnu \
>
>  STRIP=${HOME}/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-sstrip
> \
>
>  CC=${HOME}/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc
> \
>
>  CXX=${HOME}/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-g++
> \
>    CFLAGS=-I${HOME}/x-tools/arm-unknown-linux-gnueabi/local/include \
>    CXXFLAGS=-I${HOME}/x-tools/arm-unknown-linux-gnueabi/local/include \
>    LINKFLAGS=-L${HOME}/x-tools/arm-unknown-linux-gnueabi/local/lib
>
>
>
>   > 3) Eliminating Endianess problem
>>  >
>>  > After some terrible hours of debugging, we managed to cross-compile
>> XORP-CT and not to get the endianess problem on FEA sockets. Our PowerPC
>> machine uses BIG_ENDIAN, but our host cross-compilation machine uses
>> LITTLE_ENDIAN, so endianess-check get wrong parameters when looking for
>> it.
>>  >
>>  > Maybe there is some better ways, but we find it easy to "brute
>> define" things by hand to get xorp_config.h correctly identify endianess.
>>
>
> I'll look into this check when I get some time.  If it could use the
> (cross)-compiler to do the checks, it should be able to work properly
> regardless
> of cross-compiling or not.
>
>
> ==============================================================================
>>  >
>>  >
>>  > - With these modifications, we got XORP-CT top-of-tree Ben version to
>> cross-compile and works fine with PIM module on PPC machine.
>>  >
>>  > - We've tested XORP-CT restricted space versions (only with PIM
>> module and necessary) and it seems to work fine too on our SSM
>> environment.
>>  >
>>  > - Our last stripped working version got around ~9.6MB space:
>>  >
>>  > sudo scons -j4 disable_ipv6=yes disable_fw=yes
>> disable_warninglogs=yes disable_tracelogs=yes disable_fatallogs=yes
>> disable_infologs=yes disable_assertlogs=yes disable_errorlogs=yes
>> enable_olsr=no enable_bgp=no enable_vrrp=no enable_policy=no
>> enable_rip=no optimize=size enable_fea_dummy=no enable_xorpsh=no
>> disable_profile=yes
>>  >
>>  > * We had to enable and configure OSPF module too, as xorp can
>> recognize (i think it inverts) the system metrics...
>>
>
> Can you give me some details on the OSPF issue?  I don't understand
> what you wrote above.
>
>
>   > Our next work and probably most difficult is to reduce more our XORP
>> version.
>>  >
>>  > So do you have any tips beyond Ben PATCHES (on getting out modules,
>> xorpsh and IPv6 code) from where we could begin?
>>
>
> What is your goal for size?
>
> There is probably some more ipv6 code that can be eliminated from
> the core libraries and such.  If you go this route, please do
> it in smaller chunks if possible and send me patches for each chunk.
>
> There may be tools that can help determine what is taking up
> the space in files (code, data, etc)..that might help narrow down
> things to look for.
>
> There is also some 'dead' code in xorp still.  In particular, I
> have been meaning to remove the 'batch' logic from the libxipc
> logic.  It's not used by any code.  Not sure if it will save
> much space though.
>
>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100717/482d4adc/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multi.conf
Type: application/octet-stream
Size: 2570 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100717/482d4adc/attachment.obj 