Re: [Oorexx-devel] Question ad RPATH and MacOSX

[CV Bruce]

Thank you Tony and Enrico, this was something I was never able to get across.

Bruce
> On Jan 8, 2019, at 8:17 AM, Rony G. Flatscher  wrote:
> 
> Dear P.O.,
> 
> On 08.01.2019 16:24, P.O. Jonsson wrote:
>> I am not taking about the future, it is working NOW, without any 
>> modification besides the /bin
>> being in the path. NO NADA NIX modifications it works out of the box. Try it.
> 
> I believe you. :)
> 
>> A relocatable installation is desirable for other reasons, such as for 
>> creating an automated build
>> to ~/Applications, this is NOT possible today.
> 
> With Enricos definitions this has become possible. Just tested it a few 
> minutes ago successfully on
> MacOSX: moved the directories in ~/Applications/ooRexx.5.0.0 to ~/oha2/test 
> and successfully ran
> ooRexx from ~/oha2/test/bin and all of the sample programs there as well.
> 
> Cheers,
> 
> ---royn
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

[Rick McGuire]

If you are splitting things up into separate bin and lib directories, then
rexx.img needs to be co-located with librexxapi in order for the image file
to be located without it being on the path or the current directory.

Rick

On Tue, Jan 8, 2019 at 1:21 PM Rony G. Flatscher 
wrote:

> On 08.01.2019 19:15, Rony G. Flatscher wrote:
>
> While testing the standalone version on Linux, everything works out fine
> if issuing "rexx".
>
> Should have also mentioned: if putting the directory where rexx resides on
> to the path everything works as well.
>
> ---rony
>
>
> However, if invoking "rexx" with a fully qualified path like:
>
> ~/some/path/to-standalone/bin/rexx -e "parse version v; say v"
>
> an error "Logic error: no startup image" is raised and ooRexx gets aborted
> with a core dump. The libraries seem to be found.
>
> This is with r11665.
>
> ---rony
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

[Rony G. Flatscher]

On 08.01.2019 19:15, Rony G. Flatscher wrote:
>
> While testing the standalone version on Linux, everything works out fine if 
> issuing "rexx".
>
Should have also mentioned: if putting the directory where rexx resides on to 
the path everything
works as well.

---rony


> However, if invoking "rexx" with a fully qualified path like:
>
> ~/some/path/to-standalone/bin/rexx -e "parse version v; say v"
>
> an error "Logic error: no startup image" is raised and ooRexx gets aborted 
> with a core dump. The
> libraries seem to be found.
>
> This is with r11665.
>
> ---rony
>

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

[Rony G. Flatscher]

While testing the standalone version on Linux, everything works out fine if 
issuing "rexx".

However, if invoking "rexx" with a fully qualified path like:

~/some/path/to-standalone/bin/rexx -e "parse version v; say v"

an error "Logic error: no startup image" is raised and ooRexx gets aborted with 
a core dump. The
libraries seem to be found.

This is with r11665.

---rony

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Experimental "standalone" ooRexx interpreters

[Rony G. Flatscher]

Thanks to Enrico I was able to compile ooRexx with RPATH for MacOS and Linux 
successfully which
allows one to use those interpreters "standalone" like on a stick.

The experimental standalone ooRexx interpreters for Windows (32- and 64-bit), 
Linux (64-bit) and
MacOSX (64-bit) can be temporarily found on my Dropbox:
. 
This Dropbox directory
includes a directory named "CMakeList" which contains the file CMakeList.txt 
used to create the
MacOS and Linux versions.

To use, unzip/untar the archives and run "rexx.exe"/"rexx" from the "bin" 
directory.

---rony







___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Works and a question ad patches (Re: Question ad RPATH and MacOSX

[Rony G. Flatscher]

Dear P.O.,

On 08.01.2019 17:17, P.O. Jonsson wrote:
>> Am 08.01.2019 um 17:10 schrieb Rony G. Flatscher > >:
>>
>> O.K, Enrico's definitions work like a charm!
>> :)
>>
>> Ad multiple RPATHs: this works as well, one needs to separate the paths with 
>> a semi-colon, not with
>> a colon, though. However, thinking about it in the meantime, this would not 
>> be really helpful on
>> Unix based systems, although Windows users might be happy. :) The reason 
>> being that probably all
>> Unix-based builds will have a "bin" and a "lib" directory as siblings.
>>
>> Enrico's definitions should also work when installing to /usr/local as the 
>> executables land in
>> /usr/local/bin and locating their libs is "../lib" hence "/usr/local/lib“.
>
> I would strongly advice against installing directly into /usr/local/bin and 
> /usr/local/lib. Rather
> installing into /usr/local/oorexx5.0.0 (/bin,/lib etc) and Symlink all files 
> into /usr/local/bin
> etc. This is what all other installations do. Out of 215 files in /bin 211 
> are symlinks, not
> executables.

this depends on the installation philosophy. :)

Unlike you and René I use macports which installs into "/opt/local" (and its 
subdirectories "bin",
"lib", "include", "man", "share",  etc., nowadays.

Homebrew, I understand, installs like you suggest.

mvim (the Mac version of vi improved) installs into /usr/local, etc.

No matter which philosophy one follows the "@executable_path/../lib" in the 
binaries RPATH will
allow rexx to locate its libraries in its sibling "lib" directory.

The BSF4ooRexx installation installs, as you know, according to Apple's 
installation
recommendations, hence Framework and Application bundles are used there. The 
binaries in this
environment are then symbolically linked to /usr/local/bin and /usr/local/lib. 
Thinking of this
scenario it actually may make sense to have an additional RPATH defined in this 
case (speculating
that the system will resolve the symbolic path e.g. "/usr/local/bin/rexx ->
/Library/Frameworks/ooRexx.framework/Commands/rexx" for which its libraries are 
located in
"@executable_path/../Libraries"). Will test and report back, whether this would 
really be necessary.

---rony


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad RPATH and MacOSX

[P.O. Jonsson]

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




> Am 08.01.2019 um 17:17 schrieb Rony G. Flatscher :
> 
> Dear P.O.,
> 
> On 08.01.2019 16:24, P.O. Jonsson wrote:
>> I am not taking about the future, it is working NOW, without any 
>> modification besides the /bin
>> being in the path. NO NADA NIX modifications it works out of the box. Try it.
> 
> I believe you. :)
> 
>> A relocatable installation is desirable for other reasons, such as for 
>> creating an automated build
>> to ~/Applications, this is NOT possible today.
> 
> With Enricos definitions this has become possible. Just tested it a few 
> minutes ago successfully on
> MacOSX: moved the directories in ~/Applications/ooRexx.5.0.0 to ~/oha2/test 
> and successfully ran
> ooRexx from ~/oha2/test/bin and all of the sample programs there as well.

That is GREAT, will try it tomorrow.
> 
> Cheers,
> 
> ---royn
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Works and a question ad patches (Re: Question ad RPATH and MacOSX

[P.O. Jonsson]

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




> Am 08.01.2019 um 17:10 schrieb Rony G. Flatscher :
> 
> O.K, Enrico's definitions work like a charm!
> :)
> 
> Ad multiple RPATHs: this works as well, one needs to separate the paths with 
> a semi-colon, not with
> a colon, though. However, thinking about it in the meantime, this would not 
> be really helpful on
> Unix based systems, although Windows users might be happy. :) The reason 
> being that probably all
> Unix-based builds will have a "bin" and a "lib" directory as siblings.
> 
> Enrico's definitions should also work when installing to /usr/local as the 
> executables land in
> /usr/local/bin and locating their libs is "../lib" hence "/usr/local/lib“.

I would strongly advice against installing directly into /usr/local/bin and 
/usr/local/lib. Rather installing into /usr/local/oorexx5.0.0 (/bin,/lib etc) 
and Symlink all files into /usr/local/bin etc. This is what all other 
installations do. Out of 215 files in /bin 211 are symlinks, not executables.

> 
> Will test Linux later and report back, should there be any unexpected 
> problems.
> 
> Again, thank you very much Enrico for your advice! ooRexx now works in the 
> most versatile fashion! :)
> 
> ---
> 
> Just a question to the developers: is it helpful supplying a patch for 
> CMakeList.txt?
> 
> The reason why I ask is that a patch got not picked up so far that creates 
> symbolic links for Linux
> and MacOSX. I attached it to the proper bug report, cf. 
> .
> 
> The latest patch there is
> 
> which in addition also includes two placing the libraries in the "lib" 
> directory as per Enricos
> suggestion and naming 64-bit rpm packages correctly. That patch got tested 
> building ooRexx against
> Windows, Linux and MacOSX.
> 
> ---rony
> 
> 
> On 08.01.2019 16:12, Rony G. Flatscher wrote:
>> On 08.01.2019 15:52, Enrico Sorichetti via Oorexx-devel wrote:
>>> Right now You cannot relocate the installed thing 
>>> Because the rpath is an absolute one 
>>> I posted a few emails back the right constructs …
>> Hmm saw them, but was not sure what they were about and whether that was all 
>> that was needed (being
>> totally unfamiliar with RPATH)! :(
>> 
>>> Here they are again
>>> 
>>> With these settings  all works fine for me without bothering 
>>> To export DYLD_LIBRARY_PATH or LD_LIBRARY_PATH
>>> 
>>> # do not skip the full RPATH for the build tree
>>> SET( CMAKE_SKIP_BUILD_RPATH  FALSE)
>>> 
>>> # when building, don't use the install RPATH 
>>> # only later on when installing 
>>> SET( CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>>> 
>>> if( APPLE )
>>> SET( CMAKE_INSTALL_RPATH "@executable_path/../lib")
>>> else()
>>> SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib")
>>> endif()
>>> 
>>> # add the automatically determined parts of the RPATH
>>> # which point to directories outside the build tree to the install RPATH
>>> SET( CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
>> Is it correct to state in this case that the executable's libraries then get 
>> automatically searched
>> in the sibling "lib" directory?
>> 
>>> Without the RPATH setting the exports are required 
>>> 
>>> ( tested on El Capitan, high Sierra, Mojave and Fedora 29 )
>> This is great, thank you very much indeed (also for your patience! :) ), 
>> will try it out on both
>> MacOSX and Linux!
>> 
>>> Why would anybody set multiple paths ???
>> Well, in Windows the libraries are usually on the PATH and hence a 
>> standalone ("stick") version of
>> ooRexx on Windows might have the dlls in the same directory as ooRexx. Even 
>> though Windows should
>> not serve as the role model for Unix, nevertheless such layouts or solutions 
>> might be attempted
>> (easier understandable) for users (not developers).
>> 
>> People coming from Windows might therefore intend to place the shared 
>> libraries on Unix into the
>> executable directory as well or move "lib" to become local to the executable 
>> directory (this way a
>> subdirectory "oorexx" would point to the ooRexx executable and include all 
>> necessary files directly
>> there, including the libraries or the "lib" directory).
>> 
>> How would one add multiple RPATHs with CMake? Would just adding another 
>> directory to the path rpath
>> with a colon be correct, something like:
>> 
>> if( APPLE )
>> SET( CMAKE_INSTALL_RPATH "@executable_path/../lib:@executable_path/.")
>> else()
>> SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib:$ORIGIN/.")
>> endif()
>> 
>> Will test it, after first testing your "@executable_path/../lib"  definition.
>> 
>> Again, thank you very much, Enrico!
>> 
>> ---rony
>> 
>> 
>> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad RPATH and MacOSX

[Rony G. Flatscher]

Dear P.O.,

On 08.01.2019 16:24, P.O. Jonsson wrote:
> I am not taking about the future, it is working NOW, without any modification 
> besides the /bin
> being in the path. NO NADA NIX modifications it works out of the box. Try it.

I believe you. :)

> A relocatable installation is desirable for other reasons, such as for 
> creating an automated build
> to ~/Applications, this is NOT possible today.

With Enricos definitions this has become possible. Just tested it a few minutes 
ago successfully on
MacOSX: moved the directories in ~/Applications/ooRexx.5.0.0 to ~/oha2/test and 
successfully ran
ooRexx from ~/oha2/test/bin and all of the sample programs there as well.

Cheers,

---royn




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Works and a question ad patches (Re: Question ad RPATH and MacOSX

[Rony G. Flatscher]

O.K, Enrico's definitions work like a charm!
:)

Ad multiple RPATHs: this works as well, one needs to separate the paths with a 
semi-colon, not with
a colon, though. However, thinking about it in the meantime, this would not be 
really helpful on
Unix based systems, although Windows users might be happy. :) The reason being 
that probably all
Unix-based builds will have a "bin" and a "lib" directory as siblings.

Enrico's definitions should also work when installing to /usr/local as the 
executables land in
/usr/local/bin and locating their libs is "../lib" hence "/usr/local/lib".

Will test Linux later and report back, should there be any unexpected problems.

Again, thank you very much Enrico for your advice! ooRexx now works in the most 
versatile fashion! :)

---

Just a question to the developers: is it helpful supplying a patch for 
CMakeList.txt?

The reason why I ask is that a patch got not picked up so far that creates 
symbolic links for Linux
and MacOSX. I attached it to the proper bug report, cf. 
.

The latest patch there is

which in addition also includes two placing the libraries in the "lib" 
directory as per Enricos
suggestion and naming 64-bit rpm packages correctly. That patch got tested 
building ooRexx against
Windows, Linux and MacOSX.

---rony


On 08.01.2019 16:12, Rony G. Flatscher wrote:
> On 08.01.2019 15:52, Enrico Sorichetti via Oorexx-devel wrote:
>> Right now You cannot relocate the installed thing 
>> Because the rpath is an absolute one 
>> I posted a few emails back the right constructs …
> Hmm saw them, but was not sure what they were about and whether that was all 
> that was needed (being
> totally unfamiliar with RPATH)! :(
>
>> Here they are again
>>
>> With these settings  all works fine for me without bothering 
>> To export DYLD_LIBRARY_PATH or LD_LIBRARY_PATH
>>
>> # do not skip the full RPATH for the build tree
>> SET( CMAKE_SKIP_BUILD_RPATH  FALSE)
>>
>> # when building, don't use the install RPATH 
>> # only later on when installing 
>> SET( CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>>
>> if( APPLE )
>>     SET( CMAKE_INSTALL_RPATH "@executable_path/../lib")
>> else()
>>     SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib")
>> endif()
>>
>> # add the automatically determined parts of the RPATH
>> # which point to directories outside the build tree to the install RPATH
>> SET( CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> Is it correct to state in this case that the executable's libraries then get 
> automatically searched
> in the sibling "lib" directory?
>
>> Without the RPATH setting the exports are required 
>>
>> ( tested on El Capitan, high Sierra, Mojave and Fedora 29 )
> This is great, thank you very much indeed (also for your patience! :) ), will 
> try it out on both
> MacOSX and Linux!
>
>> Why would anybody set multiple paths ???
> Well, in Windows the libraries are usually on the PATH and hence a standalone 
> ("stick") version of
> ooRexx on Windows might have the dlls in the same directory as ooRexx. Even 
> though Windows should
> not serve as the role model for Unix, nevertheless such layouts or solutions 
> might be attempted
> (easier understandable) for users (not developers).
>
> People coming from Windows might therefore intend to place the shared 
> libraries on Unix into the
> executable directory as well or move "lib" to become local to the executable 
> directory (this way a
> subdirectory "oorexx" would point to the ooRexx executable and include all 
> necessary files directly
> there, including the libraries or the "lib" directory).
>
> How would one add multiple RPATHs with CMake? Would just adding another 
> directory to the path rpath
> with a colon be correct, something like:
>
> if( APPLE )
>     SET( CMAKE_INSTALL_RPATH "@executable_path/../lib:@executable_path/.")
> else()
>     SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib:$ORIGIN/.")
> endif()
>
> Will test it, after first testing your "@executable_path/../lib"  definition.
>
> Again, thank you very much, Enrico!
>
> ---rony
>
>
>



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad RPATH and MacOSX

[P.O. Jonsson]

Dear Rony,

I am not taking about the future, it is working NOW, without any modification 
besides the /bin being in the path. NO NADA NIX modifications it works out of 
the box. Try it.

A relocatable installation is desirable for other reasons, such as for creating 
an automated build to ~/Applications, this is NOT possible today.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 08.01.2019 um 16:19 schrieb Rony G. Flatscher :
> 
> Dear P.O.,
> 
> On 08.01.2019 16:16, P.O. Jonsson wrote:
>> For MAC at least a build to a USB stick is relocatable to another computer 
>> since the name of the
>> stick will be the name of the volume, automatically mounted to /Volumes
> 
> with RPATH defined the way Enrico suggests, there is no need to link/copy the 
> libraries to any
> special place, they will be located by the system relative to the place where 
> the "rexx" executable
> resides. Therefore the binaries (if moved with the lib directory) are fully 
> relocatable.
> 
> Best regards
> 
> ---rony
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad RPATH and MacOSX

[Rony G. Flatscher]

Dear P.O.,

On 08.01.2019 16:16, P.O. Jonsson wrote:
> For MAC at least a build to a USB stick is relocatable to another computer 
> since the name of the
> stick will be the name of the volume, automatically mounted to /Volumes

with RPATH defined the way Enrico suggests, there is no need to link/copy the 
libraries to any
special place, they will be located by the system relative to the place where 
the "rexx" executable
resides. Therefore the binaries (if moved with the lib directory) are fully 
relocatable.

Best regards

---rony



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad RPATH and MacOSX

[Rony G. Flatscher]

Dear Enrico:

On 08.01.2019 16:11, Enrico Sorichetti via Oorexx-devel wrote:
> I wonder why everybody refuses to use the proper constructs for the RPATH
> Looks like I am wasting my time testing and making suggestions

please bear with us!

Not having *any* background knowledge of CMake and the usage of RPATH, it 
sometimes takes a second
or third push!

Also, I have noticed your posted CMake program which would display all set 
CMake variables and meant
to ask how to use it! Something that probably goes without saying for yourself, 
being obviously a
CMake master/expert/power user, but something that needs experiments/research 
from this side of a
total CMake amateur (who unfortunately does not have time at the moment to 
really go through
tutorials and background literature/sources to get acquainted with it). In the 
meantime I have been
carried away from testing it (with a popped up problem with BSF4ooRexx and 
OpenOffice/LibreOffice on
MacOSX that in the meantime got solved, after quite some efforts and two day's 
of work), but would
like to do that in any case as it would allow me to get a rough idea of what 
CMake variables are set
and used for a build.

Cheers,

---rony



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad RPATH and MacOSX

[P.O. Jonsson]

For MAC at least a build to a USB stick is relocatable to another computer 
since the name of the stick will be the name of the volume, automatically 
mounted to /Volumes

There is a USB standalone version for testing here 


Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 08.01.2019 um 15:46 schrieb Rony G. Flatscher :
> 
> Would it be possible to define RPATH such, that it always looks in the 
> directories ".", "./lib",
> "../lib", "/usr/local/lib" (maybe even "/opt/local/lib") for the needed 
> libraries?
> 
> This way a USB-stick version may have the executables in the same directory 
> or lib in a companion or
> subdirectory.
> 
> Currently, after a "make install" one cannot relocate the resulting binaries. 
> Using the binaries
> from the "make" step forces one to have "lib" in a sibling directory.
> 
> Probably with the help of
>  
> this could be solvable.
> Alternatively, if one has XCode installed, one might use "install_name_tool" 
> to manipulate all rpath
> definitions. Another alternative would be to set DYLD_LIBRARY_PATH.
> 
> What do you think, which solution would be preferable?
> 
> ---rony
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad RPATH and MacOSX

[Rony G. Flatscher]

On 08.01.2019 15:52, Enrico Sorichetti via Oorexx-devel wrote:
> Right now You cannot relocate the installed thing 
> Because the rpath is an absolute one 
> I posted a few emails back the right constructs …

Hmm saw them, but was not sure what they were about and whether that was all 
that was needed (being
totally unfamiliar with RPATH)! :(

> Here they are again
>
> With these settings  all works fine for me without bothering 
> To export DYLD_LIBRARY_PATH or LD_LIBRARY_PATH
>
> # do not skip the full RPATH for the build tree
> SET( CMAKE_SKIP_BUILD_RPATH  FALSE)
>
> # when building, don't use the install RPATH 
> # only later on when installing 
> SET( CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>
> if( APPLE )
>     SET( CMAKE_INSTALL_RPATH "@executable_path/../lib")
> else()
>     SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib")
> endif()
>
> # add the automatically determined parts of the RPATH
> # which point to directories outside the build tree to the install RPATH
> SET( CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

Is it correct to state in this case that the executable's libraries then get 
automatically searched
in the sibling "lib" directory?

> Without the RPATH setting the exports are required 
>
> ( tested on El Capitan, high Sierra, Mojave and Fedora 29 )

This is great, thank you very much indeed (also for your patience! :) ), will 
try it out on both
MacOSX and Linux!

>
> Why would anybody set multiple paths ???

Well, in Windows the libraries are usually on the PATH and hence a standalone 
("stick") version of
ooRexx on Windows might have the dlls in the same directory as ooRexx. Even 
though Windows should
not serve as the role model for Unix, nevertheless such layouts or solutions 
might be attempted
(easier understandable) for users (not developers).

People coming from Windows might therefore intend to place the shared libraries 
on Unix into the
executable directory as well or move "lib" to become local to the executable 
directory (this way a
subdirectory "oorexx" would point to the ooRexx executable and include all 
necessary files directly
there, including the libraries or the "lib" directory).

How would one add multiple RPATHs with CMake? Would just adding another 
directory to the path rpath
with a colon be correct, something like:

if( APPLE )
    SET( CMAKE_INSTALL_RPATH "@executable_path/../lib:@executable_path/.")
else()
    SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib:$ORIGIN/.")
endif()

Will test it, after first testing your "@executable_path/../lib"  definition.

Again, thank you very much, Enrico!

---rony






___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad RPATH and MacOSX

[Enrico Sorichetti via Oorexx-devel]

I wonder why everybody refuses to use the proper constructs for the RPATH
Looks like I am wasting my time testing and making suggestions 
E

> On 8 Jan 2019, at 16:08, P.O. Jonsson  wrote:
> 
> With this convention - would it be possible to make the executables 
> relocatable?

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad RPATH and MacOSX

[P.O. Jonsson]

Dear all,

I think there might be another way of solving this problem. If you symlink all 
libraries in /lib back to /bin it will look as if the libraries are in the same 
place as the executable ( in „." basically), so one could rely on that always 
being the case.

During a time when my build did not create the /lib properly all files resided 
in /bin. I could run all test cases using that configuration with no problems.

With this convention - would it be possible to make the executables relocatable?

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 08.01.2019 um 15:46 schrieb Rony G. Flatscher :
> 
> Would it be possible to define RPATH such, that it always looks in the 
> directories ".", "./lib",
> "../lib", "/usr/local/lib" (maybe even "/opt/local/lib") for the needed 
> libraries?
> 
> This way a USB-stick version may have the executables in the same directory 
> or lib in a companion or
> subdirectory.
> 
> Currently, after a "make install" one cannot relocate the resulting binaries. 
> Using the binaries
> from the "make" step forces one to have "lib" in a sibling directory.
> 
> Probably with the help of
>  
> this could be solvable.
> Alternatively, if one has XCode installed, one might use "install_name_tool" 
> to manipulate all rpath
> definitions. Another alternative would be to set DYLD_LIBRARY_PATH.
> 
> What do you think, which solution would be preferable?
> 
> ---rony
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad RPATH and MacOSX

[Enrico Sorichetti via Oorexx-devel]

Right now You cannot relocate the installed thing 
Because the rpath is an absolute one 
I posted a few emails back the right constructs …

Here they are again

With these settings  all works fine for me without bothering 
To export DYLD_LIBRARY_PATH or LD_LIBRARY_PATH

# do not skip the full RPATH for the build tree
SET( CMAKE_SKIP_BUILD_RPATH  FALSE)

# when building, don't use the install RPATH 
# only later on when installing 
SET( CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)

if( APPLE )
SET( CMAKE_INSTALL_RPATH "@executable_path/../lib")
else()
SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib")
endif()

# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET( CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

Without the RPATH setting the exports are required 

( tested on El Capitan, high Sierra, Mojave and Fedora 29 )

Why would anybody set multiple paths ???

If things have been done properly no need.

Cheers
Enrico

> On 8 Jan 2019, at 15:46, Rony G. Flatscher  wrote:
> 
> Would it be possible to define RPATH such, that it always looks in the 
> directories ".", "./lib",
> "../lib", "/usr/local/lib" (maybe even "/opt/local/lib") for the needed 
> libraries?

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad RPATH and MacOSX

[René Jansen]

yes, I think I read that it is possible to define multiple rpaths with 
install_name_tool

> On 8 Jan 2019, at 10:46, Rony G. Flatscher  wrote:
> 
> Would it be possible to define RPATH such, that it always looks in the 
> directories ".", "./lib",
> "../lib", "/usr/local/lib" (maybe even "/opt/local/lib") for the needed 
> libraries?
> 
> This way a USB-stick version may have the executables in the same directory 
> or lib in a companion or
> subdirectory.
> 
> Currently, after a "make install" one cannot relocate the resulting binaries. 
> Using the binaries
> from the "make" step forces one to have "lib" in a sibling directory.
> 
> Probably with the help of
>  
> this could be solvable.
> Alternatively, if one has XCode installed, one might use "install_name_tool" 
> to manipulate all rpath
> definitions. Another alternative would be to set DYLD_LIBRARY_PATH.
> 
> What do you think, which solution would be preferable?
> 
> ---rony
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Question ad RPATH and MacOSX

[Rony G. Flatscher]

Would it be possible to define RPATH such, that it always looks in the 
directories ".", "./lib",
"../lib", "/usr/local/lib" (maybe even "/opt/local/lib") for the needed 
libraries?

This way a USB-stick version may have the executables in the same directory or 
lib in a companion or
subdirectory.

Currently, after a "make install" one cannot relocate the resulting binaries. 
Using the binaries
from the "make" step forces one to have "lib" in a sibling directory.

Probably with the help of
 
this could be solvable.
Alternatively, if one has XCode installed, one might use "install_name_tool" to 
manipulate all rpath
definitions. Another alternative would be to set DYLD_LIBRARY_PATH.

What do you think, which solution would be preferable?

---rony




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel