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 737702 - Use -R instead of -rpath when linking libtool libraries
Use -R instead of -rpath when linking libtool libraries
Status: RESOLVED FIXED
Product: gjs
Classification: Bindings
Component: general
unspecified
Other Mac OS
: Normal normal
: ---
Assigned To: gjs-maint
gjs-maint
Depends on:
Blocks:
 
 
Reported: 2014-10-01 07:45 UTC by Philip Chimento
Modified: 2016-01-25 04:35 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch to fix the problem (1.07 KB, patch)
2014-10-01 07:45 UTC, Philip Chimento 		none Details | Review
I've determined that the problem comes from passing -rpath to the linker (2.09 KB, patch)
2016-01-25 03:09 UTC, Philip Chimento 		none Details | Review
build: Only force shared libraries if necessary (2.09 KB, patch)
2016-01-25 03:10 UTC, Philip Chimento 		committed Details | Review

Description Philip Chimento 2014-10-01 07:45:04 UTC 
Created attachment 287499 [details] [review]
Patch to fix the problem

Libtool's runpath option is confusingly -R, not -rpath. On OSX the use of -rpath failed to build because ld complained about two -rpath options in one command line. If using -R, then libtool cleans that up.

I'd appreciate if this could be committed to the gnome-3-14 branch as well.
Comment 1 Giovanni Campagna 2014-10-06 19:44:02 UTC 
Review of attachment 287499 [details] [review]:

Looks good.
Comment 2 Philip Chimento 2014-10-06 20:03:33 UTC 
OK for me to commit to both master and gnome-3-14?
Comment 3 Philip Chimento 2014-11-26 21:28:37 UTC 
Committed to both master and gnome-3-14.
Comment 4 Giovanni Campagna 2014-12-21 17:56:49 UTC 
But it wasn't good: -rpath for libtool means something else: "the library will be eventually installed in ...", and it is used to force a shared library instead of a static one. It has nothing to do with the actual rpath.

I reverted the commit, the OS X problem will need a different fix.
Comment 5 Philip Chimento 2014-12-22 01:27:02 UTC 
OK, I see the problem. How old is that advice from libtool? Can't we just force a shared library using libtool's -shared option in LDFLAGS instead of -rpath?

(Documentation reference: http://www.gnu.org/software/libtool/manual/html_node/Link-mode.html#Link-mode)
Comment 6 Philip Chimento 2016-01-25 03:09:30 UTC 
Created attachment 319645 [details] [review]
I've determined that the problem comes from passing -rpath to the linker

when Automake is already passing it, i.e. with --enable-installed-tests.
This patch only adds -rpath /nowhere if running the tests uninstalled.

It works for me on both Fedora 22 and OS X.
Comment 7 Philip Chimento 2016-01-25 03:10:16 UTC 
Whoops, that was meant for a comment, not a commit message. Fixing...
Comment 8 Philip Chimento 2016-01-25 03:10:38 UTC 
Created attachment 319646 [details] [review]
build: Only force shared libraries if necessary

The libtool argument -rpath /nowhere is the (bizarrely) recommended way
to force generation of a shared library even if Automake thinks you
should not have a shared library. This happens when your library is part
of the check or noinst target.

We only need to force a shared library if --enable-installed-tests is not
given to configure. Normally the extra -rpath does not matter in the case
of --enable-installed tests, but OS X's linker chokes if a second -rpath
argument is given.

This change makes sure the -rpath argument is only added when necessary.
Comment 9 Colin Walters 2016-01-25 03:16:37 UTC 
Review of attachment 319646 [details] [review]:

LGTM, thanks.
Comment 10 Philip Chimento 2016-01-25 04:35:09 UTC 
Attachment 319646 [details] pushed as a3b2207 - build: Only force shared libraries if necessary