Bug in generation of static link lines for three specific libraries

[Eric S. Raymond]

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