- Mail original -
> De: "Alexander Neundorf"
> À: "Franck Houssen"
> Cc: cmake@cmake.org
> Envoyé: Jeudi 4 Janvier 2018 22:04:02
> Objet: Re: [CMake] RPATH for pkg-config
>
> On 2018 M01 4, Thu 10:06:26 CET Franck Houssen wrote:
> ...
> &
t;CMake Mail List"
>
> Envoyé: Jeudi 4 Janvier 2018 21:49:05
> Objet: Re: [CMake] RPATH for pkg-config
> This is mostly an ordering problem -- you need to setup everything before
> calling add_executable. Also, I was wrong about using ';' in RPATH
> variables. T
On 2018 M01 4, Thu 10:06:26 CET Franck Houssen wrote:
...
> ...
> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> foreach(lib ${PETSc_LDFLAGS})
> target_link_libraries(main PUBLIC ${lib})
> message("target_link_libraries - lib is ${lib}")
> endforeach(lib)
>
> foreach(dir ${PET
y if it's not a system
>> directory
>> LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
>> "${CMAKE_INSTALL_PREFIX}/lib" isSystemDir)
>> IF("${isSystemDir}" STREQUAL "-1")
>>SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/
message("link_directories - dir is ${dir}")
> set(CMAKE_INSTALL_RPATH "${dir};${CMAKE_INSTALL_RPATH}")
> endforeach(dir)
> message("CMAKE_INSTALL_RPATH: ${CMAKE_INSTALL_RPATH}")
>
> include(CTest)
> enable_testing()
> add_test(NAME main CO
AKE_INSTALL_RPATH: ${CMAKE_INSTALL_RPATH}")
include(CTest)
enable_testing()
add_test(NAME main COMMAND "mpirun -n 2 ./main" WORKING_DIRECTORY
"${CMAKE_CURRENT_BINARY_DIR}")
- Mail original -
> De: "Don Hinton"
> À: "Franck Houssen"
> Cc: &q
#x27;;' instead as a separator. Or use 'list(APPEND
...), to add to a list.
On Thu, Jan 4, 2018 at 8:34 AM, Franck Houssen
wrote:
> nope !... :D
>
> --
>
> *De: *"Don Hinton"
> *À: *"Franck Houssen"
> *Cc: *"
nope !... :D
- Mail original -
> De: "Don Hinton"
> À: "Franck Houssen"
> Cc: "Andreas Naumann" , cmake@cmake.org
> Envoyé: Jeudi 4 Janvier 2018 16:52:53
> Objet: Re: [CMake] RPATH for pkg-config
> On Thu, Jan 4, 2018 at 3:57 AM Fr
On Thu, Jan 4, 2018 at 3:57 AM Franck Houssen
wrote:
> --
>
> *De: *"Don Hinton"
> *À: *"Franck Houssen"
> *Cc: *"Andreas Naumann" , cmake@cmake.org
> *Envoyé: *Jeudi 4 Janvier 2018 10:43:28
>
>
> *Obj
- Mail original -
> De: "Don Hinton"
> À: "Franck Houssen"
> Cc: "Andreas Naumann" , cmake@cmake.org
> Envoyé: Jeudi 4 Janvier 2018 10:43:28
> Objet: Re: [CMake] RPATH for pkg-config
> The cmake rpath settings handle build/install direct
The cmake rpath settings handle build/install directories more or less
automatically, but you need to add a completely different path.
Try adding the additional path (pretty much every -L you added) to
CMAKE_INSTALL_RPATH, and set CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE.
Then run cmake with the ‘-v
My understanding is that you need a local copy of FindPETSc.cmake: if this
changes, you don't know it.
That's why I tried to go with the pc file.
- Mail original -
> De: "Andreas Naumann"
> À: cmake@cmake.org
> Envoyé: Mercredi 3 Janvier 2018 21:41:51
>
- Mail original -
> De: "Alexander Neundorf"
> À: cmake@cmake.org
> Envoyé: Mercredi 3 Janvier 2018 21:35:02
> Objet: Re: [CMake] RPATH for pkg-config
>
> On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
> > Hello,
> >
> > How to ask cm
What about using a FindPETSC-Module? Some hints are
*http://jacobmerson.com/2016/01/17/cmake-petsc2.html
*http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
Regards,
Andreas
Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
> Hello,
>
> How to ask cmake to add a library path (coming from pc file) to rpath ?
>
> I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but still not
> working. Can somebody help ?
> >> more main.cpp
>
> #include
>
> int main(i
Hello,
How to ask cmake to add a library path (coming from pc file) to rpath ?
I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but still not
working. Can somebody help ?
>> more main.cpp
#include
int main(int argc, char ** argv) {
PetscInitialize(&argc, &argv, NULL, "");
Pe
I’m wondering if anyone knows the details of rpath linker args. In particular,
I have two paths in my CMAKE_BUILD_RPATH. On macOS, I end-up with something
like this:
…. -Wl,rpath=/path/number/one -Wl,rpath=/path/number/two ….
and on linux with the same CMakeLists.txt file, I get:
…. -Wl,rpath
>> > If I understand things correctly, pkg-config does not return the
>> > RPATH-arguments necessary to link with. IOW, if used in a GNU
>> > Makefile you would also need to add these by yourself, right? So
>> > your problem is not a cmake-problem.
>> IMHO it's not fair to say - if it's not support
On Wed, 17 May 2017 17:13:13 -0700
Pawel Veselov wrote:
> On Wed, May 17, 2017 at 2:55 AM, Patrick Boettcher
> > My reason of preferring pkg-config is
> because it may have all
> >> other kind of stuff in it that the maintainer thought is necessary.
> >> I'd imagine some .pc files export a boatlo
On Wed, May 17, 2017 at 2:55 AM, Patrick Boettcher
> My reason of preferring pkg-config is
because it may have all
>> other kind of stuff in it that the maintainer thought is necessary.
>> I'd imagine some .pc files export a boatload of flags for all 3
>> stages, and I rather not ignored them. It i
On Tue, 16 May 2017 12:32:11 -0700
Pawel Veselov wrote:
> > I was once in a situation where I could have used pkg-config with a
> > custom path to have pkg-config look for the .pc-file. I then
> > switched to find_library with the custom-path slightly adapted and
> > it worked at least as good as
On Tue, May 16, 2017 at 12:09 PM, Patrick Boettcher
wrote:
> On Tue, 16 May 2017 11:50:47 -0700
> Pawel Veselov wrote:
>
>> >> I'm trying to make CMake add to the linker RPATH automatically.
>> >> There is a library that is installed in a non-default location.
>> >> I'm discovering the library us
On Tue, 16 May 2017 11:50:47 -0700
Pawel Veselov wrote:
> >> I'm trying to make CMake add to the linker RPATH automatically.
> >> There is a library that is installed in a non-default location.
> >> I'm discovering the library using PkgConfig (custom
> >> CMAKE_APPBUNDLE_PATH) and add the library
>> I'm trying to make CMake add to the linker RPATH automatically.
>> There is a library that is installed in a non-default location.
>> I'm discovering the library using PkgConfig (custom
>> CMAKE_APPBUNDLE_PATH) and add the library build options to the
>> LINK_FLAGS (using set_property).
> Instea
On Mon, 15 May 2017 13:32:15 -0700
Pawel Veselov wrote:
> Hello.
>
> I'm trying to make CMake add to the linker RPATH automatically.
> There is a library that is installed in a non-default location.
> I'm discovering the library using PkgConfig (custom
> CMAKE_APPBUNDLE_PATH) and add the library
Hello.
I'm trying to make CMake add to the linker RPATH automatically.
There is a library that is installed in a non-default location.
I'm discovering the library using PkgConfig (custom CMAKE_APPBUNDLE_PATH)
and add the library build options to the LINK_FLAGS (using set_property).
I then set INS
On 02/28/2017 08:22 AM, Brad King wrote:
>> 2) Make sure, in case lib32 is a symlink, to follow the symlink.
>
> I was thinking the same thing. The lib => lib32 search path conversion
> should just be skipped if lib32 is a symlink back to lib.
For reference, I opened an issue for this part of th
On Tue, 2017-02-28 at 08:22 -0500, Brad King wrote:
> On 02/28/2017 05:25 AM, Jörg Krause wrote:
> > Buildroot does not have any problems with searching for libraries
> > in
> > lib32. It does have a problem with having a host rpath used for
> > linking
> > with libraries.
>
> From your descriptio
On 02/27/2017 08:11 PM, Ray Donnelly wrote:
>> CMake passes the host rpath to the linker
>
> CMake does this because it isn't *asking* the linker, it's making
> assumptions instead (and adding some predefined values like
> `/usr/lib32`). If we just ask the linker instead then everything
> should w
On 02/28/2017 05:25 AM, Jörg Krause wrote:
> Buildroot does not have any problems with searching for libraries in
> lib32. It does have a problem with having a host rpath used for linking
> with libraries.
From your description we are not adding a host rpath. It's coming from
/sysroot/usr/lib32 w
On Mon, 2017-02-27 at 16:33 -0500, Brad King wrote:
> On 02/27/2017 03:50 PM, Jörg Krause wrote:
> > The problem is...
>
> Thanks. I've opened an issue for this here:
>
> https://gitlab.kitware.com/cmake/cmake/issues/16682
Great!
> > > These are set on by default in `Modules/Platform/UnixPath
On Mon, Feb 27, 2017 at 9:39 PM, Brad King wrote:
> On 02/27/2017 03:54 PM, Ray Donnelly wrote:
>> This is why my PR asks the linker that the compiler will use for the
>> actual list of implicit link dirs. I'm sorry I've not had time to
>> write up a clear explanation yet.
>
> IIUC your case is th
On 02/27/2017 03:54 PM, Ray Donnelly wrote:
> This is why my PR asks the linker that the compiler will use for the
> actual list of implicit link dirs. I'm sorry I've not had time to
> write up a clear explanation yet.
IIUC your case is the opposite of that under discussion in the rest
of this thr
On 02/27/2017 03:50 PM, Jörg Krause wrote:
> The problem is...
Thanks. I've opened an issue for this here:
https://gitlab.kitware.com/cmake/cmake/issues/16682
>> These are set on by default in `Modules/Platform/UnixPaths.cmake` but
>> disabled on Debian by `Modules/Platform/Linux.cmake` except
On Mon, Feb 27, 2017 at 8:50 PM, Jörg Krause
wrote:
> Hi Brad,
>
> On Mon, 2017-02-27 at 11:43 -0500, Brad King wrote:
>> On 02/07/2017 04:40 AM, Ray Donnelly wrote:
>> > > > I have a PR that asks the linker (via the compiler) what its
>> > > > implicit
>> > > > search directories are instead.
>>
Hi Brad,
On Mon, 2017-02-27 at 11:43 -0500, Brad King wrote:
> On 02/07/2017 04:40 AM, Ray Donnelly wrote:
> > > > I have a PR that asks the linker (via the compiler) what its
> > > > implicit
> > > > search directories are instead.
> > > >
> > > > It is the right way to do it IMHO, but I need to
On 02/07/2017 04:40 AM, Ray Donnelly wrote:
>>> I have a PR that asks the linker (via the compiler) what its implicit
>>> search directories are instead.
>>>
>>> It is the right way to do it IMHO, but I need to find time to finish
>>> it unfortunately.
>>
>> Do you have a link to the PR?
>
> The PR
The PR Is closed pending me writing a test-case, but I just now
updated to the my latest version and rebased on top of master:
https://gitlab.kitware.com/mingwandroid/cmake/commit/b937ff949d8fdaab7d8b812d503f67f8cef69532
Cheers.
On Tue, Feb 7, 2017 at 8:37 AM, wrote:
> Hi Ray,
>
> Am 2017-02
Hi Ray,
Am 2017-02-07 02:46, schrieb Ray Donnelly:
I have a PR that asks the linker (via the compiler) what its implicit
search directories are instead.
It is the right way to do it IMHO, but I need to find time to finish
it unfortunately.
Do you have a link to the PR?
On Feb 6, 2017 11:16
I have a PR that asks the linker (via the compiler) what its implicit
search directories are instead.
It is the right way to do it IMHO, but I need to find time to finish it
unfortunately.
On Feb 6, 2017 11:16 PM, "Jörg Krause" wrote:
> On Mon, 2017-02-06 at 22:22 +0100, Jörg Krause wrote:
> >
On Mon, 2017-02-06 at 22:22 +0100, Jörg Krause wrote:
> Hi,
>
> On Sun, 2017-02-05 at 23:03 +0100, Jörg Krause wrote:
> > Hi,
> >
> > when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
> > environment, CMake passes the host rpath to the linker:
> >
> > """ CMakeOutput.log
> >
> >
Hi,
On Sun, 2017-02-05 at 23:03 +0100, Jörg Krause wrote:
> Hi,
>
> when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
> environment, CMake passes the host rpath to the linker:
>
> """ CMakeOutput.log
>
> /home/joerg/host/usr/bin/i586-linux-gcc
> --sysroot=/home/joerg/host/usr/i
Hi,
when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
environment, CMake passes the host rpath to the linker:
""" CMakeOutput.log
/home/joerg/host/usr/bin/i586-linux-gcc
--sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D
I'm having an issue building a child project through my master project
where the child project is an "External Project" which is automatically
built using CMake's "ExternalProject_Add" feature if it is not found (using
"FindChildProject.cmake"). The error message happens during installing of
the ch
Can anyone confirm whether invoking cpack directly rather than "cmake
--build . --target package" would still give the same RPATH handling?
Specifically, the install/packaging step rewrites the rpaths in at least
some cases (e.g. see the docs for CMAKE_BUILD_WITH_INSTALL_RPATH) and I'm
wanting to e
Hi Folks,
I'm linking a target against libraries from an imported package. The
resulting linker invocation then will link against the libs using the full
path, but it will not set the RPATH accordingly. How to I enable RPATH?
I suspect the reason is, that, in the package's Exports.cmake, it sets
Recently, during our install phase, we get the following error message
CMake Error at CoreApp/CLI/cmake_install.cmake:45 (file):
file RPATH_CHANGE could not write new RPATH:
$ORIGIN/lib
to the file:
/home/marc_local/views/.branch/bin/dbg/Install/./.BluePearlCLI
No valid ELF RPATH
In cmake 2.6, I could do something kind of bogus like this:
get_filename_component(MY_COMPILER_PREFIX ${CMAKE_C_COMPILER} PATH)
set(MY_RPATH ${MY_COMPILER_PREFIX}/../CentOS-5.7/x86_64/lib)
link_directories(${MY_RPATH})
set(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
set(CMAKE_INSTALL_RPATH_USE
On Wednesday 11 September 2013, Clinton Stimpson wrote:
> On Tuesday, September 10, 2013 04:03:08 PM Dan Kegel wrote:
> > On Tue, Sep 10, 2013 at 10:43 AM, Clinton Stimpson
>
> wrote:
> > > Using the INSTALL_RPATH property doesn't work correctly unless you use
> > > CMake 2.8.12 with the target p
On Tuesday, September 10, 2013 09:43:59 AM Dan Kegel wrote:
> Howdy!
> I'm using 2.8.9 installed on MacOSX using macports, and am trying to get
> a minimal example of rpath working.
>
> Doing it without cmake works fine; see
> http://kegel.com/macosx/rpath/demo.txt
> which just does
> gcc -sha
On Tue, Sep 10, 2013 at 10:43 AM, Clinton Stimpson wrote:
> Using the INSTALL_RPATH property doesn't work correctly unless you use CMake
> 2.8.12 with the target property MACOSX_RPATH=1.
Done, example http://kegel.com/macosx/rpath/demo2/CMakeLists.txt
> If you want it to work with the older vers
On Tuesday, September 10, 2013 04:03:08 PM Dan Kegel wrote:
> On Tue, Sep 10, 2013 at 10:43 AM, Clinton Stimpson
wrote:
> > Using the INSTALL_RPATH property doesn't work correctly unless you use
> > CMake 2.8.12 with the target property MACOSX_RPATH=1.
>
> Done, example http://kegel.com/macosx/r
All is well. I updated my minimal examples showing how to do it in
various worlds.
http://kegel.com/macosx/rpath/demo1/ - commandline gcc example
http://kegel.com/macosx/rpath/demo2/ - cmake 2.8.12 example
http://kegel.com/macosx/rpath/demo3/ - cmake 2.8.9 example
Someday I'll add a cross-pla
I had thought, from reading
http://www.kitware.com/blog/home/post/510
and the doc, that the only thing being added in 2.8.12 was
the MACOSX_RPATH variable.
I guess this is a documentation failure, and/or an example
of cmake's tendancy to accept and ignore garbage input.
cmake, bless its useful li
The clue is probably that RPATH support on the Mac is "behind" and has
only recently been merged to master... -- although you didn't say
exactly how much you'd be willing to pay for a clue... :-)
Here are some related commits:
http://cmake.org/gitweb?p=cmake.git&a=search&h=refs%2Fheads%2F
Howdy!
I'm using 2.8.9 installed on MacOSX using macports, and am trying to get
a minimal example of rpath working.
Doing it without cmake works fine; see
http://kegel.com/macosx/rpath/demo.txt
which just does
gcc -shared foo.c -install_name @rpath/foo.so -o foo.so
gcc -Wl,-rpath $OTHERDIR x
Hello,
On Sat, Aug 25, 2012 at 7:03 PM, Eric Noulard wrote:
> 2012/8/25 Martin Vogt :
> The fact that libdummy.so is in the rpath of one of the library the executable
> is linked against is just a coincidence or did I miss something?
I think, its the correct behavior for libmyopen not to open li
2012/8/25 Martin Vogt :
> Hello,
>
> I have a library "A", which dlopens another library "B".
>
> But this does not work with cmake under the following circumstances:
>
> - in tree build
> - library in another directory
>
> I have attached an example for the behaviour.
>
> The reason for this is, t
This doesn't look like a cmake bug to me.
Someone tried to "fix" dlopen() for this case you are demonstrating, when the
--enable-new-dtags linker flag is used.
http://sources.redhat.com/ml/libc-hacker/2002-10/msg00048.html
But the patch was rejected because it was by design.
http://sourceware.or
Hello,
I have a library "A", which dlopens another library "B".
But this does not work with cmake under the following circumstances:
- in tree build
- library in another directory
I have attached an example for the behaviour.
The reason for this is, that cmake does not set the RPATH in library
You can find a detailed description of RPath and CMake here:
http://www.cmake.org/Wiki/CMake_RPATH_handling
Greetings
Micha
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the
Hello,
I have a question about cmake with makefiles and g++ on linux:
I have a single executable, consisting out of static libraries built by
cmake. Now one of the static libraries needs a shared library which is
not compiled by cmake but precompiled. I can link the one static lib
with the sha
On Friday 19 August 2011, Michael Hertling wrote:
> On 08/17/2011 10:03 PM, Knox, Kent wrote:
> > Yes, that's right. I'm currently using cmake with RPATH, but from what
> > I've been reading the RUNPATH header is now the more preferred approach.
> > If the user does not set LD_LIBRARY_PATH, the R
itly, in particular as ld does not provide an
immediate option to set this tag, AFAIK. Also, there's no need to
bother with chrpath/patchelf in a pre- or post-install manner.
'hope that helps.
Regards,
Michael
> -Original Message-----
> From: David Cole [mailto:david.c...@kit
7;s, but I'm not quite sure
how to write this in CMake yet. Wanted to check first if CMake had
undocumented or planned settings first.
Kent
-Original Message-
From: David Cole [mailto:david.c...@kitware.com]
Sent: Wednesday, August 17, 2011 2:13 PM
To: Knox, Kent
Cc: cmake@cmake
RUNPATH?
>
> -Original Message-
> From: David Cole [mailto:david.c...@kitware.com]
> Sent: Wednesday, August 17, 2011 1:57 PM
> To: Knox, Kent
> Cc: cmake@cmake.org
> Subject: Re: [CMake] RPATH/RUNPATH
>
> You can use CMake's RPATH related properties to put a path containi
Any comments on CMake support or planned support for RUNPATH?
-Original Message-
From: David Cole [mailto:david.c...@kitware.com]
Sent: Wednesday, August 17, 2011 1:57 PM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] RPATH/RUNPATH
You can use CMake's RPATH related prope
hough.
>
> -Original Message-
> From: David Cole [mailto:david.c...@kitware.com]
> Sent: Wednesday, August 17, 2011 11:37 AM
> To: Knox, Kent
> Cc: cmake@cmake.org
> Subject: Re: [CMake] RPATH/RUNPATH
>
> Perhaps try googling "cmake rpath" ... ?
>
>
: Wednesday, August 17, 2011 11:37 AM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] RPATH/RUNPATH
Perhaps try googling "cmake rpath" ... ?
http://www.cmake.org/Wiki/CMake_RPATH_handling
On Wed, Aug 17, 2011 at 12:03 PM, Knox, Kent wrote:
> Is there any support or planned sup
Perhaps try googling "cmake rpath" ... ?
http://www.cmake.org/Wiki/CMake_RPATH_handling
On Wed, Aug 17, 2011 at 12:03 PM, Knox, Kent wrote:
> Is there any support or planned support in CMake for RUNPATH? On a related
> note, is it possible for CMake to set the RPATH/RUNPA
Is there any support or planned support in CMake for RUNPATH? On a related
note, is it possible for CMake to set the RPATH/RUNPATH using $ORIGIN on 'make
install'? This way the install directory can be self-referential and moved as
a unit around the filesystem?
Kent
_
Hi,
Yes I have used the references you send me i.e. the link to the QtTest project.
This project is nevertheless simpler than mine since only an
executable is generated - no libraries (excepted those taken from Qt).
If my understanding is correct - FIXUP_BUNDLE shall be used after the
bundle is c
Use the "SHARED" library type for your shared library and "MODULE" for your
plugin.
Have you downloaded the Qt example from the Wiki? It shows what you need to do.
The terse summary of how some of us do it is this:
Write a configurable *.cmake.in file that gets configured at cmake time. An
ins
Hi Mike
Thanks for this very helpful answer.
I am nevertheless still facing few problems. My project contains:
- a shared library
- an executable using the shared lib
- a plugin lib (loaded using dylib)
I have modified my exec target to be
ADD_EXECUTABLE(main MACOSX_BUNDLE main.cpp sub.cpp
You need to process your executable with "install_name_tool" either manually or
using the "BundleUtilities" functionality built into CMake. Note that there is
a bug in the current CMake 2.8.4 that will NOT allow bundleUtilities to work on
a command line type app. Your app MUST be in a .app bundl
Dear all
Let's phrase it differently. Does CMake supports RPATH on the Mac platform ?
grep -i rpath /Applications/CMake\
2.8-4.app/Contents/share/cmake-2.8/Modules/Platform/* does not show
anything related to Darwin.
CMAKE_SHARED_LIBRARY_RUNTIME_C[X]*_FLAG does not seem to define on Darwin ?
Am
Dear all
I have a project in which I would like to use rpath on Mac OS.
Everything is going fine if I am building everything manually (i.e.
without CMake)
With CMake all is fine for the libs between the build and the
installation, all libs are processed with install_name_tool.
But nothing is done
2010/11/2 Szilárd Páll :
> Hi,
>
> In order to be able to run binaries linked dynamically to some
> libraries from the same project the rpath in the build directory has
> to point to the lib directory in the build directory. However, this
> brakes CPack which seems to require the
> CMAKE_BUILD_WITH
Hi,
In order to be able to run binaries linked dynamically to some
libraries from the same project the rpath in the build directory has
to point to the lib directory in the build directory. However, this
brakes CPack which seems to require the
CMAKE_BUILD_WITH_INSTALL_RPATH set on to work flawless
bit disregarding apparent expectations of users
> installing from source to different prefix. Softened approach (backport from
> trunk) has not made to the archive yet.
>
> However, I still think that KDElibs should stick to cmake defaults with
> respect to RPATH settings giving
On 29.06.10 23:21:10, Alexander Neundorf wrote:
> On Monday 28 June 2010, Andreas Pakulat wrote:
> > On 28.06.10 08:44:35, Brad King wrote:
> > > Andreas Pakulat wrote:
> > > > On 26.06.10 13:26:29, Andreas Pakulat wrote:
> > > >> Ping? Any further ideas on this? Could someone at least point me to
On Monday 28 June 2010, Andreas Pakulat wrote:
> On 28.06.10 08:44:35, Brad King wrote:
> > Andreas Pakulat wrote:
> > > On 26.06.10 13:26:29, Andreas Pakulat wrote:
> > >> Ping? Any further ideas on this? Could someone at least point me to
> > >> the source code in cmake that decides wether to add
On 28.06.10 08:44:35, Brad King wrote:
> Andreas Pakulat wrote:
> > On 26.06.10 13:26:29, Andreas Pakulat wrote:
> >> Ping? Any further ideas on this? Could someone at least point me to the
> >> source code in cmake that decides wether to add RPATH_REMOVE or
> >> RPATH_REPLACE to the cmake_install.
Andreas Pakulat wrote:
> On 26.06.10 13:26:29, Andreas Pakulat wrote:
>> Ping? Any further ideas on this? Could someone at least point me to the
>> source code in cmake that decides wether to add RPATH_REMOVE or
>> RPATH_REPLACE to the cmake_install.cmake file?
Look at "cmInstallTargetGenerator::A
On 26.06.10 13:26:29, Andreas Pakulat wrote:
> On 21.06.10 23:30:46, Andreas Pakulat wrote:
> > On 21.06.10 21:29:14, Alexander Neundorf wrote:
> > > On Sunday 20 June 2010, Andreas Pakulat wrote:
> > > > On 20.06.10 13:27:30, Thiago Macieira wrote:
> > > > > Em Domingo 20. Junho 2010, às 13.07.15,
For a config that uses
cmake ... \
-D CMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \
-D CMAKE_SKIP_BUILD_RPATH:BOOL=OFF \
-D CMAKE_INSTALL_RPATH:STRING=${libInstallPath} \
-D VTK_USE_RPATH \
...
This provides a build tree with rpath settings specific to the build path.
At the point of install
Iker Arizmendi wrote:
> I've run into some trouble with how CMake 2.4.2 (and perhaps
> later) handles the string "$ORIGIN" when it appears as part of
> an RPATH. I've gotten around the trouble (see below), but would
> appreciate any pointers on the correct way to use "$ORIGIN".
This will work with
O/H Alexander Neundorf ??:
On Wednesday 09 July 2008, Georgios Petasis wrote:
O/H Alexander Neundorf ??:
...
Which dirs are that exactly ?
Are they all outside the build dir ?
Alex
Two are in the build dir, but one is the perl library, in
/usr/lib/perl5/
2008/7/9 Georgios Petasis <[EMAIL PROTECTED]>:
Hi George,
Did you read this
http://www.cmake.org/Wiki/CMake_RPATH_handling
CMAKE_INSTALL_RPATH_USE_LINK_PATH
is not the sole CMake var to setup for proper RPATH
setting so may be you miss some.
--
Erk
__
On Wednesday 09 July 2008, Georgios Petasis wrote:
> O/H Alexander Neundorf ??:
...
> > Which dirs are that exactly ?
> > Are they all outside the build dir ?
> >
> > Alex
>
> Two are in the build dir, but one is the perl library, in
> /usr/lib/perl5/
I think that one should stay...
Could
O/H Alexander Neundorf ??:
On Wednesday 09 July 2008, Georgios Petasis wrote:
O/H Alexander Neundorf ??:
On Wednesday 09 July 2008, George Petasis wrote:
Hi all,
I am trying to build a shared library under linux, with
INSTALL_RPATH_USE_LINK_PATH ON. When the library is
On Wednesday 09 July 2008, Georgios Petasis wrote:
> O/H Alexander Neundorf ??:
> > On Wednesday 09 July 2008, George Petasis wrote:
> >> Hi all,
> >>
> >> I am trying to build a shared library under linux, with
> >> INSTALL_RPATH_USE_LINK_PATH ON. When the library is built,
> >> -Wl,-rpath,...
O/H Alexander Neundorf ??:
On Wednesday 09 July 2008, George Petasis wrote:
Hi all,
I am trying to build a shared library under linux, with
INSTALL_RPATH_USE_LINK_PATH ON. When the library is built, -Wl,-rpath,...
is added to the compiler flags. Also, I can see the rpath of the built wit
On Wednesday 09 July 2008, George Petasis wrote:
> Hi all,
>
> I am trying to build a shared library under linux, with
> INSTALL_RPATH_USE_LINK_PATH ON. When the library is built, -Wl,-rpath,...
> is added to the compiler flags. Also, I can see the rpath of the built with
> "readelf -d".
> But the
Hi all,
I am trying to build a shared library under linux, with
INSTALL_RPATH_USE_LINK_PATH ON. When the library is built, -Wl,-rpath,... is
added to the compiler flags. Also,
I can see the rpath of the built with "readelf -d".
But the installed shared library has no rpath, and "readelf -d" does
Iker Arizmendi wrote:
I've run into some trouble with how CMake 2.4.2 (and perhaps
later) handles the string "$ORIGIN" when it appears as part of
an RPATH. I've gotten around the trouble (see below), but would
appreciate any pointers on the correct way to use "$ORIGIN".
...
SET(CMAKE_INSTALL
I've run into some trouble with how CMake 2.4.2 (and perhaps
later) handles the string "$ORIGIN" when it appears as part of
an RPATH. I've gotten around the trouble (see below), but would
appreciate any pointers on the correct way to use "$ORIGIN".
Regards,
Iker
Briefly, the problem seems to be
On 2007-10-29 20:08-0400 Bill Hoffman wrote:
Alan W. Irwin wrote:
I don't have access to Cygwin myself, but I have recently been getting
PLplot feedback from one of our developers and also two of our more
experienced users for that platform. From their detailed "make" and "make
install" result
Alan W. Irwin wrote:
I don't have access to Cygwin myself, but I have recently been getting
PLplot feedback from one of our developers and also two of our more
experienced users for that platform. From their detailed "make" and "make
install" results it appears rpath is being completely
ignored
I don't have access to Cygwin myself, but I have recently been getting
PLplot feedback from one of our developers and also two of our more
experienced users for that platform. From their detailed "make" and "make
install" results it appears rpath is being completely
ignored both in the build tree
1 - 100 of 109 matches
Mail list logo
