GNOME Bugzilla – Bug 787578
Can't compile gnome-builder if gdlib installed
Last modified: 2017-11-19 21:58:10 UTC
Created attachment 359588 [details] build.log g-ir-scanner: link: cc -o /var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/tmp-introspectwnrq0_90/Ide-1.0 -O2 -pipe -march=native -finline-functions -fomit-frame-pointer /var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/tmp-introspectwnrq0_90/Ide-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -lgd -lide-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lgtksourceview-3.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpeas-1.0 -lgmodule-2.0 -lgirepository-1.0 -ldazzle-1.0 -ltemplate_glib-1.0 -lxml2 -ljson-glib-1.0 -ljsonrpc_glib-1.0 -lwebkit2gtk-4.0 -lsoup-2.4 -ljavascriptcoregtk-4.0 -lm -L/var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/libide -Wl,-rpath,/var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/libide -L/usr/lib64/ -Wl,-rpath,/usr/lib64/ -L/var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/subprojects/libgd/libgd -Wl,-rpath,/var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/subprojects/libgd/libgd -L/var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/libide -Wl,-rpath,/var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/libide -L/var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/subprojects/libgd/libgd -Wl,-rpath,/var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/subprojects/libgd/libgd -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -Wl,-O1 -Wl,--as-needed /var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/libide/libide-1.0.so: undefined reference to `gd_tagged_entry_tag_set_style' /var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/libide/libide-1.0.so: undefined reference to `gd_tagged_entry_tag_set_label' /var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/libide/libide-1.0.so: undefined reference to `gd_tagged_entry_add_tag' /var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/libide/libide-1.0.so: undefined reference to `gd_tagged_entry_tag_new' /var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/libide/libide-1.0.so: undefined reference to `gd_tagged_entry_get_type' /var/tmp/portage/gnome-extra/gnome-builder-3.26.0/work/gnome-builder-3.26.0-build/libide/libide-1.0.so: undefined reference to `gd_tagged_entry_remove_tag' collect2: error: ld returned 1 exit status
I wonder if it is related to https://github.com/mesonbuild/meson/issues/1181 Our build congiguration for this isn't that fancy: https://git.gnome.org/browse/gnome-builder/tree/libide/meson.build#n774
Can you update your meson version to 0.42 and see if this is resovled? (You'll need to wipe your old build directory and recreate it).
I compiled gnome-shell with meson-0.42.0
*I compiled gnome and gnome-builder with meson-0.42.0
After remove system gd gnome-builder compile successful
Same problem with meson-0.42.1
libgd certainly isn't intended to be installed system-wide. It's a library meant to be cribbed by projects and statically linked. That said, there might be something that meson can do to help avoid the linker ordering issue, but I'm not sure that is something we can do much about on our side.
(In reply to Christian Hergert from comment #7) > libgd certainly isn't intended to be installed system-wide. It's a library > meant to be cribbed by projects and statically linked. > > That said, there might be something that meson can do to help avoid the > linker ordering issue, but I'm not sure that is something we can do much > about on our side. FWIW this is not about libgd the copylib but libgd the graphics library: https://libgd.github.io/ The reason why only Gentoo users see this is because no other distro installs development files by default.
> The reason why only Gentoo users see this is because no other distro > installs development files by default. We see the same issue on BSDs. Building gnome-builder does not work if the libgd graphic library is installed on the system.
Created attachment 363278 [details] [review] build: tweak dependency ordering In hopes that we increase our chances for proper paths into the private directory before loading libgd from the public library paths loaded from system libraries.
Comment on attachment 363278 [details] [review] build: tweak dependency ordering If meson is altering the order, there isn't much more we can do. But this will put libgd first in the list in hopes that we get it before the directories containing other libraries are loaded with -L. Attachment 363278 [details] pushed as 134b52a - build: tweak dependency ordering
Thanks for the patch Christian, unfortunately it doesn't seem to help :-/
As a workaround for the time being, prepending: -L${PATH_TO_BUILDIR}/subprojects/libgd/libgd to LDFLAGS seems to work fine.
Created attachment 364014 [details] [review] build: vendor GdTaggedEntry as IdeTaggedEntry We were having a number of issues compiling on systems where libgd is installed (and not the, typically static, libgd from GNOME). We only use one widget from there anyway, which doesn't really change. So instead, we can just vendor it and namespace it into libide. This also reduces the number of private shared libraries we load by one. Namespace was changed, and availability macros added using the tool at https://github.com/chergert/add-availability-macros.
This should work around the issue with libgd by just vendoring the one thing we use into libide. Attachment 364014 [details] pushed as d5b8677 - build: vendor GdTaggedEntry as IdeTaggedEntry