Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] cross-compile tcpreplay for armv5 freescale #623

Closed
dummys opened this issue Nov 13, 2020 · 8 comments
Closed

[Bug] cross-compile tcpreplay for armv5 freescale #623

dummys opened this issue Nov 13, 2020 · 8 comments
Assignees
Labels

Comments

@dummys
Copy link

dummys commented Nov 13, 2020

Hi,

Im trying to cross compile tcpreplay for armv5 but I get the following eror when doing it:
PS: libpcap is compiled successfully. I'm using two different toolchain, one from crosstool-ng rm-unknown-linux-gnueabi and arm-unknown-linux-gnueabihf but both fail with the same error:

In file included from ../../src/common/timer.h:31,
                 from ../../src/common.h:45,
                 from cidr.c:23:
/usr/include/math.h:462:21: error: '_Float128' is not supported on this target
 # define _Mdouble_  _Float128

My command is:

CC=arm-unknown-linux-gnueabi-gcc ./configure --host=arm-unknown-linux-gnueabi --with-libpcap=/home/build/cross-compiling/arm-32/libpcap-1.9.1_comp/compiled --prefix=/home/build/cross-compiling/arm-32/tcpreplay-4.3.3/compiled
@fklassen
Copy link
Member

Not sure why it is picking up the local math.h rather than the cross compiler's. Maybe get rid of --host=

Can you compile 64-bit?

@dummys
Copy link
Author

dummys commented Nov 13, 2020

no I can't because the target is x32

Without --host its failing:

checking whether to enable maintainer-specific portions of Makefiles... yes
checking if malloc debugging is wanted... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for cygwin development environment... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... arm-unknown-linux-gnueabi-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... configure: error: in `/home/build/cross-compiling/arm-32/tcpreplay-4.3.3':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

also tried with --target= same problem

I tried settings this :

set -x PATH "$PATH:/home/build/x-tools/arm-unknown-linux-gnueabi/bin/"
set -x CFLAGS "-march=armv5tej -mfloat-abi=soft"
set -x CC arm-unknown-linux-gnueabi-gcc

Then configure with:

./configure --host=arm-unknown-linux-gnueabi --with-libpcap=/home/build/cross-compiling/arm-32/libpcap-1.9.1_comp/compiled --prefix=/home/build/cross-compiling/arm-32/tcpreplay-4.3.3/compiled --with-sysroot=/home/build/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot

Still picking the /usr/include/math.h from the host.

@dummys
Copy link
Author

dummys commented Nov 16, 2020

@fklassen do i need to cross compile tcpdump and libdnet too ?

@dummys
Copy link
Author

dummys commented Nov 16, 2020

i cross compiled libdnet, tcpdump also and use this now:

set -x PATH "/home/build/x-tools/arm-unknown-linux-gnueabi/bin/:/home/mofo/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot/usr/include:$PATH"


set -x CPPFLAGS "/home/build/cross-compiling/arm-32/libpcap-1.9.1/compiled/lib/libpcap.so"


set -x LDFLAGS "/home/build/cross-compiling/arm-32/libpcap-1.9.1/compiled/lib/libpcap.so"

./configure --host=arm-unknown-linux-gnueabi --with-libpcap=/home/build/cross-compiling/arm-32/libpcap-1.9.1 --prefix=/home/build/cross-compiling/arm-32/tcpreplay-4.3.3/compiled --enable-static-link --with-tcpdump=/home/build/cross-compiling/arm-32/tcpdump-4.9.3/tcpdump --with-libdnet=/home/build/cross-compiling/arm-32/libdnet-1.11/compiled

And i get further the error of fpu error, but now I have another one popping:

/home/build/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/8.3.0/../../../../arm-unknown-linux-gnueabi/bin/ld.bfd: ./common/libcommon.a(utils.o): in function `_our_safe_realloc':
utils.c:(.text+0xb4): undefined reference to `rpl_realloc'
/home/build/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/8.3.0/../../../../arm-unknown-linux-gnueabi/bin/ld.bfd: ../libopts/.libs/libopts.a(libopts_la-libopts.o): in function `ao_realloc':
libopts.c:(.text+0x2088): undefined reference to `rpl_realloc'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:717: tcpreplay] Error 1

Seems to be well known error on arm but tested all the fix and cannot find that works:

add ac_cv_func_malloc_0_nonnull=yes on configure

Check for AC_MALLOC in configure etc...

EDIT found a fix for this bug... remove the AC_FUNC_REALLOC in configure.ac

@dummys
Copy link
Author

dummys commented Nov 16, 2020

now I struggle with building a static tcpreplay version, its not possible despite I used "-static" everywhere I can, like in lddflags, cflags etc...

@fklassen
Copy link
Member

It sounds like you found a fix similar to this.

You seem to have issues with your compiler. Unfortunately I would say you are on your won to figure out how to get static to work. You probably have issues with your libraries not containing static libraries.

@dummys
Copy link
Author

dummys commented Nov 17, 2020

yes but the problem of AC_FUNC_REALLOC is in your configure.ac. Not in my toolchain. It seems to be a error that appear mainly on cross compile for arm.

@fklassen fklassen self-assigned this Feb 24, 2021
@fklassen fklassen added the bug label Mar 13, 2021
@fklassen
Copy link
Member

fixed in PR #641

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants