We actually managed to build Suricata using gcc and a handmade linking command.
Meson and ninja in DPDK use a linking gcc command with something like “-Wl,–start-group [many DPDK-related *.a files] -Wl,–end-group”.
I provided a LDFLAGS=“-Wl,–start-group [many DPDK-related *.a files] -Wl,–end-group” to .configure. When compiling Suricata, the libtool command which builds .libs/suricata (which is the file that is installed later on) however uses a a command that looks like “-Wl,–start-group […] -Wl,–end-group […] -Wl,–as-needed -L[many DPDK-related *.a files]”.
I think this is related to libtool behavior. I did not really dig into this yet. I will do it as soon as possible.
I do not want to replace the Autotools build system with Meson/Ninja build system.
My issue is that: on my ARM DPDK, it looks like the linking step of an executable that use DPDK seem to need a specific option set provided to gcc during linking. This option looks like “-Wl,–start-group [many DPDK-related *.a files] -Wl,–end-group”.
I actually checked that this option is needed using a small C tool that lists DPDK interfaces. During linking, if I do not use this option with gcc, the tool cannot find my interface. But, if I use this option with gcc, the tool finds my interface.
As I said above, I tried to provide a LDFLAGS=“-Wl,–start-group [many DPDK-related *.a files] -Wl,–end-group” to .configure. When compiling Suricata, the libtool command which builds .libs/suricata (which is the file that is installed later on) however uses a a command that looks like “-Wl,–start-group […] -Wl,–end-group […] -Wl,–as-needed -L[many DPDK-related *.a files]”. I can provide log files for these two steps.
If I manually link Suricata with a custom gcc command that uses the “-Wl,--start-group [many DPDK-related *.a files] -Wl,--end-group” option, Suricata sees my interface.
My goal now is to find a way to make the Autotools build system use the option I need during linking.
I do not plan to make any local modification to the Suricata source code (at least not soon ), so I could also keep my final custom linking step in the short term. But I am also interested in having a cleaner/simpler compilation process.
I’ve tried compiling Suricata on ARM (aarch64) VM and I had no problem with that. I’ve used Ubuntu 22.04 server which had all dependencies installable from the repositories so I’ve only compiled Suricata. I didn’t need to modify anything anywhere.
I think your problem might lie in the installation of DPDK in an unknown location. Did you install DPDK from repositories (dpdk-devel) or did you compile it yourselves? With DPDK you can use pkg-config tool. This tool is also used during configure step e.g. pkg-config --libs libdpdk. Please check if the command outputs something as it is crucial to proceed further.
If you compiled DPDK yourself (and the pkg-config does not recognize libdpdk) then the easiest solution would be to change the installation folder of the DPDK. That can be done with meson during the configuration step of DPDK with --prefix option.
Thank you for taking some time to help me.
My ARM board is a SolidRun HoneyComb LX2. The OS image is Debian Bullseye which is built using this Github repo.
As far as I know, the OS image however does not include DPDK files. So I compiled it and installed it locally. The DPDK library is thus installed in my home directory (/home/jmazel/install/dpdk).
If I provide the “PKG_CONFIG_PATH=/home/jmazel/install/dpdk/lib/pkgconfig” variable to the ./configure script, I still get the same linking error as what I explained here. Similarly, my custom linking command is still working.
Does setting up PKG_CONFIG_PATH with a custom value related to the location of the manually compiled DPDK installation on the configure command line was what you had in mind or did I misunderstand you?
Thank you again for your time.