C++: compilation error - “no .eh_frame_hdr table w

问题:

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.

回答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.

回答2:

The linking errors of concern start with:

[...]/lib/libCommandLineInterface.so: In function `_start':
(.text+0x0): multiple definition of `_start'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o:(.text+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `_fini':
(.fini+0x0): multiple definition of `_fini'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crti.o:(.fini+0x0): first defined here
[...]/lib/libCommandLineInterface.so:(.rodata+0x0): multiple definition of `_IO_stdin_used'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o:(.rodata.cst4+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `__data_start':
(.data+0x0): multiple definition of `__data_start'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o:(.data+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `__data_start':
(.data+0x8): multiple definition of `__dso_handle'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbegin.o:(.data+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `_edata':
(*ABS*+0x607130): multiple definition of `__bss_start'
[...]/lib/libCommandLineInterface.so: In function `_end':
(*ABS*+0x6073b8): multiple definition of `_end'
[...]/lib/libCommandLineInterface.so: In function `_edata':
(*ABS*+0x607130): multiple definition of `_edata'
[...]/lib/libCommandLineInterface.so: In function `main':
/home/daniel/skola/exjobb/miniballscripts/Common/CommandLineInterface.cc:6: multiple definition of `main'

The symbols that are multiply defined are 'standard' on Unix - and I've never needed to bother with them myself on Mac either, though I don't do GUI programming there.

You need to look at libCommandLineInterface.cc with a very prejudiced attitude and decide whether it provides anything that you need. You might be able to remove it altogether. If it contains some stuff you do need, you will need to cauterize the material that defines _start, and _end and main and so on.

You are also going to have to worry about the missing vtables:

[...]/libTransfer.so: undefined reference to `vtable for Annular'
[...]/libTransfer.so: undefined reference to `ROOT::GenerateInitInstance(Barrel const*)'
[...]/libTransfer.so: undefined reference to `ROOT::GenerateInitInstance(Annular const*)'
[...]/libTransfer.so: undefined reference to `vtable for Barrel'
[...]/libTransfer.so: undefined reference to `vtable for Crystal'
[...]/libTransfer.so: undefined reference to `vtable for Germanium'

回答3:

It's solved. The eh_frame_hdr-problem was solved by this thread. The undefined references was solved by deleting libTransfer.so after the first make, and then directly afterwards running make again. Don't ask me how, but that made it compile.