Link Order

[Raijinsetsu]

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:

Code

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

[mandrav]

You got something wrong there... The linking order matters for libraries only, not object files...

[Raijinsetsu]

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:

Code

-------------- 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

Which, as you can see, works. Mind you, I am using the newest cygwin packages, so maybe the newest version of gcc released is different?
GCC -v:

Code

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)

[mandrav]

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:

Code

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?

[Raijinsetsu]

[edited]
Ugh... Just for the hell of it, I searched for the source of the spurious -L argument. It was an old project option that isn't used in my new install.
I see now that it was using .objs/NullPointer.o as a directory(this file has the dependencies for NullPointerNF.o).

 Thanks.