It seems that since I re-installed C::B(now using 3455) and cygwin(fresh install of both), all of my projects fail during the linking stage. I'm not sure whether this is a Cygwin-GCC problem, or a C::B problem. However, C::B should be able to fix what I describe below.
The problem is the order of object files given to the linker. Noramlly, files with the most dependencies go first, while files with no dependencies go last. This ensures that the linker links all external functions and data.
Output:
-------------- Build: Debug in libBSException ---------------
g++.exe -Wall -DLIBBSEXCEPTION_EXPORTS -g -DDEBUG -DWIN32 -ID:/Projects/libBSException/ -c NullPointer.cpp -o .objs/Debug/NullPointer.o
g++.exe -Wall -DLIBBSEXCEPTION_EXPORTS -g -DDEBUG -DWIN32 -ID:/Projects/libBSException/ -c NullPointerNF.cpp -o .objs/Debug/NullPointerNF.o
g++.exe -Wall -DLIBBSEXCEPTION_EXPORTS -g -DDEBUG -DWIN32 -ID:/Projects/libBSException/ -c Exception.cpp -o .objs/Debug/Exception.o
g++.exe -shared -Wl,--dll -L .objs/Debug/NullPointer.o .objs/Debug/NullPointerNF.o .objs/Debug/Exception.o -o bin/libBSException_d.dll
.objs/Debug/NullPointerNF.o: In function `_ZN2BS10Exceptions13NullPointerNFD0Ev':
/cygdrive/d/Projects/libBSException/NullPointerNF.cpp:(.text+0x14): undefined reference to `BS::Exceptions::NullPointer::NullPointer(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
.objs/Debug/NullPointerNF.o: In function `_ZN2BS10Exceptions13NullPointerNFC1ERKSs':
/cygdrive/d/Projects/libBSException/NullPointerNF.cpp:4: undefined reference to `BS::Exceptions::NullPointer::NullPointer(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
.objs/Debug/NullPointerNF.o: In function `_ZN2BS10Exceptions13NullPointerNFD0Ev':
/cygdrive/d/Projects/libBSException/NullPointerNF.cpp:(.text$_ZN2BS10Exceptions11NullPointerD2Ev[BS::Exceptions::NullPointer::~NullPointer()]+0xb): undefined reference to `vtable for BS::Exceptions::NullPointer'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 2 seconds)
1 errors, 0 warnings
This is the output of one of my smaller projects. As you can see, the linker is given a list of object files in alphabetical order, which is incorrect. The NullPointerNF.o file should be first, because it has dependencies in NullPointer.o and Exception.o. I can manually fix this, but this requires me to change the compilation priority of all my files in every project. Normally, link dependencies can be assumed in such a way: if object A's source includes object B's header, then object A can be assumed to depend on object B, and should therefore come before B on the link command.
Maybe theres a new GCC option that will alleviate this easier? Get back to me, please.
That's the way it should be, but obviously not anymore.
When I change the compile priority of NullPointerNF to 40 and NullPointer to 45 I get this:
-------------- Build: Debug in libBSException ---------------
g++.exe -pedantic -Wall -DLIBBSEXCEPTION_EXPORTS -g -DDEBUG -DWIN32 -ID:/Projects/libBSException/ -c NullPointerNF.cpp -o .objs/Debug/NullPointerNF.o
g++.exe -pedantic -Wall -DLIBBSEXCEPTION_EXPORTS -g -DDEBUG -DWIN32 -ID:/Projects/libBSException/ -c NullPointer.cpp -o .objs/Debug/NullPointer.o
g++.exe -pedantic -Wall -DLIBBSEXCEPTION_EXPORTS -g -DDEBUG -DWIN32 -ID:/Projects/libBSException/ -c Exception.cpp -o .objs/Debug/Exception.o
g++.exe -shared -Wl,--dll -L .objs/Debug/NullPointerNF.o .objs/Debug/NullPointer.o .objs/Debug/Exception.o -o bin/libBSException_d.dll
Running target post-build steps
cp -f bin\libBSException_d.dll D:\cygwin\usr\lib
Running project post-build steps
cp -f *.h D:\cygwin\usr\include/BS/
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 0 warnings
GCC -v:
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --ver
bose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libe
xecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-langu
ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --
enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-
awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-thre
ads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptio
ns --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Mind you, I am using the newest cygwin packages, so maybe the newest version of gcc released is different?
I wouldn't call gcc 3.4.4 "the newest" :).
Besides, I see something else wrong:
g++.exe -shared -Wl,--dll -L .objs/Debug/NullPointerNF.o
What's that stray "-L" doing there? You understand that all it does is add the (non-existent) directory ".objs/Debug/NullPointerNF.o" to the linker search dirs? Effectively not linking the actual object file?