After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 771206 - Linking failure on midipix with slibtool
Linking failure on midipix with slibtool
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: build
unspecified
Other Windows
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2016-09-10 19:11 UTC by foxyred333
Modified: 2018-05-24 19:05 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
slibtool PE linking patch (261 bytes, patch)
2016-09-10 19:29 UTC, foxyred333 		needs-work Details | Review
Updated linking patch (600 bytes, patch)
2017-08-22 11:13 UTC, foxyred333 		needs-work Details | Review

Description foxyred333 2016-09-10 19:11:39 UTC 
Compiling glib on midipix ( http://midipix.org ) fails to link gio because of missing symbols in inotify, at least 'g_queue_peek_head', on PE targets, you need the -lglib-2.0 _after_ -linotify


patch to fix the issue is adding 

libinotify_la_LIBADD = -L../../glib -lglib-2.0

to the end of gio/inotify/Makefile.am
Comment 1 foxyred333 2016-09-10 19:29:13 UTC 
Created attachment 335270 [details] [review]
slibtool PE linking patch
Comment 2 Emmanuele Bassi (:ebassi) 2017-08-22 09:36:32 UTC 
Building inotify on Windows is kind of broken; inotify is a Linux kernel interface.
Comment 3 Emmanuele Bassi (:ebassi) 2017-08-22 09:40:07 UTC 
Review of attachment 335270 [details] [review]:

Thanks for the patch.

Could you please re-submit a patch generated by `git format-patch`? It makes applying and preserving authorship trivial, and allows keeping a reference to this bug.

::: glib.orig/gio/inotify/Makefile.am
@@ +27,3 @@
 	-DG_DISABLE_DEPRECATED
 
+libinotify_la_LIBADD = -L../../glib -lglib-2.0

You probably want to use `-l$(top_builddir)/glib/libglib-2.0.la` instead of changing th linker path.
Comment 4 Emmanuele Bassi (:ebassi) 2017-08-22 09:40:09 UTC 
Review of attachment 335270 [details] [review]:

Thanks for the patch.

Could you please re-submit a patch generated by `git format-patch`? It makes applying and preserving authorship trivial, and allows keeping a reference to this bug.

::: glib.orig/gio/inotify/Makefile.am
@@ +27,3 @@
 	-DG_DISABLE_DEPRECATED
 
+libinotify_la_LIBADD = -L../../glib -lglib-2.0

You probably want to use `-l$(top_builddir)/glib/libglib-2.0.la` instead of changing th linker path.
Comment 5 foxyred333 2017-08-22 11:13:51 UTC 
Created attachment 358134 [details] [review]
Updated linking patch

Updated it to be in Makefile.am
Comment 6 Philip Withnall 2017-08-22 12:18:10 UTC 
Review of attachment 358134 [details] [review]:

::: gio/inotify/Makefile.am
@@ +27,3 @@
 	-DG_DISABLE_DEPRECATED
 
+libinotify_la_LIBADD = -L../../glib -lglib-2.0

As Emmanuele said:
> You probably want to use `-l$(top_builddir)/glib/libglib-2.0.la` instead of changing th linker path.
Comment 7 foxyred333 2017-08-22 13:14:45 UTC 
At least with slibtool; that doesn't work. I've tried it, nor do I see what's wrong with -L../../glib -lglib-2.0?
Comment 8 Philip Withnall 2017-09-11 09:49:00 UTC 
(In reply to foxyred333 from comment #7)
> what's wrong with -L../../glib -lglib-2.0?

The use of -L will affect the linker path so that ../../glib will be searched for all future -l arguments. This could result in subsequent -l arguments being linked from the wrong place.
Comment 9 GNOME Infrastructure Team 2018-05-24 19:05:22 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1201.