Bug #74

Default build from source breaks at the link stage

Added by Firstname Lastname 11 months ago. Updated 11 months ago.

Status:Closed Start date:06/23/2012
Priority:Normal Due 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

Updated by Hiroyuki Yamamoto 11 months 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.

Updated by Firstname Lastname 11 months 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.

Updated by Hiroyuki Yamamoto 11 months ago

  • Status changed from New to Resolved

Possibly fixed at 3.2rc.

Updated by Firstname Lastname 11 months ago

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

Updated by Hiroyuki Yamamoto 11 months ago

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

Also available in: Atom PDF