Bug #74

Default build from source breaks at the link stage

Added by Firstname Lastname over 2 years ago. Updated about 2 years ago.

Status:ClosedStart date:06/23/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-Spent time:-
Target version:3.2

Description

Out of the box, Sylpheed does not build from source. Here is the proof-of-concept. When configuring and compiling Sylpheed with:

CFLAGS= CXXFLAGS= LDFLAGS= ./configure ; make

the build breaks at the linking stage with this error:

gcc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -o .libs/sylpheed main.o mainwindow.o folderview.o summaryview.o messageview.o headerview.o textview.o imageview.o mimeview.o quick_search.o query_search.o message_search.o colorlabel.o action.o compose.o gtkshruler.o menu.o stock_pixmap.o prefs_ui.o prefs_common_dialog.o prefs_filter.o prefs_filter_edit.o prefs_account_dialog.o prefs_folder_item.o prefs_display_items.o prefs_display_header.o prefs_customheader.o prefs_summary_column.o prefs_template.o prefs_actions.o prefs_search_folder.o prefs_toolbar.o account_dialog.o template.o addressbook.o addr_compl.o addritem.o addrcache.o addrbook.o addrindex.o mgutils.o vcard.o ldif.o importldif.o importcsv.o jpilot.o syldap.o editbook.o editgroup.o editaddress.o editvcard.o editjpilot.o editldap.o editldap_basedn.o addressadd.o filesel.o foldersel.o statusbar.o logwindow.o sourcewindow.o manage_window.o undo.o alertpanel.o inputdialog.o progressdialog.o subscribedialog.o about.o setup.o gtkutils.o send_message.o inc.o rpop3.o import.o export.o rfc2015.o passphrase.o select-keys.o sigstatus.o simple-gettext.o manual.o eggtrayicon.o trayicon.o printing.o sslmanager.o plugin_manager.o update_check.o quote_fmt_lex.o quote_fmt_parse.o sylpheed-marshal.o -pthread /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgio-2.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libpangocairo-1.0.so /usr/lib/libgdk_pixbuf-2.0.so /usr/lib/libcairo.so /usr/lib/libpango-1.0.so /usr/lib/libfreetype.so /usr/lib/libfontconfig.so /usr/lib/libgobject-2.0.so ./.libs/libsylpheed-plugin-0.so ../libsylph/.libs/libsylph-0.so -lnsl -lssl -lcrypto /usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so -Wl,--rpath -Wl,/usr/local/lib
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../i686-pc-linux-gnu/bin/ld: main.o: undefined reference to symbol 'g_module_name'
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../i686-pc-linux-gnu/bin/ld: note: 'g_module_name' is defined in DSO /usr/lib/../lib/libgmodule-2.0.so.0 so try adding it to the linker command line
/usr/lib/../lib/libgmodule-2.0.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make4: *** [sylpheed] Error 1

It is of course trivial to work around the problem locally, for example by setting LDFLAGS="-lgmodule-2.0". But with a new release imminent, this seems like a good point in time to fix the issue at the source.

History

#1 Updated by Hiroyuki Yamamoto about 2 years ago

What does 'pkg-config --libs gtk+-2.0' show on your system?
(and your OS and GTK+ version)

$ pkg-config --libs gtk+-2.0
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0

Here (Ubuntu 8.04, GTK+ 2.12.9), it adds -lgmodule-2.0, so it doesn't have the problem.

#2 Updated by Firstname Lastname about 2 years ago

'pkg-config --libs gtk+-2.0' shows:

-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0

The OS is 32-bit Linux (no distribution). All software versions are the most recent ones: Linux kernel 3.4.4, glibc 2.15, GTK+ 2.24.10, glib 2.32.3, and so on. Just for comparison: Other software that I compile (for example Gimp 2.8.0) knows the "-lgmodule-2.0" requirement by itself.

#3 Updated by Hiroyuki Yamamoto about 2 years ago

  • Status changed from New to Resolved

Possibly fixed at 3.2rc.

#4 Updated by Firstname Lastname about 2 years ago

Confirmed. 3.2rc builds (and works) without the LDFLAGS workaround. Thank you very much!

#5 Updated by Hiroyuki Yamamoto about 2 years ago

  • Status changed from Resolved to Closed
  • Target version set to 3.2

Also available in: Atom PDF