Question

I’m supposed to use a data analysis program for a physics experiment. I can’t get it to compile though.

The code is old, not really compatible with current GCC-versions from what I can find. To make things a bit more time-comsuming, I got the code from a guy who had modified all the makefiles to make it compile on Mac. I have no C++-experience, but with man-pages, Google and patience I have fixed a lot of errors on the way, but I’m stuck on this one, even after a week of tries and googling.

I believe the relevant error message is the following:

/usr/bin/ld: error in /home/daniel/skola/exjobb/miniballscripts
/lib/libCommandLineInterface.so(.eh_frame); no .eh_frame_hdr table will be created.`

What can be the cause, and what can be the remedy?

libCommandLineInterface.so was compiled by me before, without any apparent error messages:

$ make  
g++ -g2 -O2 -I./ -c CommandLineInterface.cc -o CommandLineInterface.o  
g++ -g  -Wl -o /home/daniel/skola/exjobb/miniballscripts/lib/libCommandLineInterface.so
CommandLineInterface.o -lm -L/home/daniel/skola/exjobb/miniballscripts/lib -lgcc -lc  
Done

My g++-version is g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3, amd64.

• http://tinypaste.com/9eee9 – make output
• http://tinypaste.com/ddbde – GNUmakefile

As I said, I have no experience with C++, so maybe my naive Makefile modifications have destroyed something. My lack of experience also makes me not really knowing what other information is needed to help me, but I’ll be glad to reply.

Answer 1

Looks like you have forgotten the -shared command line option when you generate the libCommandLineInterface.so file. That would explain those multiple definition errors. If the linker thinks that the file it is generating is an executable (instead of a dynamic library), then it would link in the startup code, etc. When you try to use this .so file, those symbols coming in from the startup code will clash with those that are being added to the executable that uses the dynamic library.

It is possible that the libTransfer.so errors are related to the same flag being omitted. A shared library is allowed to have dangling references (that get resolved when the library is used), but an executable has to have all the symbols resolved at link time. This is probably an oversimplification of how things are, but I never needed to get into more details on dynamic linking in linux. 🙂 Anyhow, adding -shared option may solve the undefined reference errors as well.