unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Andreas Enge <andreas@enge.fr>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] build: cmake: Add input libraries to the rpath.
Date: Fri, 25 Apr 2014 13:31:02 +0200	[thread overview]
Message-ID: <87d2g5bq89.fsf@gnu.org> (raw)
In-Reply-To: <20140425071346.GA12585@debian> (Andreas Enge's message of "Fri, 25 Apr 2014 09:13:46 +0200")

Andreas Enge <andreas@enge.fr> skribis:

> In a discussion we had yesterday, Ludovic mentioned the need to pass a
> special flag to the cmake configure phase to modify the rpath of installed
> libraries, as done for the package slim. I then noticed I needed the same
> flag for clucene. The attached patch applies it globally in the cmake build
> system. This should also avoid the need for the add-libs-to-runpath phase
> in the gmsh package Eric Bavier posted yesterday.
>
> In slim, there is another flag:
>     ;; Don't build libslim.so, because then the build
>     ;; system is unable to set the right RUNPATH on the
>     ;; 'slim' binary.
>     "-DBUILD_SHARED_LIBS=OFF"
> I wonder if we should instead use another of the rpath setting variables
> given at
>    http://www.cmake.org/Wiki/CMake_RPATH_handling

Yes, that would be better.

> Moreover, libclucene-core.so needs to be linked to libclucene-shared.so.1
> from the same package. Here we usually employ patchelf, but maybe yet again
> a cmake flag could solve the problem directly.
>
> Comments from cmake specialists are very welcome!

[...]

> --- a/guix/build/cmake-build-system.scm
> +++ b/guix/build/cmake-build-system.scm
> @@ -48,6 +48,7 @@
>  
>      (let ((args `(,srcdir
>                    ,(string-append "-DCMAKE_INSTALL_PREFIX=" out)
> +                  "-DCMAKE_SKIP_BUILD_RPATH=ON"
>                    ,@configure-flags)))

So that means that CMake won’t pass -rpath flag when building, nor when
installing, right?  (Which may be compensated by what ld-wrapper does.)

Does it actually work with the packages you looked at, and for SLiM and
and libssh (try building guile-ssh to check)?

At any rate, that’ll deserve a comment because even after discussing it
I still have to think twice what the option really does.  :-)

Thanks,
Ludo’.

  reply	other threads:[~2014-04-25 11:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-25  7:13 [PATCH] build: cmake: Add input libraries to the rpath Andreas Enge
2014-04-25 11:31 ` Ludovic Courtès [this message]
2014-04-25 17:44 ` Eric Bavier
2014-04-26  8:52   ` Ludovic Courtès
2014-04-27  8:59   ` Andreas Enge
2014-04-27  9:57     ` Andreas Enge
2014-04-27 17:17       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d2g5bq89.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).