Bob Jamison wrote:
And the link now looks like this.
g++ -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -o inkscape --export-dynamic main.o -Wl,--export-dynamic -Wl,-E -Wl,-rpath -Wl,/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE libinkpre.a application/libinkapp.a ui/dialog/libuidialog.a dialogs/libspdialogs.a trace/libtrace.a svg/libspsvg.a widgets/libspwidgets.a display/libspdisplay.a helper/libspchelp.a libcroco/libcroco.a libnrtype/libnrtype.a libnr/libnr.a livarot/libvarot.a ui/view/libuiview.a ui/libui.a ui/widget/libuiwidget.a extension/libextension.a extension/implementation/libimplementation.a extension/internal/libinternal.a extension/script/libscript.a xml/libspxml.a util/libinkutil.a io/libio.a inkjar/libinkjar.a libinkpost.a debug/libinkdebug.a -L/usr/local/lib ....blah....
This works, so I committed it. Let me know if I broke anything.
Is it maybe time to fix /src/Makefile.am and /src/Makefile_inserts? Since link-order will likely get worse in the future, how about this idea....
Instead of linking together the set of individual $inkscape_private_libs (and their link problems) with the client apps to make the executables, concatenate each of their libxxx_a_OBJECTS variables together to make a single libinkscape.a and libinkscape.so. Link -THAT- with the client apps (inkscape, inkview, etc)
Benefits:
o This will remove the link-order problem within Inkscape entirely.
o Since inkscape and inkview objects will no longer be almost duplicates of each other (if we link dynamically), binary packages will be smaller.
o We could finally export an Inkscape API for others who wish to use it.
o The individual small .a's are still available for testers.
This is just an idea. But remember that we have been using a monolithic libinkscape.a on Win32 for 18 months now. We have never had a link order problem with it, or duplicate symbols (except for when a test .cpp file has a main() in it). So we know that it would work.
Bob