Quoting Stephen GALLIMORE: > > > > What about adding a workaround in configure.in? > > > > Or there might be a reason why LD is not affected. > Indeed, we did look at this, the obvious adding > AC_PROG_LD to configure.in didn't seem to have > the desired effect. Three of us tried in vain to follow > the tortuous maze of autoconf, automake and libtool > to try and work out how _any_ of the TOOL = @TOOL@ > lines get created in the Makefile.in files from the > Makefile.am templates. Short answer, we gave up > and decided there were more important things in life!
What a nightmare :) > However we did begin to wonder if LD simply wasn't > catered for, as using it directly rather than via gcc > is very rare. In fact the partial link case is about the > only one we could think of, and we didn't think > that was commonly used outside of the kernel build. Linking objects into a new object using "ld -r" is very neat for keeping the constructor (not C++) calls alive. Previously, we've been using the ".a" versions and we had to manually specify the constructor methods on the command line, otherwise the stupid linker throws them out, but not with ".o" :-) -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
