gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnucap-devel] CMake


From: Felix Salfelder
Subject: [Gnucap-devel] CMake
Date: Tue, 17 Feb 2015 09:37:08 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Feb 17, 2015 at 12:32:23AM +0100, Guilherme Brondani Torri wrote:
> I was referring to the CMake issues.

oh sorry -- sure. it was late and i was tired.

> I think this is the thread:
> http://lists.gnu.org/archive/html/gnucap-devel/2014-05/msg00035.html

yes, in that thread i ended up with a poll on RPATH. which was
completely silly. it's pretty obvious how to deal with it [2]. in the
meantime, the autotools system does the right thing (involving one
workaround, see below) in all cases that i know of. it's worth a look
and imitate.

the most important bits from [2]:
- "Most of the time, you'll want to avoid setting RPATH and RUNPATH and
  just use libraries in your usual linking path."
  means as much as: don't use R*PATH for paths where the linker looks
  anyway. on linux, this is specified in /etc/ld.so.conf.
- (about plugins) "The relevant linker flags are -rpath and
  --enable-new-dtags. Without --enable-new-dtags, you'll just set the
  RPATH flag, which is probably not what you want."
  RPATH cannot be overriden, so we must not use it, otherwise plugins in
  userspace (somebodys home directory?) cannot be loaded.

> Basically it the same issue I reported earlier today.
> The dlopen tries to load the libgnucap-default-plugins but it is in
> different locations during build and after install.

with autotools i did not manage to interact with plugin runpaths for
libgnucap.so, hence i wrote a wrapper that governs the builddir, and
gets lost during install. this is ugly but implements the correct
behaviour. it would be nice if CMake was more flexible...

> [..]
> the absolute path to the libraries to avoid issues. Libraries are
> [..]

absolute paths are a no-go. this just reinvents $LD_LIBRARY_PATH and
friends. we should just use them the way we use $PATH. a system that
keeps you from doing stupid things will also keep you from doing clever
things.

> Is it acceptable to have two default search paths defined on the
> gnucap loader? For make and make install? Should it be defined
> externally somewhere or set with a command?

if you can switch RUNPATH for libgnucap.so during install, that would
solve a lot.

> (I just pushed another commit to my fix-osx branch to add an
> uninstall target to Cmake)

i'll have a look today.

thanks a lot.
felix

[2] http://blog.tremily.us/posts/rpath/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]