C++ Linking Error: invalid DSO for symbol

I am on a FreeBSD system trying to build a piece of software that I wrote. I had built it in the past but recently reinstalled FreeBSD. I am not sure what is going on. The software depends on and wxgtk2.8.

Using g++:

$ make
g++ -c `wx-config --cxxflags` -DPIXMAPDIR="\"/usr/local/share/pixmaps\""  -DABCDIR="\"/usr/local/share/myabcs\"" -Iinclude src/gnrcabt.cpp
g++ -c `wx-config --cxxflags` -DPIXMAPDIR="\"/usr/local/share/pixmaps\""  -DABCDIR="\"/usr/local/share/myabcs\"" -Iinclude src/abc.cpp
g++ -c `wx-config --cxxflags` -DPIXMAPDIR="\"/usr/local/share/pixmaps\""  -DABCDIR="\"/usr/local/share/myabcs\"" -Iinclude src/main.cpp
Making project myabcs version 0.4.5.
g++ -v -s `wx-config --libs` gnrcabt.o abc.o main.o -o myabcs 
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/lto-wrapper
Target: x86_64-portbld-freebsd10.1
Configured with: ./../gcc-4.8.4/configure --disable-bootstrap --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc48
--libexecdir=/usr/local/libexec/gcc48 --program-suffix=48 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc48/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection'
--with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local
--mandir=/usr/local/man --infodir=/usr/local/info/gcc48 --build=x86_64-portbld-freebsd10.1
Thread model: posix
gcc version 4.8.4 (FreeBSD Ports Collection) 
COMPILER_PATH=/usr/local/libexec/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/:/usr/local/libexec/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/:/usr/local/libexec/gcc48/gcc/x86_64-portbld-freebsd10.1/:/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/:/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/
LIBRARY_PATH=/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/:/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-s' '-L/usr/local/lib' '-pthread' '-fstack-protector' '-L/usr/local/lib' '-o' 'myabcs' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/collect2 --eh-frame-hdr -V
-dynamic-linker /libexec/ld-elf.so.1 -o myabcs -s /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/crtbegin.o
-L/usr/local/lib -L/usr/local/lib -L/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4
-L/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/../../.. -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8
-lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8
gnrcabt.o abc.o main.o -lstdc++ -lm -lssp_nonshared -lgcc_s -lgcc -lpthread -lc -lgcc_s
-lgcc /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/crtend.o /usr/lib/crtn.o
GNU ld (GNU Binutils) 2.25
  Supported emulations:
   elf_x86_64_fbsd
   elf_i386_fbsd
   elf_x86_64
   elf_i386
   elf_l1om
   elf_l1om_fbsd
   elf_k1om
   elf_k1om_fbsd

Using clang:

$ make CC=clang
clang -c `wx-config --cxxflags` -DPIXMAPDIR="\"/usr/local/share/pixmaps\""  -DABCDIR="\"/usr/local/share/myabcs\"" -Iinclude src/gnrcabt.cpp
clang -c `wx-config --cxxflags` -DPIXMAPDIR="\"/usr/local/share/pixmaps\""  -DABCDIR="\"/usr/local/share/myabcs\"" -Iinclude src/abc.cpp
clang -c `wx-config --cxxflags` -DPIXMAPDIR="\"/usr/local/share/pixmaps\""  -DABCDIR="\"/usr/local/share/myabcs\"" -Iinclude src/main.cpp
Making project myabcs version 0.4.5.
clang -v -s `wx-config --libs` gnrcabt.o abc.o main.o -o myabcs 
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix
Selected GCC installation: 
 "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o myabcs /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib -L/usr/local/lib -L/usr/lib -s -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8
-lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8
-lwx_baseu_net-2.8 -lwx_baseu-2.8 gnrcabt.o abc.o main.o -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed
-lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
/usr/bin/ld: //usr/lib/libc++.so.1: invalid DSO for symbol `_ZdlPv' definition
//usr/lib/libc++.so.1: could not read symbols: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Not sure what is going on. I'll have to see if I can compile another program with wxgtk.

It is hard to say - it looks like a mismatch, perhaps a shared object file with newer or missing symbols. Although - a reinstall should not have caused a problem, were there some updates to the reinstall that you deferred?

I don't think there were any updates that would have effected it. I just built another project that uses wxgtk2.8 and it works fine. I must have done something to my compiler commands in the Makefile.

What's the output from

wx-config --cxxflags
wx-config --libs

What are the C++ flags used on the source that worked?

$ wx-config --cxxflags --libs
-I/usr/local/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-D__WXGTK__ -pthread -D_THREAD_SAFE
-L/usr/local/lib -pthread  -fstack-protector  -L/usr/local/lib   -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8
-lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8
-lwx_baseu-2.8

There's not much there that could cause a problem. I don't see any support for "-fstack-protector" in the clang documentation, though.

What's the output from "file .../main.o" and all your other object files, from both GCC and clang? Maybe something shows up there.

Hopefully you're not running up against a compiler bug.

"Invalid DSO" can sometimes mean "symbol not found" these days. I got that error while linking -lssl but not linking -lcrypto too.

Clang:

$ for o in `ls | grep -i "\.o"`; do file ${o}; done
abc.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
gnrcabt.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped

g++:

$ for o in `ls | grep -i "\.o"`; do file ${o}; done
abc.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
gnrcabt.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped

--- Edit ---

After stripping the object files I got this error from Clang:

/usr/bin/ld: error in gnrcabt.o(.eh_frame); no .eh_frame_hdr table will be created.
/usr/bin/ld: error in abc.o(.eh_frame); no .eh_frame_hdr table will be created.
/usr/bin/ld: error in main.o(.eh_frame); no .eh_frame_hdr table will be created.
/usr/lib/crt1.o: In function `_start':
/usr/src/lib/csu/amd64/crt1.c:(.text+0x16b): undefined reference to `main'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Thought it might be missing something.

main() is where your program begins, if that's missing it can't create an executable. Libraries on the other hand don't need a main().

Check that the code which is supposed to define it is getting compiled, and also check that main is being exported properly. If it's being hashed into a C++ overloaded name, the linker might not find it. You could give it a definition to avoid it being name-mangled.

// Forcing main to export as _main in a C++ program
extern "C" int main(int argc, char *argv[]);

// Actual definition for main
int main(int argc, char *argv[]) {
...
}

wxgtk defines the "main" function:

#include "main.h"
#include "abc.h"

IMPLEMENT_APP(App)

bool App::OnInit()
{
    MainWindow *frame = new MainWindow(_T(""));
    frame->Show(true);
    SetTopWindow(frame);

    return true;
}

There must be a bug in the wxgtk2.8 build for FreeBSD. Guess it's time to start porting to wxgtk3.0 anyway. :-\

I'll try doing a custom build of wxgtk2.8.