phaag / nfdump

Netflow processing tools
Other
753 stars 195 forks source link

Include dependencies? #505

Closed hentheor closed 5 months ago

hentheor commented 5 months ago

Trying to build [debian-bullseye] latest nfdump with:

configure --enable-nfpcapd --enable-nfprofile  --enable-nftrack  --enable-nsel \
          --enable-sflow \
          --enable-shared=no

undefined reference errors encountered.

Making all in src/nfdump
make[3]: Entering directory '/home/user/BUILD/nfdump-1.7.3/src/nfdump'
.........................
gcc -DHAVE_CONFIG_H -I. -I../..  -I.. -I../include -I../lib -I../output -I../maxmind -I../netflow -I../collector -I../lib/conf -I../inline  -g -O2 -ffile-prefix-map=/home/user/BUILD/nfdump-1.7.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/home/user/BUILD/nfdump-1.7.3=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu17 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -DNSEL -pthread -c -o blocksort.o blocksort.c

/bin/bash ../../libtool  --tag=CC   --mode=link gcc  -g -O2 -ffile-prefix-map=/home/user/BUILD/nfdump-1.7.3=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu17 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -DNSEL -pthread -L../lib -Wl,-z,relro -Wl,-z,now -o nfdump nfdump.o exporter.o nbar.o ifvrf.o nfstat.o nflowcache.o nfprof.o blocksort.o ../lib/libnfdump.la ../output/liboutput.a ../maxmind/libmaxmind.a -lresolv -lpthread -latomic  -lbz2

libtool: link: gcc -g -O2 -ffile-prefix-map=/home/user/BUILD/nfdump-1.7.3=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu17 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -DNSEL -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -o nfdump nfdump.o exporter.o nbar.o ifvrf.o nfstat.o nflowcache.o nfprof.o blocksort.o  -L../lib ../lib/.libs/libnfdump.a ../output/liboutput.a ../maxmind/libmaxmind.a -lresolv -lpthread -latomic -lbz2 -pthread

/usr/bin/ld: ../output/liboutput.a(output_csv.o): in function `csv_record':
./src/output/output_csv.c:123: undefined reference to `FlagsString'
/usr/bin/ld: ../output/liboutput.a(output_fmt.o): in function `String_Flags':
./src/output/output_fmt.c:1465: undefined reference to `FlagsString'
/usr/bin/ld: ../output/liboutput.a(output_json.o): in function `stringEXgenericFlow':
./src/output/output_json.c:93: undefined reference to `FlagsString'
/usr/bin/ld: ../output/liboutput.a(output_raw.o): in function `stringsEXflowMisc':
./src/output/output_raw.c:255: undefined reference to `FlowEndString'
/usr/bin/ld: ./src/output/output_raw.c:255: undefined reference to `biFlowString'
/usr/bin/ld: ../output/liboutput.a(output_raw.o): in function `stringEXgenericFlow':
./src/output/output_raw.c:114: undefined reference to `FlagsString'
/usr/bin/ld: ./src/output/output_raw.c:122: undefined reference to `FlagsString'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:433: nfdump] Error 1

On the other hand, for dynamic option --enable-shared=yes (default behavior) make exits with success. Is this desirable?

Thank you.

phaag commented 5 months ago

I can not reproduce this behavior. I use static linking quite often without an issues. The command line for the linker includes all states libraries libnfdump.a and liboutput.a

Any linker issu on debian-bullseye?

hentheor commented 5 months ago

Peter, the static linking problem for my debian-bullseye box appears at master's commit: "[Refrag code into userio files. Prepare for next level code update]" (b78ffba32d10149f0fe6553fb3f9b692c8fd2c26) and after. All commits before that, compile successfully!!! (I'm interested only in nfdump >= 1.7.3. Compilation is done: A. using debian/rules from unstable src tarball (fixes values for various compilation vars according to debian policy) B. Independently using masters Makefile (leaving default values for various compilation vars). Both ways give compatible outcome. After and at commit b78ffba, static compilation fails.)

The commit b78ffba introduces some code reordering, as far as I can see and understand. (Not much experience in c / c++). Is it possible some reordering remnants trigger linking errors? After all it could be a debian's maintainer assignment...

Thank you.

hentheor commented 5 months ago

...Update... I've tried to explicitly include the relevant code snippets to src/output/output_*.c files. Namely, the error seems to come up from calls to functions defined in src/lib/output_utils.c After copying the whole definition of FlagsString @ output_csv.c and similarly for biFlowString and FlowEndString @ output_raw.c static compilation succeds! (current master)

Can't say if this hack introduces side effects...

phaag commented 5 months ago

It seems as some Linux linkers cannot find text symbols in static libraries given in the same link task. I reordered the linking and cleaned up some code. You should not move code unless for good reason. It's fixed in the latest master repo.