Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 468522

Summary: x11-misc/notification-daemon-0.5.0: undefined reference to symbol 'g_module_symbol'
Product: Gentoo Linux Reporter: Ted Tanberry <ted.tanberry>
Component: [OLD] GNOMEAssignee: Freedesktop bugs <freedesktop-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: andrius
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 372079    
Attachments: notification-daemon-0.5.0-underlinking.patch

Description Ted Tanberry 2013-05-03 20:55:15 UTC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: engines.o: undefined reference to symbol 'g_module_symbol'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: note: 'g_module_symbol' is defined in DSO /usr/lib64/libgmodule-2.0.so.0 so try adding it to the linker command line
/usr/lib64/libgmodule-2.0.so.0: could not read symbols: Invalid operation

Your usual underlinking issue with binutils-2.23.2. I've fixed the build system as I don't want to use any >x11-misc/notification-daemon-0.5.0. As the change to configure.ac requires a run of autoreconf, I needed to add gnome-base/gnome-common to the DEPENDency list.

Reproducible: Always
Comment 1 Ted Tanberry 2013-05-03 20:56:02 UTC
--- /usr/portage/x11-misc/notification-daemon/notification-daemon-0.5.0.ebuild	2012-01-28 03:17:07.000000000 +0100
+++ /usr/local/portage/x11-misc/notification-daemon/notification-daemon-0.5.0.ebuild	2013-05-03 22:39:40.963048440 +0200
@@ -6,7 +6,7 @@
 GCONF_DEBUG=no
 GNOME2_LA_PUNT=yes
 
-inherit eutils gnome2
+inherit eutils gnome2 autotools
 
 DESCRIPTION="Notification daemon"
 HOMEPAGE="http://git.gnome.org/browse/notification-daemon/"
@@ -29,7 +29,8 @@
 	!x11-misc/qtnotifydaemon"
 DEPEND="${RDEPEND}
 	>=dev-util/intltool-0.40
-	>=sys-devel/gettext-0.14"
+	>=sys-devel/gettext-0.14
+	gnome-base/gnome-common"
 
 pkg_setup() {
 	DOCS="AUTHORS ChangeLog NEWS"
@@ -38,5 +39,8 @@
 
 src_prepare() {
 	epatch "${FILESDIR}"/${P}-libnotify-0.7.patch
-	gnome2_src_prepare
+	epatch "${FILESDIR}"/${P}-underlinking.patch
+
+	gnome2_omf_fix
+	eautoreconf
 }
Comment 2 Ted Tanberry 2013-05-03 20:56:41 UTC
Created attachment 347312 [details, diff]
notification-daemon-0.5.0-underlinking.patch
Comment 3 Oschtan 2013-09-25 21:10:31 UTC
Thx. It's work :-)
Comment 4 wrdyanf 2014-03-04 12:36:41 UTC
notification-daemon-0.5.0-underlinking.patch
don't work on ARM arch.

engines.o: undefined reference to symbol 'g_module_close'
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/../../../../armv7a-hardfloat-linux-gnueabi/bin/ld: note: 'g_module_close' is defined in DSO /usr/lib/libgmodule-2.0.so.0 so try adding it to the linker command line
/usr/lib/libgmodule-2.0.so.0: could not read symbols: Invalid operation
Comment 5 Samuli Suominen (RETIRED) gentoo-dev 2014-03-04 12:58:05 UTC
(In reply to wrdyanf from comment #4)
> notification-daemon-0.5.0-underlinking.patch
> don't work on ARM arch.
> 
> engines.o: undefined reference to symbol 'g_module_close'
> /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/../../../../armv7a-
> hardfloat-linux-gnueabi/bin/ld: note: 'g_module_close' is defined in DSO
> /usr/lib/libgmodule-2.0.so.0 so try adding it to the linker command line
> /usr/lib/libgmodule-2.0.so.0: could not read symbols: Invalid operation

that's quite an claim without an attached build.log. did you remember to run eautoreconf after patching configure.ac?
if it still doesn't work after eautoreconf, to generate new configure from the patched configure.ac, then attach build.log so we can figure out why
Comment 6 Andrius Štikonas 2014-06-01 21:07:59 UTC
The patch works on arm provided that inherit autotools is added.

Is there any reason why this is not committed to portage?
Comment 7 Samuli Suominen (RETIRED) gentoo-dev 2014-06-02 17:54:53 UTC
(In reply to Andrius Štikonas from comment #6)
> The patch works on arm provided that inherit autotools is added.
> 
> Is there any reason why this is not committed to portage?

no other reason that 0.5.0 is deprecated version, overshadowed by KEYWORDS of 0.7.x series, so most focus goes to the newer versions

0.5.0 is left behind because, in my opinion, upstream ruined the daemon in 0.7.x series :-)

applied the patch to portage now. sorry for delay.