Who cross compile rtptools

[mcd500]

The configure file in master branch do not support cross compile at the moment.

These are the examples for the person who just want to download it and croos build it.

$ git clone https://github.com/columbia-irt/rtptools rtptools-autotools
$ cd rtptools-autotools
$ git checkout with-autotools
$ aclocal
$ automake --add-missing --force--missing
$ autoconf

For ARM32
$ ./configure --host=arm-linux-gnueabihf
$ make clean
$ make
$ file rtptrans
rtptrans: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=26761e8336bb5b7b353be19b72426d528d577b4d, not stripped

For ARM64
$ ./configure --host=aarch64-linux-gnu
$ make clean
$ make
$ file rtptrans
rtptrans: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=f750a201408358aaace438739278b199d34d5122, not stripped

For PPC32 which is bigendian and has advantage on performance of network packet processing.
$ ./configure --host=powerpc-linux-gnu
$ make clean
$ make
$ file rtptrans
rtptrans: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=3a3d2191be1d0170b2ffc73748e00e397b77cfaa, not stripped

For PPC64 also bigendian
$ ./configure --host=powerpc64-linux-gnu
$ make clean
$ make
$ file rtptrans
rtptrans: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=c3b13403204fbe119a7717d9cfdb6d54b6100bee, not stripped

[janstary]

All of these archs run linux (by definition),
so they can compile natively, which makes this a bit pointless.

In general though, we are interested in platforms that do need to cross-compile.
Please report here if you want to run rtptools on such a platfrom.

[mcd500]

The rtp protocol are used on voice/tele conference machine.
Working at the electronic company would require to have cross-compiling since it can not build natively on the device like polycon and cisco products.

[mcd500]

It is very strange for me for the comment.
"so they can compile natively, which makes this a bit pointless."
while the huge number of engineers have to use cross-compilation for making earnings.

[mcd500]

The products of embedded network device such as voice/tele conference machines tend to use bigendian hardware for the performance of handling network byte order.

[janstary]

Yes, every HW VOIP phone (for example) needs to have a RTP implementation.
And most probably it has been cross-compiled for the machine. And yes, telco engineers
must cross-compile that stuff daily. How does that relate to rtptools specificaly?

But really, if anyone needs to cross-compile rtptools, please report here.

[mcd500]

I did have to cross compile rtptools when I was working for electronic companies.

When prototype boards comes out from hardware department, and the software engineer have to work on the board,
often time what happened was that initial batch did not have any of external network connection such as ethernet or 3G/LTE were not working.
Some time, the board does not have ethernet chip or came out with the chip do not have driver (or changed without notifying software department) or 3G/LTE have not passed the FCC/Telec compliance and can not distribute any radio out of the device even working inside the building (Precious Anechoic chamber is for hardware engineer to pass the compliance as soon as possible).

But software programmer would like to test RTP protocol as soon as possible to meet the deadline.
So easiest to test RTP packets from the software stack was using rtpdump, rtpplay and rtpsend internally in the board using localhost, for at least cheeking the packet confirmation and integrity.

The supporting cross-compilation on the new configure is not high priority but it is worth making it work in the future.

[janstary]

Running rtpdump and rtpplay localy is exactly what I intend to do in make test :-)