GNOME Bugzilla – Bug 640303
Build failure with introspection enabled
Last modified: 2012-11-28 19:35:48 UTC
Using a minimal buildroot, I can build _without_ introspection. But building _with_ introspection causes it to fail like this: http://koji.fedoraproject.org/koji/getfile?taskID=2736175&name=build.log However, I discovered that if I install the non-introspection build of at-spi2-core into the build root, then the introspection build is able to succeed.
Oh, and it's in the build log, but this is 1.91.5.
The only reason that the Fedora package of at-spi2-core needs to BuildRequire itself is because the DIE_RPATH_DIE sed breaks libtool's ability to set any RPATHs, breaking the introspection build. Pretty much any other method of preventing rpath works better, e.g. based on a patch in the gnutls rpm: sed -i -e 's+sys_lib_dlsearch_path_spec="/lib /usr/lib+sys_lib_dlsearch_path_spec="/lib /usr/lib /lib64 /usr/lib64+' configure
That fix worked in Fedora
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports. IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
Created attachment 229956 [details] [review] build: Use gobject-introspection's Makefile instead of rolling our own Invoking the GI compiler through libtool would cause us to embed an RPATH in our binaries. -- (In reply to comment #2) > sed -i -e 's+sys_lib_dlsearch_path_spec="/lib > /usr/lib+sys_lib_dlsearch_path_spec="/lib /usr/lib /lib64 /usr/lib64+' > configure With this patch this isn't needed anymore.
Comment on attachment 229956 [details] [review] build: Use gobject-introspection's Makefile instead of rolling our own That looks fine. Thanks for the patch. Committed as 706692.
(In reply to comment #5) > Created an attachment (id=229956) [details] [review] > build: Use gobject-introspection's Makefile instead of rolling our own > > Invoking the GI compiler through libtool would cause us to embed an > RPATH in our binaries. > -- > The patch is probably fine and simplifies the Makefile.am, but of course Makefile.introspection will use libtool, so isn't related to this bug. This bug was entirely due to a using a bad method of RPATH removal in the Fedora package.
(In reply to comment #7) > The patch is probably fine and simplifies the Makefile.am, but of course > Makefile.introspection will use libtool, so isn't related to this bug. Yes, I think it does still use libtool somehow, I didn't dig that deep. What I know for a fact is that it's now possible to build with introspection without RPATH getting set on any binary and without using any RPATH removal methods. As such, the patch does indeed fix this bug.
If you run autoreconf on a Fedora system, you won't get any problems with RPATH because Fedora's libtool knows /usr/lib64 is a standard system library directory.
Ah, so that's why... Ok, thanks for telling.