Somewhere deep inside either the libtool/autotools/automake toolchain, there appears to be a bug relating to generation of command-line references for three specific static libraries. Furthermore, this bug has apparently existed since at least 2004.
Here is a generated command line from an attempt to build the Subversion trunk version of Battle For Wesnoth: g++ -I ./sdl_ttf -I../intl -I../intl -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DHAVE_PYTHON -I/usr/include/python2.5 -DWESNOTH_PATH=\"/usr/local/share/wesnoth\" -DLOCALEDIR=\"translations\" -DHAS_RELATIVE_LOCALEDIR=1 -DFIFODIR=\"/usr/local/var/run/wesnothd\" -DHAVE_FRIBIDI -I/usr/include -O0 -DDEBUG -ggdb3 -W -Wall -ansi -DSVNREV=\"17696:17697\" -D_X11 -static -o wesnoth about.o actions.o ai.o ai_dfool.o ai_attack.o ai_move.o ai_python.o animated.o astarnode.o attack_prediction.o builder.o cavegen.o checksum.o clipboard.o color_range.o config_adapter.o construct_dialog.o cursor.o dialogs.o display.o events.o filechooser.o floating_textbox.o font.o game.o game_events.o gamestatus.o generic_event.o halo.o help.o hotkeys.o image.o intro.o key.o language.o leader_list.o loadscreen.o map_create.o map_label.o mapgen.o mapgen_dialog.o marked-up_text.o menu_events.o minimap.o mouse_events.o multiplayer.o multiplayer_ui.o multiplayer_wait.o multiplayer_connect.o multiplayer_create.o multiplayer_lobby.o network.o network_worker.o pathfind.o playcampaign.o play_controller.o playmp_controller.o playsingle_controller.o playturn.o preferences.o preferences_display.o publish_campaign.o replay.o replay_controller.o reports.o sdl_utils.o show_dialog.o sound.o soundsource.o statistics.o team.o theme.o titlescreen.o tooltips.o unit.o unit_abilities.o unit_animation.o unit_display.o unit_frame.o unit_map.o unit_types.o upload_log.o variable.o video.o serialization/binary_or_text.o serialization/parser.o serialization/string_utils.o widgets/button.o widgets/file_menu.o widgets/combo.o widgets/label.o widgets/menu.o widgets/menu_style.o widgets/progressbar.o widgets/scrollarea.o widgets/scrollbar.o widgets/scrollpane.o widgets/slider.o widgets/textbox.o widgets/widget.o sdl_ttf/SDL_ttf.o -L/home/esr/svn/wesnoth/src -lwesnoth-core /usr/lib/libSDL_image.a -lpng -L/usr/lib -L/usr/share/qt3/lib /usr/lib/libSDL_mixer.a /usr/lib/libvorbisfile.a /usr/lib/libvorbis.a /usr/lib/libogg.a /usr/lib/libsmpeg.a -lstdc++ -L/usr/X11R6/lib /usr/lib/libSDL_net.a -laudio -lXt -lXext /usr/lib/libSDL.a /usr/lib/libasound.a /usr/lib/libartsc.a /usr/lib/libgmodule-2.0.so /usr/lib/libgthread-2.0.so /usr/lib/libglib-2.0.so -lrt /usr/lib/libesd.a /usr/lib/libaudiofile.a /usr/lib/libdirectfb.a /usr/lib/libfusion.a /usr/lib/libdirect.a -ldl /usr/lib/libaa.a -lncurses -lslang -lm -lpthread -lpython2.5 /usr/lib/libfreetype.a -lz /usr/lib/libfribidi.a -lX11 /usr/bin/ld: attempted static link of dynamic object `/usr/lib/libgmodule-2.0.so' collect2: ld returned 1 exit status Now look at this posting from 2004, "Gtk2 build fails for static build": <http://www.ethereal.com/lists/ethereal-dev/200403/msg00715.html>. It includes the following line: gcc -DINET6 "-D_U_=__attribute__((unused))" -Wall -W -g -O2 -I/usr/local/include -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pcap -I/usr/heimdal/include -o ethereal -Wl,-static -static pcap-util-unix.o capture_stop_conditions.o cfile.o conditions.o disabled_protos.o pcap-util.o print.o ps.o range.o ringbuffer.o timestats.o version_info.o alert_box.o capture.o file.o filters.o proto_hier_stats.o summary.o -L/usr/local/lib wiretap/.libs/libwiretap.a gtk/libui.a epan/.libs/libethereal.a -L/usr/heimdal/lib -lcrypto -lpcap -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangox-1.0 -lpangoxft-1.0 -lpango-1.0 /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libgthread-2.0.so -lpthread /usr/lib/libglib-2.0.so -lz /usr/heimdal/lib/libkrb5.a /usr/heimdal/lib/libasn1.a /usr/heimdal/lib/libcom_err.a /usr/heimdal/lib/libdes.a /usr/heimdal/lib/libroken.a -ldb -lcrypt -lresolv /usr/bin/ld: cannot find -lgtk-x11-2.0 collect2: ld returned 1 exit status What these have in common is that for three modules, /usr/lib/libgmodule-2.0.so /usr/lib/libgthread-2.0.so /usr/lib/libglib-2.0.so something in the toolchain is generating references to dynamic libs when static libs were desired. I used grep-find to verify that neither these library names nor their stems occur anywhere in the Battle for Wesnoth source tree. You can check it out using these instructions: https://gna.org/svn/?group=wesnoth I used autogen.sh --enable-editor --enable-debug --enable-static --enable-display-revision --enable-tools followed by 'make' to produce the bug. Removing the --enable-static switch makes it go away. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> All governments are more or less combinations against the people. . .and as rulers have no more virtue than the ruled. . . the power of government can only be kept within its constituted bounds by the display of a power equal to itself, the collected sentiment of the people. -- Benjamin Franklin Bache, in a Phildelphia Aurora editorial 1794 _______________________________________________ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
