-1

compiler output

I am trying to compile a simple c++ program that calls some functions from the NDPI C library. When compiling using the shared library (.so file) it can't find some of the functions in the library (like set_ndpi_flow_malloc) but seems to be able to find another function called set_ndpi_malloc.

Note: I believe the functions it can't find were newly added to the library when it updated from version 1.8 to 2.0, but the library files I am using were all compiled from source of version 2.0.

Strangely when I compile using the static library (.a) it has no problem finding these functions.

See the image linked above to see the compiler output each time and the code. The two compile attempts were made within a minute of each other and nothing was changed except for one line in the makefile to compile with the static library instead of the shared library.

Update

This has been identified as an issue with the library not exporting all the symbols.

See the issue on github here: https://github.com/ntop/nDPI/issues/459

Daniel E
  • 394
  • 3
  • 13
  • Possible duplicate of [What is an undefined reference/unresolved external symbol error and how do I fix it?](https://stackoverflow.com/questions/12573816/what-is-an-undefined-reference-unresolved-external-symbol-error-and-how-do-i-fix) – user0042 Sep 24 '17 at 17:59
  • You seem to have a space after `-L` – user7860670 Sep 24 '17 at 17:59
  • @VTT I removed it and it didn't make a difference but thanks for the suggestion – Daniel E Sep 24 '17 at 18:01
  • @BronislavElizavetin I just tried doing it with and without -lndpi https://i.imgur.com/cUofcCH.png – Daniel E Sep 24 '17 at 18:11
  • 1
    Then could you please say `nm -D ~/ndpi/precompiled/ndpi/lib/libndpi.a | more` and look up those missing symbols in the output? –  Sep 24 '17 at 18:20
  • Maybe, even something like `nm -D ~/ndpi/precompiled/ndpi/lib/libndpi.a | grep "set_ndpi_flow_"` would be simpler to take a look at. –  Sep 24 '17 at 18:22
  • @BronislavElizavetin wow thanks, so I did nm libndpi.a --demangle and compared the output to that of the same command but for libndpi.so and this was the result https://i.imgur.com/IrNuXUe.png (static on left, shared on right) so it seems like for the shared library set_ndpi_flow_free is local (hence the lowercase t) and set_ndpi_free is global (hence the capital T). For the static library both functions are global. So now I guess I should look into why the shared library made the function local only. – Daniel E Sep 24 '17 at 19:26
  • Yeah, I see, you expanded on `nm` usage and this showed a difference. Shall I re-post my suggestion as an answer or would you prefer to dig the library further and post a self-answer later? –  Sep 24 '17 at 19:40
  • @BronislavElizavetin feel free to make your comment a separate answer if you'd like, I'm going to investigate the root cause of this and I will either accept your answer or create my own based on my findings. – Daniel E Sep 25 '17 at 18:55
  • @DanielE Thanks for your kind permit. I elaborated my thoughts a little bit more and posted it as a separate answer. I hope you'll find it acceptable... –  Sep 26 '17 at 02:27

1 Answers1

1

I made some effort to reproduce your steps.

  1. Clone (download/unpack) the library source from their Github
  2. Enter the source directory of the library
  3. ./autogen.sh (as per README.md, also: libpcap-dev package is needed to be installed in the system)
  4. ./configure (as per README.md)
  5. make (as per README.md)
  6. Create a file in the home directory called test.cpp and place your code there (however, I think that include statement shall be reworded as simply #include "ndpi_api.h")
  7. g++ -c -O3 -Wall -I ./src/include ~/test.cpp (as per your wish)
  8. g++ -O3 -Wall -o test test.o -L ./lib -lndpi (as per your wish)

So, indeed, there are undefined symbols in this case. I used nm -gC ./lib/libndpi.so to read the symbol list and didn't find set_ndpi_flow_malloc and set_ndpi_flow_free. Not mentioned in either way.

I then inspected ./src/include/ndpi_api.h and ./src/lib/ndpi_main.c and couldn't wrap my head around what might have been wrong there. Everything seemed to be OK since these two functions were implemented and defined similar to their counterparts without _flow_. Nevertheless, the difference certainly exists and could be observed in ./libndpi.sym file. As you might see, set_ndpi_malloc and set_ndpi_free are listed there whilst their _flow_ counterparts are not.

So, I deleted the library source and followed the steps 1 and 2 one more time. Then I added these two lines to ./libndpi.sym just after non-_flow_ function names:

set_ndpi_flow_malloc
set_ndpi_flow_free

Next I had to proceed with the steps 3-8 and the last one turned to be successful. Also, nm -gC ./lib/libndpi.so shows the symbols of interest just fine.

I may suppose that forgetting to add the symbol names to .sym file is some sort of mistake. Here is the commit by Vito Piserchia. Perhaps it would be better if you contacted that person or, maybe, lucaderi, who makes the impression of an avid contributor, to tell them about the issue with the symbols. As you may learn from libndpi.sym commit history, they often "add missing symbols", etc.

That's it.

  • Thank you so much you have been extremely helpful!! I followed your steps and verified that my test program works now. I did submit an issue here https://github.com/ntop/nDPI/issues/459 and I will add more information to the issue now that you have identified the cause of the problem. – Daniel E Sep 26 '17 at 14:12