Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Rony G. Flatscher]

Bonsoir Jean-Louis,

On 21.07.2021 19:16, Jean Louis Faucher wrote:
> Guten Abend Rony
>>
>> would it ease your use case/be of help for your use case, if I were to 
>> add honoring an
>> environment variable (e.g. "BSF4ooRexx_Library") which would need to 
>> fully qualify (absolute
>> path) the BSF4ooRexx- library to be loaded? 
>>
> Not needed on my side.
>
> My no-install setup sets these variables:
> BSF4Rexx_JavaStartupOptions="-Djava.library.path=...
> CLASSPATH
> DYLD_LIBRARY_PATH
> JAVA_HOME
> PATH
>
> I think the new variable you propose would be redundant with 
> BSF4Rexx_JavaStartupOptions ?
> It’s not a problem for me to define BSF4Rexx_JavaStartupOptions.

that is fine, then I would leave it as is.

---rony

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

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Jean Louis Faucher]

Guten Abend Rony
> would it ease your use case/be of help for your use case, if I were to add 
> honoring an environment variable (e.g. "BSF4ooRexx_Library") which would need 
> to fully qualify (absolute path) the BSF4ooRexx- library to be loaded? 
> 
Not needed on my side.

My no-install setup sets these variables:
BSF4Rexx_JavaStartupOptions="-Djava.library.path=...
CLASSPATH
DYLD_LIBRARY_PATH
JAVA_HOME
PATH

I think the new variable you propose would be redundant with 
BSF4Rexx_JavaStartupOptions ?
It’s not a problem for me to define BSF4Rexx_JavaStartupOptions.


Jean-Louis

> On 21 Jul 2021, at 18:57, Rony G. Flatscher  wrote:
> 
> Bonsoir Jean-Louis,
> 
> one question ad your test case # 3 which you were able to resolve with 
> BSF4ooRexx_setup: 
> would it ease your use case/be of help for your use case, if I were to add 
> honoring an environment variable (e.g. "BSF4ooRexx_Library") which would need 
> to fully qualify (absolute path) the BSF4ooRexx- library to be loaded? 
> [I tested it and it would be possible as it works in the baseline Java 
> version 1.6. That's the "6" in the version number "641", where "41" is the 
> ooRexx baseline, i.e. ooRexx version 4.1.]
> ---rony
> 
> On 21.07.2021 17:53, Jean Louis Faucher wrote:
>> Guten tag Rony
>> 
>>> A question here: after you removed the shebang line how were you able to 
>>> successfully invoke/run "rexx2.sh 1-010_HellowWorld.rxj"?
>>> 
>> 
>> That was the purpose of the side note, to explain why it works.
>> 
>> By the way, during my tests, I ran setupBSF.rex to review the generated 
>> scripts, and I noticed that rexxj.sh has no shebang. Keep it like that! It’s 
>> just to say that it works without shebang.
>> 
>> I’m curious to know if the most recent versions of MacOs still keep the DYLD 
>> variables when no shebang…
>> A simple echo $DYLD_LIBRARY_PATH is enough to check that.
>> 
>> If, at one moment, Apple decides to “fix” that, then the only workaround 
>> will be to put a copy of /bin/sh in /usr/local/bin, to make it unprotected 
>> by SIP.
>> Of course, this is not something for production, but still can be useful for 
>> a development machine.
>> 
>> 
>> Thanks for the background informations!
>> I understand that 
>>> java.lang.System.loadLibrary(libName)
>> takes care of java.library.path to find LibName, but the libs needed by 
>> LibName are not searched with the paths in java.library.path:
>> I have the path to ooRexx5 lib in java.library.path, they are not found when 
>> the shebang is used, i.e. when DYLD_LIBRARY is deleted.
>> 
>> 
>> Jean-Louis
>> 
>> 
>>> On 21 Jul 2021, at 17:03, Rony G. Flatscher >> > wrote:
>>> 
>>> Bonjour Jean-Louis,
>>> 
>>> thank you very much for your information!
>>> On 21.07.2021 09:21, Jean Louis Faucher wrote:
 Guten tag Rony
 
 Thanks a lot for the detailed explanations.
 After setting BSF4Rexx_JavaStartupOptions as you explained, the 3rd test 
 case is ok now.
 More tests:
 
 rexx 1-030_JavaVersion.rxj works correctly.
 
 rexxj2.sh 1-010_HelloWorld.rxj did not work because of "Library not 
 loaded: @rpath/librexx.4.dylib”
 Should be found with DYLD_LIBRARY_PATH, but SIP deleted it:
 - rexxj2.sh has a shebang line #!/bin/sh, which is protected by SIP
 - the default java is protected by SIP.
 
 After installing a local JDK (just unzip + set JAVA_HOME) and removing the 
 shebang line of rexxj2.sh, that worked.
>>> 
>>> A question here: after you removed the shebang line how were you able to 
>>> successfully invoke/run "rexx2.sh 1-010_HellowWorld.rxj"?
>>> 
>>> 
>>> ---
>>> Ad background to "rexxj.sh"/"rexxj2.sh": 
>>> purpose: run Rexx scripts via java instead of via the rexx binary using the 
>>> file name of the Rexx script as argument, optionally followed by arguments 
>>> for the Rexx script 
>>> 
>>> so "rexxj[2].sh" Java gets launched (if the environment variable 
>>> "BSF4Rexx_JavaStartupOptions" exists then its value gets passed to java, 
>>> which configures the Java virtual machine, JVM) which loads the BSF4ooRexx 
>>> Java class named "org.rexxla.bsf.RexxDispatcher" and run its static main 
>>> method supplying all command line arguments. 
>>> 
>>> the main method of the Java class "org.rexxla.bsf.RexxDispatcher" will 
>>> create an instance of  "org.apache.bsf.BSFManager" 
>>> 
>>> all the command line arguments as parsed and supplied by Java and passed on 
>>> to the static main method as a Java String array get registered with the 
>>> BSFManager instance under the name "allCommandLineArguments"; 
>>> 
>>> BSFManager needs to find and create the engine for Rexx: it looks up the 
>>> BSF defined engine names and dynamically loads the Java class 
>>> "org.rexxla.bsf.engines.rexx.RexxEngine" which extends the abstract class 
>>> "org.apache.bsf.util.BSFEngineImpl" which  implements  the interface class 
>>> "org.apache.bsf.BSFEngine" 
>>> 
>>> an instance of 

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Rony G. Flatscher]

Bonsoir Jean-Louis,

one question ad your test case # 3 which you were able to resolve with 
BSF4ooRexx_setup:

would it ease your use case/be of help for your use case, if I were to add 
honoring an
environment variable (e.g. "BSF4ooRexx_Library") which would need to fully 
qualify (absolute
path) the BSF4ooRexx- library to be loaded?
[I tested it and it would be possible as it works in the baseline Java 
version 1.6. That's the
"6" in the version number "641", where "41" is the ooRexx baseline, i.e. 
ooRexx version 4.1.]

---rony


On 21.07.2021 17:53, Jean Louis Faucher wrote:
> Guten tag Rony
>
>> A question here: after you removed the shebang line how were you able to 
>> successfully invoke/run
>> "rexx2.sh 1-010_HellowWorld.rxj"?
>>
> That was the purpose of the side note, to explain why it works.
>
> By the way, during my tests, I ran setupBSF.rex to review the generated 
> scripts, and I noticed
> that rexxj.sh has no shebang. Keep it like that! It’s just to say that it 
> works without shebang.
>
> I’m curious to know if the most recent versions of MacOs still keep the DYLD 
> variables when no
> shebang…
> A simple echo $DYLD_LIBRARY_PATH is enough to check that.
>
> If, at one moment, Apple decides to “fix” that, then the only workaround will 
> be to put a copy of
> /bin/sh in /usr/local/bin, to make it unprotected by SIP.
> Of course, this is not something for production, but still can be useful for 
> a development machine.
>
>
> Thanks for the background informations!
> I understand that 
>>
>>   * java.lang.System.loadLibrary(libName)
>>
> takes care of java.library.path to find LibName, but the libs needed by 
> LibName are not searched
> with the paths in java.library.path:
> I have the path to ooRexx5 lib in java.library.path, they are not found when 
> the shebang is used,
> i.e. when DYLD_LIBRARY is deleted.
>
>
> Jean-Louis
>
>
>> On 21 Jul 2021, at 17:03, Rony G. Flatscher > > wrote:
>>
>> Bonjour Jean-Louis,
>>
>> thank you very much for your information!
>>
>> On 21.07.2021 09:21, Jean Louis Faucher wrote:
>>> Guten tag Rony
>>>
>>> Thanks a lot for the detailed explanations.
>>> After setting BSF4Rexx_JavaStartupOptions as you explained, the 3rd test 
>>> case is ok now.
>>> More tests:
>>>
>>> rexx 1-030_JavaVersion.rxj works correctly.
>>>
>>> rexxj2.sh 1-010_HelloWorld.rxj did not work because of "Library not loaded: 
>>> @rpath/librexx.4.dylib”
>>> Should be found with DYLD_LIBRARY_PATH, but SIP deleted it:
>>> - rexxj2.sh has a shebang line #!/bin/sh, which is protected by SIP
>>> - the default java is protected by SIP.
>>>
>>> After installing a local JDK (just unzip + set JAVA_HOME) and removing the 
>>> shebang line of
>>> rexxj2.sh, that worked.
>>
>>
>> A question here: after you removed the shebang line how were you able to 
>> successfully invoke/run
>> "rexx2.sh 1-010_HellowWorld.rxj"?
>>
>>
>> ---
>>
>> Ad background to "rexxj.sh"/"rexxj2.sh":
>>
>>   * purpose: run Rexx scripts /via java //instead of /via the rexx binary 
>> using the file name of
>> the Rexx script as argument, optionally followed by arguments for the 
>> Rexx script
>>
>>   * so "rexxj[2].sh" Java gets launched (if the environment variable
>> "BSF4Rexx_JavaStartupOptions" exists then its value gets passed to 
>> /java/, which configures
>> the Java virtual machine, JVM) which loads the BSF4ooRexx Java class 
>> named
>> "org.rexxla.bsf.RexxDispatcher" and run its static main method supplying 
>> all command line
>> arguments.
>>
>>   * the main method of the Java class "org.rexxla.bsf.RexxDispatcher" will 
>> create an instance of 
>> "org.apache.bsf.BSFManager"
>>
>>   o all the command line arguments as parsed and supplied by Java and 
>> passed on to the static
>> main method as a Java String array get registered with the 
>> BSFManager instance under the
>> name "allCommandLineArguments";
>>
>>   o BSFManager needs to find and create the engine for Rexx: it looks up 
>> the BSF defined
>> engine names and dynamically loads the Java class
>> "org.rexxla.bsf.engines.rexx.RexxEngine" which extends the abstract 
>> class
>> "org.apache.bsf.util.BSFEngineImpl" which  implements  the interface 
>> class
>> "org.apache.bsf.BSFEngine"
>>
>>   + an instance of "org.rexxla.bsf.engines.rexx.RexxEngine" gets 
>> created and the current
>> set of BSFManager registered beans will get registered with the 
>> RexxEngine instance
>>
>>   + the RexxEngine instance will have its "initialize()" method 
>> invoked
>>
>>   # the RexxEngine creates an instance of 
>> "org.rexxla.bsf.engines.rexx.RexxAndJava"
>> which serves as the interface for this combination of this 
>> BSFManager instance
>> and this RexxEngine instance
>>
>>   * the very first time the 
>> 

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Rony G. Flatscher]

Bonsoir Jean-Louis,

On 21.07.2021 17:53, Jean Louis Faucher wrote:
>>
>> A question here: after you removed the shebang line how were you able to 
>> successfully invoke/run
>> "rexx2.sh 1-010_HellowWorld.rxj"?
>>
> That was the purpose of the side note, to explain why it works.
>
Yes, I understand. Are you saying that "rexx2.sh" works without the hashbang 
line if it is marked
executable? So far I would have expected that running "./rexx2.sh" without a 
hashbang would not work
as the operating system would not know which application is supposed to run it 
(of course, the file
extension .sh would indicate the shell, but then the shell gets SIP protected 
...).

> By the way, during my tests, I ran setupBSF.rex to review the generated 
> scripts, and I noticed
> that rexxj.sh has no shebang. Keep it like that! It’s just to say that it 
> works without shebang.

If it works, I will remove the shebang from all the rexxj* scripts on MacOS. 
(Will test though
whether that would work on Linux as well, which would ease the configuration.)

> I’m curious to know if the most recent versions of MacOs still keep the DYLD 
> variables when no
> shebang…
> A simple echo $DYLD_LIBRARY_PATH is enough to check that.

Well it does not show it on my machine (11.4 Big Sur). However here a few 
musings

--- start of test ---
export DYLD_LIBRARY_PATH=test-macos
echo $DYLD_LIBRARY_PATH
test-macos
set | sort
... outputs a line (note: env | sort does not): DYLD_LIBRARY_PATH=test-macos
DYLD_LIBRARY_PATH=nixi:noxi echo $DYLD_LIBRARY_PATH
test-macos
unset DYLD_LIBRARY_PATH
echo $DYLD_LIBRARY_PATH

DYLD_LIBRARY_PATH=nixi:noxi echo $DYLD_LIBRARY_PATH

--- end of test ---

> If, at one moment, Apple decides to “fix” that, then the only workaround will 
> be to put a copy of
> /bin/sh in /usr/local/bin, to make it unprotected by SIP.
> Of course, this is not something for production, but still can be useful for 
> a development machine.

Indeed. Production would mean to install the package such that the links are in 
the appropriate places.

> Thanks for the background informations!
> I understand that 
>>
>>   * java.lang.System.loadLibrary(libName)
>>
> takes care of java.library.path to find LibName, but the libs needed by 
> LibName are not searched
> with the paths in java.library.path:
> I have the path to ooRexx5 lib in java.library.path, they are not found when 
> the shebang is used,
> i.e. when DYLD_LIBRARY is deleted.

The reason is that the Java part of BSF4ooRexx does not load the ooRexx libs 
via Java, rather via
the dynamic link library (like creating RexxInterpreter instances, for each 
RexxEngine instance
there will be a RexxInterpreter instance created) which is linked against the 
rexx and rexxapi
libraries. So:

  * use case 1: rexx loads Java (via libBSF4ooRexx.dylib)
  * use case 2: Java loads Rexx (via libBSF4ooRexx.dylib)

--rony



>
>
>> On 21 Jul 2021, at 17:03, Rony G. Flatscher > > wrote:
>>
>> Bonjour Jean-Louis,
>>
>> thank you very much for your information!
>>
>> On 21.07.2021 09:21, Jean Louis Faucher wrote:
>>> Guten tag Rony
>>>
>>> Thanks a lot for the detailed explanations.
>>> After setting BSF4Rexx_JavaStartupOptions as you explained, the 3rd test 
>>> case is ok now.
>>> More tests:
>>>
>>> rexx 1-030_JavaVersion.rxj works correctly.
>>>
>>> rexxj2.sh 1-010_HelloWorld.rxj did not work because of "Library not loaded: 
>>> @rpath/librexx.4.dylib”
>>> Should be found with DYLD_LIBRARY_PATH, but SIP deleted it:
>>> - rexxj2.sh has a shebang line #!/bin/sh, which is protected by SIP
>>> - the default java is protected by SIP.
>>>
>>> After installing a local JDK (just unzip + set JAVA_HOME) and removing the 
>>> shebang line of
>>> rexxj2.sh, that worked.
>>
>>
>> A question here: after you removed the shebang line how were you able to 
>> successfully invoke/run
>> "rexx2.sh 1-010_HellowWorld.rxj"?
>>
>>
>> ---
>>
>> Ad background to "rexxj.sh"/"rexxj2.sh":
>>
>>   * purpose: run Rexx scripts /via java //instead of /via the rexx binary 
>> using the file name of
>> the Rexx script as argument, optionally followed by arguments for the 
>> Rexx script
>>
>>   * so "rexxj[2].sh" Java gets launched (if the environment variable
>> "BSF4Rexx_JavaStartupOptions" exists then its value gets passed to 
>> /java/, which configures
>> the Java virtual machine, JVM) which loads the BSF4ooRexx Java class 
>> named
>> "org.rexxla.bsf.RexxDispatcher" and run its static main method supplying 
>> all command line
>> arguments.
>>
>>   * the main method of the Java class "org.rexxla.bsf.RexxDispatcher" will 
>> create an instance of 
>> "org.apache.bsf.BSFManager"
>>
>>   o all the command line arguments as parsed and supplied by Java and 
>> passed on to the static
>> main method as a Java String array get registered with the 
>> BSFManager instance under the
>> name "allCommandLineArguments";

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Jean Louis Faucher]

Guten tag Rony

> A question here: after you removed the shebang line how were you able to 
> successfully invoke/run "rexx2.sh 1-010_HellowWorld.rxj"?
> 

That was the purpose of the side note, to explain why it works.

By the way, during my tests, I ran setupBSF.rex to review the generated 
scripts, and I noticed that rexxj.sh has no shebang. Keep it like that! It’s 
just to say that it works without shebang.

I’m curious to know if the most recent versions of MacOs still keep the DYLD 
variables when no shebang…
A simple echo $DYLD_LIBRARY_PATH is enough to check that.

If, at one moment, Apple decides to “fix” that, then the only workaround will 
be to put a copy of /bin/sh in /usr/local/bin, to make it unprotected by SIP.
Of course, this is not something for production, but still can be useful for a 
development machine.


Thanks for the background informations!
I understand that 
> java.lang.System.loadLibrary(libName)
takes care of java.library.path to find LibName, but the libs needed by LibName 
are not searched with the paths in java.library.path:
I have the path to ooRexx5 lib in java.library.path, they are not found when 
the shebang is used, i.e. when DYLD_LIBRARY is deleted.


Jean-Louis


> On 21 Jul 2021, at 17:03, Rony G. Flatscher  wrote:
> 
> Bonjour Jean-Louis,
> 
> thank you very much for your information!
> On 21.07.2021 09:21, Jean Louis Faucher wrote:
>> Guten tag Rony
>> 
>> Thanks a lot for the detailed explanations.
>> After setting BSF4Rexx_JavaStartupOptions as you explained, the 3rd test 
>> case is ok now.
>> More tests:
>> 
>> rexx 1-030_JavaVersion.rxj works correctly.
>> 
>> rexxj2.sh 1-010_HelloWorld.rxj did not work because of "Library not loaded: 
>> @rpath/librexx.4.dylib”
>> Should be found with DYLD_LIBRARY_PATH, but SIP deleted it:
>> - rexxj2.sh has a shebang line #!/bin/sh, which is protected by SIP
>> - the default java is protected by SIP.
>> 
>> After installing a local JDK (just unzip + set JAVA_HOME) and removing the 
>> shebang line of rexxj2.sh, that worked.
> 
> A question here: after you removed the shebang line how were you able to 
> successfully invoke/run "rexx2.sh 1-010_HellowWorld.rxj"?
> 
> 
> ---
> Ad background to "rexxj.sh"/"rexxj2.sh": 
> purpose: run Rexx scripts via java instead of via the rexx binary using the 
> file name of the Rexx script as argument, optionally followed by arguments 
> for the Rexx script 
> 
> so "rexxj[2].sh" Java gets launched (if the environment variable 
> "BSF4Rexx_JavaStartupOptions" exists then its value gets passed to java, 
> which configures the Java virtual machine, JVM) which loads the BSF4ooRexx 
> Java class named "org.rexxla.bsf.RexxDispatcher" and run its static main 
> method supplying all command line arguments. 
> 
> the main method of the Java class "org.rexxla.bsf.RexxDispatcher" will create 
> an instance of  "org.apache.bsf.BSFManager" 
> 
> all the command line arguments as parsed and supplied by Java and passed on 
> to the static main method as a Java String array get registered with the 
> BSFManager instance under the name "allCommandLineArguments"; 
> 
> BSFManager needs to find and create the engine for Rexx: it looks up the BSF 
> defined engine names and dynamically loads the Java class 
> "org.rexxla.bsf.engines.rexx.RexxEngine" which extends the abstract class 
> "org.apache.bsf.util.BSFEngineImpl" which  implements  the interface class 
> "org.apache.bsf.BSFEngine" 
> 
> an instance of "org.rexxla.bsf.engines.rexx.RexxEngine" gets created and the 
> current set of BSFManager registered beans will get registered with the 
> RexxEngine instance
> 
> the RexxEngine instance will have its "initialize()" method invoked
> 
> the RexxEngine creates an instance of 
> "org.rexxla.bsf.engines.rexx.RexxAndJava" which serves as the interface for 
> this combination of this BSFManager instance and this RexxEngine instance
> 
> the very first time the "org.rexxla.bsf.engines.rexx.RexxAndJava" class gets 
> loaded its static constructor will - among other things - load the dynamic 
> BSF4ooRexx library using java.lang.System.loadLibrary(libName)
> 
> the constructor of "org.rexxla.bsf.engines.rexx.RexxAndJava" will use a 
> native method from the BSF4ooRexx dynamic library to initialize it
> 
> the RexxEngine registers the BSFManager's registered beans with its instance 
> such that a Rexx programmer can get at the Java parsed arguments (a Java 
> array of type String) with the statement:
> 
> argsByJava=bsf.lookupBean("allCommandLineArguments")
> 
> the freshly created RexxEngine is then used to execute the supplied Rexx 
> script (which will be read from file), supplying the arguments to the Rexx 
> script
> 
> at the very first time a Rexx script needs to be executed, the RexxEngine 
> creates a RexxInterpreter instance for that purpose, and reuses it each time 
> Rexx code needs to get executed via this RexxEngine
> 
> Remark: for Java programmers it is possible to configure the 

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Rony G. Flatscher]

Bonjour Jean-Louis,

thank you very much for your information!

On 21.07.2021 09:21, Jean Louis Faucher wrote:
> Guten tag Rony
>
> Thanks a lot for the detailed explanations.
> After setting BSF4Rexx_JavaStartupOptions as you explained, the 3rd test case 
> is ok now.
> More tests:
>
> rexx 1-030_JavaVersion.rxj works correctly.
>
> rexxj2.sh 1-010_HelloWorld.rxj did not work because of "Library not loaded: 
> @rpath/librexx.4.dylib”
> Should be found with DYLD_LIBRARY_PATH, but SIP deleted it:
> - rexxj2.sh has a shebang line #!/bin/sh, which is protected by SIP
> - the default java is protected by SIP.
>
> After installing a local JDK (just unzip + set JAVA_HOME) and removing the 
> shebang line of
> rexxj2.sh, that worked.


A question here: after you removed the shebang line how were you able to 
successfully invoke/run
"rexx2.sh 1-010_HellowWorld.rxj"?


---

Ad background to "rexxj.sh"/"rexxj2.sh":

  * purpose: run Rexx scripts /via java //instead of /via the rexx binary using 
the file name of the
Rexx script as argument, optionally followed by arguments for the Rexx 
script

  * so "rexxj[2].sh" Java gets launched (if the environment variable 
"BSF4Rexx_JavaStartupOptions"
exists then its value gets passed to /java/, which configures the Java 
virtual machine, JVM)
which loads the BSF4ooRexx Java class named "org.rexxla.bsf.RexxDispatcher" 
and run its static
main method supplying all command line arguments.

  * the main method of the Java class "org.rexxla.bsf.RexxDispatcher" will 
create an instance of 
"org.apache.bsf.BSFManager"

  o all the command line arguments as parsed and supplied by Java and 
passed on to the static
main method as a Java String array get registered with the BSFManager 
instance under the
name "allCommandLineArguments";

  o BSFManager needs to find and create the engine for Rexx: it looks up 
the BSF defined engine
names and dynamically loads the Java class 
"org.rexxla.bsf.engines.rexx.RexxEngine" which
extends the abstract class "org.apache.bsf.util.BSFEngineImpl" which  
implements  the
interface class "org.apache.bsf.BSFEngine"

  + an instance of "org.rexxla.bsf.engines.rexx.RexxEngine" gets 
created and the current set
of BSFManager registered beans will get registered with the 
RexxEngine instance

  + the RexxEngine instance will have its "initialize()" method invoked

  # the RexxEngine creates an instance of 
"org.rexxla.bsf.engines.rexx.RexxAndJava"
which serves as the interface for this combination of this 
BSFManager instance and
this RexxEngine instance

  * the very first time the 
"org.rexxla.bsf.engines.rexx.RexxAndJava" class gets
loaded its static constructor will - among other things - 
load the dynamic
BSF4ooRexx library using 
java.lang.System.loadLibrary(libName)

  * the constructor of 
"org.rexxla.bsf.engines.rexx.RexxAndJava" will use a native
method from the BSF4ooRexx dynamic library to initialize it

  # the RexxEngine registers the BSFManager's registered beans with 
its instance such
that a Rexx programmer can get at the Java parsed arguments (a 
Java array of type
String) with the statement:

argsByJava=bsf.lookupBean("allCommandLineArguments")   

  o the freshly created RexxEngine is then used to execute the supplied 
Rexx script (which will
be read from file), supplying the arguments to the Rexx script

  + at the very first time a Rexx script needs to be executed, the 
RexxEngine creates a
RexxInterpreter instance for that purpose, and reuses it each time 
Rexx code needs to
get executed via this RexxEngine

  + Remark: for Java programmers it is possible to configure the 
RexxInterpreter before the
very first usage (e.g. command handlers, exits, file extensions, 
etc.); the BSF4ooRexx
samples demonstrate this in form of nutshell samples

  o BSF.CLS when called or required from a Rexx script will check, whether 
Java is already
loaded (which in this use case will be the case) and if so, it does not 
load Java (even if a
Rexx programmer attempted to do that, a Rexx condition would be raised:
/BSF4ooRexx/routine/BsfLoadJava(), error 1.999: JVM is already loaded/);
BSF.CLS uses the external Rexx function BsfInvokedBy() which returns 
"0" if Java is not
loaded yet, "1" if Java loaded ooRexx, "2" if ooRexx loaded Java


---


Ad necessity to use "rexxj.sh"/ "rexxj2.sh" on MacOSX if running Rexx scripts 
that use any of the
Java GUI classes (awt, swing, JavaFX): unfortunately it is not possible to use 
the Java GUI classes
if Java gets loaded via Rexx. The reason being that an MacOSX event loop on 
MacOSX is not started
and present, 

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Jean Louis Faucher]

Guten tag Rony

Thanks a lot for the detailed explanations.
After setting BSF4Rexx_JavaStartupOptions as you explained, the 3rd test case 
is ok now.
More tests:

rexx 1-030_JavaVersion.rxj works correctly.

rexxj2.sh 1-010_HelloWorld.rxj did not work because of "Library not loaded: 
@rpath/librexx.4.dylib”
Should be found with DYLD_LIBRARY_PATH, but SIP deleted it:
- rexxj2.sh has a shebang line #!/bin/sh, which is protected by SIP
- the default java is protected by SIP.

After installing a local JDK (just unzip + set JAVA_HOME) and removing the 
shebang line of rexxj2.sh, that worked.

Side note about the shebang:
https://stackoverflow.com/questions/12296308/shell-script-working-fine-without-shebang-line-why
"An executable file without a shebang and not matching an binary executable 
format is run with sh."
sh is protected by SIP, so DYLD_LIBRARY_PATH should be deleted... But it’s not. 
At least under High Sierra.


Jean-Louis

> On 20 Jul 2021, at 13:55, Rony G. Flatscher  wrote:
> 
> Bonjour Jean-Louis,
> 
> thank you very much for looking into this!
> 
> In this use case in which rexx (because of BSF.CLS) loads libBSF4ooRexx.dylib 
> which then tries to locate and load libjvm.dylib et.al. the following would 
> apply:
> 
> rexx -e "call bsf.cls" 
> rexx -e "call bsf.cls; say .bsf4rexx~display.version; say 
> .java.lang.System~getProperty('java.library.path')"
> 
> rexx needs to be able to load libBSF4ooRexx.dylib
> 
> even if /opt/BSF4ooRexx existed rexx would not load anything from there as 
> that location is unknown to it
> 
> so either DYLD_LIBRARY_PATH needs to be set and point to the directory where 
> libBSF4ooRexx.dylib can be loaded from or place a symbolic link into 
> /usr/local/lib/libBSF4ooRexx.dylib such that the system can find and load it
> 
> once libBSF4ooRexx.dylib got loaded successfully from rexx the initialization 
> code ("prolog") of BSF.CLS will use it to see whether Java is already loaded 
> and if not load libjvm.dylib ("Java") at that point in time 
> 
> Since yesterday's version of libBSF4ooRexx.dylib ("BSF 641.20210719") MacOS 
> uses these places to find and load Java (libjvm.dylib):
> 
> /opt/BSF4ooRexx/libjvm.dylib 
> comment: if you used the install script a symbolic link to the Java version 
> that got used to install BSF4ooRexx will be created there, such that that 
> version (as long as it did not get updated) can be found and used; one could 
> delete this symbolic link to have the next searches for libjvm.dylib take 
> place:
> 
> if JAVA_HOME is defined then the following two attempts get carried out (this 
> got added this past weekend, a long standing intent)
> 
> ${JAVA_HOME}/lib/server/libjvm.dylib and if not found, then
> ${JAVA_HOME}/jre/lib/server/libjvm.dylib
> comment: starting with Java 9 (and then adjusted accordingly for Java 8 LTS) 
> the directory layout of Java got changed such that these two locations may 
> carry libjvm.dylib, depending on the installed Java versions 
> 
> /System/Library/Frameworks/JavaVM.framework/JavaVM
> comment: this location (Apple only) stems from the days when Apple supplied 
> its own Java which now seems to find the default installed Java 
> 
> libjvm.dylib
> comment: this causes the operating system lookup to be employed to locate 
> libjvm.dylib 
> 
> after loading Java eventually successfully from the Rexx side (which is the 
> case in all of your test cases!), the next step is using a Java class that 
> causes the Java BSF scripting support for Rexx to be initialized; in this 
> process libBSF4ooRexx.dylib needs to be loadable by the Java side which uses 
> java.library.path to search for libraries; if not found the error message 
> "[BSFManager.loadScriptingEngine()] unable to load language: rexx: 
> java.lang.UnsatisfiedLinkError: no BSF4ooRexx in java.library.path" gets 
> issued; e.g. (from above)
> 
> rexx -e "call bsf.cls; say .bsf4rexx~display.version; say 
> .java.lang.System~getProperty('java.library.path')"
> 
> will display the java.library.path in effect; since yesterday ("BSF 
> 641.20210719") the new default for Unix (including Apple) is defined to be 
> (note the current directory as the last one to look up): 
> 
>/opt/BSF4ooRexx:/usr/lib:/usr/lib64:/usr/local/lib:/usr/local/lib64:.
> 
> such that libBSF4ooRexx.dylib needs to be in one of these six locations 
> comment: it would be possible to set the value for java.library.path that 
> gets used by defining an environment symbol named 
> "BSF4Rexx_JavaStartupOptions" with the Java desired startup options (just 
> enter "java" in a Terminal to see the standard startup options), in this case 
> you would need to have also something like the following as sole entry or as 
> part of it (a supplied definition for java.library.path will inhibit 
> BSF4ooRexx to use its default):
> -Djava.library.path=the:paths:to:lookup:by:java
> If libBSF4ooRexx.dylib cannot be loaded by Java at this stage then the 
> loading of the Rexx script engine will cause 

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Rony G. Flatscher]

Bonjour Jean-Louis,

thank you /very /much for looking into this!

In this use case in which rexx (because of BSF.CLS) loads libBSF4ooRexx.dylib 
which then tries to
locate and loadlibjvm.dylib et.al. the following would apply:

  * rexx -e "call bsf.cls"
rexx -e "call bsf.cls; say .bsf4rexx~display.version; say
.java.lang.System~getProperty('java.library.path')"

  o rexx needs to be able to load libBSF4ooRexx.dylib

  o even if /opt/BSF4ooRexx existed rexx would not load anything from there 
as that location is
unknown to it

  o so either DYLD_LIBRARY_PATH needs to be set and point to the directory
wherelibBSF4ooRexx.dylib can be loaded from or place a symbolic link 
into
/usr/local/lib/libBSF4ooRexx.dylib such that the system can find and 
load it

  * oncelibBSF4ooRexx.dylib got loaded successfully from rexx the 
initialization code ("prolog") of
BSF.CLS will use it to see whether Java is already loaded and if not load 
libjvm.dylib ("Java")
at that point in time

  o Since yesterday's version of libBSF4ooRexx.dylib ("BSF 641.20210719") 
MacOS uses these
places to find and load Java (libjvm.dylib):

  + /opt/BSF4ooRexx/libjvm.dylib
  # comment: if you used the install script a symbolic link to the 
Java version that got
used to install BSF4ooRexx will be created there, such that 
that version (as long as
it did not get updated) can be found and used; one could delete 
this symbolic link
to have the next searches for libjvm.dylib take place:

  + if JAVA_HOME is defined then the following two attempts get carried 
out (this got added
this past weekend, a long standing intent)

  # ${JAVA_HOME}/lib/server/libjvm.dylib and if not found, then
  # ${JAVA_HOME}/jre/lib/server/libjvm.dylib
  * comment: starting with Java 9 (and then adjusted 
accordingly for Java 8 LTS) the
directory layout of Java got changed such that these two 
locations may carry
libjvm.dylib, depending on the installed Java versions

  + /System/Library/Frameworks/JavaVM.framework/JavaVM
  # comment: this location (Apple only) stems from the days when 
Apple supplied its own
Java which now seems to find the default installed Java

  + libjvm.dylib
  # comment: this causes the operating system lookup to be employed 
to locate libjvm.dylib

  o after loading Java eventually successfully from the Rexx side (which is 
the case in all of
your test cases!), the next step is using a Java class that causes the 
Java BSF scripting
support for Rexx to be initialized; in this process libBSF4ooRexx.dylib 
needs to be loadable
by the Java side which uses java.library.path to search for libraries; 
if not found the
error message "/[BSFManager.loadScriptingEngine()] unable to load 
language: rexx:
java.lang.UnsatisfiedLinkError: no BSF4ooRexx in java.library.path/" 
gets issued; e.g. (from
above)

    rexx -e "call bsf.cls; say .bsf4rexx~display.version; say
.java.lang.System~getProperty('java.library.path')"

will display the java.library.path in effect; since yesterday ("BSF 
641.20210719") the new
default for Unix (including Apple) is defined to be (note the current 
directory as the last
one to look up):

   /opt/BSF4ooRexx:/usr/lib:/usr/lib64:/usr/local/lib:/usr/local/lib64:.

such that libBSF4ooRexx.dylib needs to be in one of these six locations
  + comment: it would be possible to set the value for 
java.library.path that gets used by
defining an environment symbol named "BSF4Rexx_JavaStartupOptions" 
with the Java desired
startup options (just enter "java" in a Terminal to see the 
standard startup options),
in this case you would need to have also something like the 
following as sole entry or
as part of it (a supplied definition for java.library.path will 
inhibit BSF4ooRexx to
use its default):
-Djava.library.path=the:paths:to:lookup:by:java

If libBSF4ooRexx.dylib cannot be loaded by Java at this stage then the 
loading of the Rexx
script engine will cause an exception with the error message that you 
experience:

So with this context the test cases behave as expected.

---

Ad JAVA_HOME: this environment variable is very common in the Java world. It 
allows to have many
different Java versions on the same computer (there are zip archives for Java 
which one merely can
unzip) and use different Java versions in different processes. Changing 
JAVA_HOME then allows one to
test an application on a different/specific Java version.

---

A hint ad using BSF4ooRexx in a non-installed use-case: if you change into the 
unzipped directory of
the BSF4ooRexx 

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Jean Louis Faucher]

Guten tag Rony

I have the same error in the 3 test cases.

Note:
I don’t have a directory /opt/BSF4ooRex
I don’t have an environment variable with value /opt/BSF4ooRex


1st test case
Nothing in DYLD_LIBRARY_PATH
libBSF4ooRexx.dylib copied in oorexx5 lib

rexx -e “call bfs.cls”
[BSFManager.loadScriptingEngine()] unable to load language: rexx: 
java.lang.UnsatisfiedLinkError: no BSF4ooRexx in java.library.path

libBSF4ooRexx.dylib is correctly loaded from oorexx5 lib
dlopen(libBSF4ooRexx.dylib, 0x0001)
dyld: loaded: 
/local/rexx/oorexx/build/official/main/trunk/macos/clang/release/64/delivery/lib/libBSF4ooRexx.dylib

libjvm is not found
dlopen(/opt/BSF4ooRexx/libjvm.dylib, 0x0009)
  dlopen() failed, error: 'dlopen(/opt/BSF4ooRexx/libjvm.dylib, 9): image not 
found'


2nd test case
remove libBSF4ooRexx.dylib from oorexx5 lib
Put my install directory of libBSF4ooRexx.dylib in DYLD_LIBRARY_PATH
libjvm directory not put in DYLD_LIBRARY_PATH

rexx -e “call bfs.cls”
[BSFManager.loadScriptingEngine()] unable to load language: rexx: 
java.lang.UnsatisfiedLinkError: no BSF4ooRexx in java.library.path

libBSF4ooRexx.dylib is correctly loaded from my install directory
dlopen(libBSF4ooRexx.dylib, 0x0001)
dyld: loaded: 
/local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210719-beta/bsf4oorexx/install/64/libBSF4ooRexx.dylib

libjvm is not found
dlopen(/opt/BSF4ooRexx/libjvm.dylib, 0x0009)
  dlopen() failed, error: 'dlopen(/opt/BSF4ooRexx/libjvm.dylib, 9): image not 
found'


3rd test case
Add libjvm directory in DYLD_LIBRARY_PATH

rexx -e “call bfs.cls”
[BSFManager.loadScriptingEngine()] unable to load language: rexx: 
java.lang.UnsatisfiedLinkError: no BSF4ooRexx in java.library.path

libBSF4ooRexx.dylib is correctly loaded from my install directory
dlopen(libBSF4ooRexx.dylib, 0x0001)
dyld: loaded: 
/local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210719-beta/bsf4oorexx/install/64/libBSF4ooRexx.dylib

libjvm is loaded (despite the path passed to dlopen)
dlopen
x/libjvm.dylib, 0x0009)
dyld: loaded: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/lib/server/libjvm.dylib


> On 19 Jul 2021, at 18:01, Rony G. Flatscher  wrote:
> 
> Bonsoir Jean-Louis,
> 
> today I finished up a new version of BSF4ooRexx that should work in this 
> use-case. You can get it from 
> 
>  
> .
>  (This version got tested against MacOS, Linux and Windows.)
> If you test this version in your environment then please let me know of any 
> difficulties or problems that you encounter. (This version of BSF4ooRexx is 
> still supposed to be usable against ooRexx 4.1 and higher, however 5.0 is 
> *strongly* advised due to its stable multithreadingness. For that reason some 
> JavaFX samples will deny being run on ooRexx prior to 5.0. This is another 
> reason for me to ask for a release version of ooRexx 5.0 beta *as is*, as it 
> is much stabler, faster and powerful than any earlier version of ooRexx.)
> 
> ---rony
> 
> On 18.07.2021 00:02, Jean Louis Faucher wrote:
>> Gute nacht Rony
>> 
>> I have an atypical configuration where I use DYLD_LIBRARY_PATH to locate the 
>> BSF4OORexx library.
>> This is because I don’t “install” BSF4OORexx, I just unzip the delivery, 
>> copy and rename the libraries to bsf4oorex/install/64
>> With this configuration, your test cases are working (not saying this is the 
>> solution).
>> 
>> 
>> If I don’t set DYLD_LIBRARY_PATH, I get the same error than yours.
>> 
>> I compared the output of the next command in both cases
>> DYLD_PRINT_LIBRARIES="1" DYLD_PRINT_APIS="1" rexx -e "call bsf.cls”
>> 
>> In the working session:
>> dlopen(librexxapi.dylib, 0x0001)
>>   dlopen(librexxapi.dylib) ==> 0x10936da50
>> dlopen(libBSF4ooRexx.dylib, 0x0001)
>> dyld: loaded: 
>> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/install/64/libBSF4ooRexx.dylib
>> dyld: loaded: 
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/lib/server/libjvm.dylib
>> dyld: loaded: /usr/lib/libstdc++.6.0.9.dylib
>> 
>> In the not working session:
>> dlopen(librexxapi.dylib, 0x0001)
>>   dlopen(librexxapi.dylib) ==> 0x10dd4a990
>> dlopen(libBSF4ooRexx.dylib, 0x0001)
>>   dlopen() failed, error: 'dlopen(libBSF4ooRexx.dylib, 1): image not found'
>> dlopen(/usr/lib/libBSF4ooRexx.dylib, 0x0001)
>>   dlopen() failed, error: 'dlopen(/usr/lib/libBSF4ooRexx.dylib, 1): image 
>> not found'
>>919 *-* ::routine xBSF   PUBLIC   EXTERNAL "LIBRARY 
>> BSF4ooRexx BSF "
>>  1 *-* call bsf.cls
>> Error 98 running 
>> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/BSF.CLS
>>  line 919:  Execution error.
>> Error 98.903:  Unable to load library "BSF4ooRexx".
>> 
>> I find 

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Rony G. Flatscher]

Bonsoir Jean-Louis,

today I finished up a new version of BSF4ooRexx that should work in this 
use-case. You can get it
from
.
(This version got tested against MacOS, Linux and Windows.)

If you test this version in your environment then please let me know of any 
difficulties or problems
that you encounter. (This version of BSF4ooRexx is still supposed to be usable 
against ooRexx 4.1
and higher, however 5.0 is *strongly* advised due to its stable 
multithreadingness. For that reason
some JavaFX samples will deny being run on ooRexx prior to 5.0. This is another 
reason for me to ask
for a release version of ooRexx 5.0 beta *as is*, as it is much stabler, faster 
and powerful than
any earlier version of ooRexx.)

---rony


On 18.07.2021 00:02, Jean Louis Faucher wrote:
> Gute nacht Rony
>
> I have an atypical configuration where I use DYLD_LIBRARY_PATH to locate the 
> BSF4OORexx library.
> This is because I don’t “install” BSF4OORexx, I just unzip the delivery, copy 
> and rename the
> libraries to bsf4oorex/install/64
> With this configuration, your test cases are working (not saying this is the 
> solution).
>
>
> If I don’t set DYLD_LIBRARY_PATH, I get the same error than yours.
>
> I compared the output of the next command in both cases
> DYLD_PRINT_LIBRARIES="1" DYLD_PRINT_APIS="1" rexx -e "call bsf.cls”
>
> In the working session:
> dlopen(librexxapi.dylib, 0x0001)
>   dlopen(librexxapi.dylib) ==> 0x10936da50
> dlopen(libBSF4ooRexx.dylib, 0x0001)
> dyld: loaded:
> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/install/64/libBSF4ooRexx.dylib
> dyld: loaded:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/lib/server/libjvm.dylib
> dyld: loaded: /usr/lib/libstdc++.6.0.9.dylib
>
> In the not working session:
> dlopen(librexxapi.dylib, 0x0001)
>   dlopen(librexxapi.dylib) ==> 0x10dd4a990
> dlopen(libBSF4ooRexx.dylib, 0x0001)
>   dlopen() failed, error: 'dlopen(libBSF4ooRexx.dylib, 1): image not found'
> dlopen(/usr/lib/libBSF4ooRexx.dylib, 0x0001)
>   dlopen() failed, error: 'dlopen(/usr/lib/libBSF4ooRexx.dylib, 1): image not 
> found'
>    919 *-* ::routine xBSF                   PUBLIC   EXTERNAL "LIBRARY 
> BSF4ooRexx BSF            
>     "
>      1 *-* call bsf.cls
> Error 98 running 
> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/BSF.CLS
> line 919:  Execution error.
> Error 98.903:  Unable to load library "BSF4ooRexx".
>
> I find "/usr/lib” in one file:
> SysLibrary.cpp
>
>     // try loading directly
>     libraryHandle = dlopen(nameBuffer, RTLD_LAZY);
>     // if not found, then try from /usr/lib
>     if (libraryHandle == NULL)
>     {
>         sprintf(nameBuffer, "/usr/lib/lib%s%s", name, ORX_SHARED_LIBRARY_EXT);
>         libraryHandle = dlopen(nameBuffer, RTLD_LAZY);
>
> The part to investigate is how to make the first dlopen work without using 
> DYLD_LIBRARY_PATH:
> If I put libBSF4ooRexx.dylib in the lib folder of oorexx then it works 
> (RPATH).
> If I put libBSF4ooRexx.dylib in the current directory then it works (see man 
> dlopen).
> I don’t know if other solutions are possible for the first dlopen
>
> The other solution could to add “/usr/local/lib” as 2nd fallback.
> But that brings the question of order.
> Maybe a more general solution would be to use an environment variable like 
> REXX_LIBRARY_PATH.
> We have already REXX_PATH for locating the rexx files.
>
>
> Jean-Louis
>
>> On 17 Jul 2021, at 21:56, Rony G. Flatscher > > wrote:
>>
>> On MacOSX the BSF4ooRexx library is named "libBSF4ooRexx.dylib".
>>
>> Testing the changes in the BSF4ooRexx installation scripts and then testing 
>> the resulting
>> installations surfaced a problem on MacOSX: libBSF4ooRexx.dylib can be 
>> loaded via Java and used
>> successfully.
>>
>> However, loading "libBSF4ooRexx.dylib" via ooRexx is not successful. To be 
>> precise, the
>>
>> ::routine xbsf PUBLIC EXTERNAL "LIBRARY BSF4ooRexx BSF"
>>
>> fails with the execution error:
>>
>> Error 98.903: Unable to load library "BSF4ooRexx".
>>
>> Here two rexxtry.rex sessions, the first one is run with "rexxj.sh 
>> /usr/local/bin/rexxtry.rex"
>> which loads a Java program that will load the BSF4ooRexx library to then 
>> execute
>> /usr/local/bin/rexxtry.rex. This is followed by a "rexx rexxtry.rex" session 
>> which yields the
>> exection error. This is then followed by the "rexx -e" statement which does 
>> a call BSF.CLS which
>> then shows the full error message:
>>
>> rony@ronymac2014 ~ % rexxj.sh /usr/local/bin/rexxtry.rex 
>> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 12
>> Jul 2021 rexxtry.rex lets you interactively try REXX statements. Each 
>> string is executed when
>> you hit Enter. Enter 'call tell' for a description of the features. Go 
>> on - try a few...
>> Enter 'exit' to end. 

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Rony G. Flatscher]

Bonsoir Jean-Louis,

sorry, missed to follow your advice:

On 18.07.2021 16:21, Jean Louis Faucher wrote:
... cut ...

> Tried it on 11.4, but unfortunately does not work. It may have to do with  
>
> Indeed, it worked for me because I had the path to libjvm.dylib in 
> DYLD_LIBRARY_PATH
>
> By the way, you could check if DYLD_LIBRARY_PATH works with your system, when 
> not deleted… Remove
> the symbolic link you created in oorexx lib, and try
>
> DYLD_LIBRARY_PATH=“directory of ibjvm” rexx -e “call bfs.cls"

... cut ...

Had to change the example (would find libjvm.dylib on Apple anyway), but moving 
away from
/opt/BSF4ooRexx such that "libBSF4ooRexx.dylib" won't be locatable by Java. 
Then doing:

DYLD_LIBRARY_PATH=/opt/BSF4ooRexx rexx -e “call bfs.cls;say 
.bsf4rexx~display.version"

would work!

Works also, if doing something like

export DYLD_LIBRARY_PATH=/opt/BSF4ooRexx
rexx -e “call bfs.cls;say .bsf4rexx~display.version"

Java will add the directories from DYLD_LIBRARY_PATH to its "java.library.path" 
and therefore become
able to find libBSF4ooRexx.dylib, so DYLD_LIBRARY_PATH in these use cases is 
fully functional on Apple!

Thank you again for your help, also for this suggestion, which makes it clear 
to me in which context
DYLD* is still functional! :)

---rony


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

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Rony G. Flatscher]

Bonjour Jean-Louis,

thank you!

On 18.07.2021 16:21, Jean Louis Faucher wrote:
... cut useful tips ...
>>
>> This is strange as BSF4ooRexx explicitly looks in different locations for 
>> libjvm.dylib and is not
>> compiled with rpath in effect.
>>
> If I understand correctly, you load dynamically libjvm using dlopen.
> In this case, is it possible to remove completely the dependency on libjvm 
> when linking ?

Indeed. Intended to send an e-mail, already drafted almost two hours ago:


But before sending I ran into a Java problem on the Mac which I have been now 
debugging for almost
two hours: java.library.path in Java 11 defines:
"/Users/rony/library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:."
(note the trailing dot), which are the directories Java looks up to find 
dynamic libraries when
needint to explicitly load one.

Java 14 seems to not honor /usr/lib nor /usr/local/lib on Mac so misses loading 
libBSF4ooRexx.dylib
to get access to its native functions (the library is for both, ooRexx and 
Java). It may be possible
that later versions of Java are honoring /usr/local/lib which would resolve the 
issue (just no time
to test it at the moment, needless to say).

So "rexx -e 'call bsf.cls'" works, but only when issued from "/opt/BSF4ooRexx" 
as current directory
such that it gets searched. "rexxj.sh" works from anywhere as it sets the 
java.library.path explicitly.

Nevertheless, the reported issue got solved (that ooRexx was not able to load 
libBSF4ooRexx.dylib)
by not linking libBSF4ooRexx.dylib against libjvm.dylib. Will adjust all the 
makefiles accordingly
and test them.

---rony


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

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Jean Louis Faucher]

Guten tag Rony

> It seems that at least with macOS Big Sur (version 11.4) DYLD_LIBRARY_PATH 
> does not work anymore (for "security reasons")
> 

Well, when this variable is not deleted by the system, it works as expected.
But ok, the point here is to work without this variable.

>> If I put libBSF4ooRexx.dylib in the lib folder of oorexx then it works 
>> (RPATH).
> Tried it on 11.4, but unfortunately does not work. It may have to do with  
> 

Indeed, it worked for me because I had the path to libjvm.dylib in 
DYLD_LIBRARY_PATH

By the way, you could check if DYLD_LIBRARY_PATH works with your system, when 
not deleted… Remove the symbolic link you created in oorexx lib, and try

DYLD_LIBRARY_PATH=“directory of ibjvm” rexx -e “call bfs.cls"

> This is strange as BSF4ooRexx explicitly looks in different locations for 
> libjvm.dylib and is not compiled with rpath in effect.
> 
If I understand correctly, you load dynamically libjvm using dlopen.
In this case, is it possible to remove completely the dependency on libjvm when 
linking ?



> On 18 Jul 2021, at 15:11, Rony G. Flatscher  wrote:
> 
> Bonjour Jean-Louis,
> On 18.07.2021 00:02, Jean Louis Faucher wrote:
>> I have an atypical configuration where I use DYLD_LIBRARY_PATH to locate the 
>> BSF4OORexx library.
>> This is because I don’t “install” BSF4OORexx, I just unzip the delivery, 
>> copy and rename the libraries to bsf4oorex/install/64
>> With this configuration, your test cases are working (not saying this is the 
>> solution).
> It seems that at least with macOS Big Sur (version 11.4) DYLD_LIBRARY_PATH 
> does not work anymore (for "security reasons"), as well as anything not 
> rooted on the Mac computer gets quarantined (got the same problem as with 
> ooRexx and BSF4ooRexx from the Internet when I installed OpenOffice 4.1.10 
> yesterday), so one needs to remove the com.apple.quarantine extended 
> attribute with xattr before the packages become operable again. (Personally, 
> I think that it is high time that someone has to stop Apple to deprive the 
> owners of Apple computers and also the Apple software developers.)
> 
> Cf. e.g.  
>  at the bottom where 
> LD_LIBRARY_PATH and anything starting with DYLD_LIBRARY_PATH gets ignored all 
> of a sudden, also 
> 
>  
> 
>  at the bottom. Some background here: 
>  
> , here the authorative 
> description: 
> 
>  
> .
>  
> [A few months ago I read that if one would run a copy of the shell program 
> from the user location then it would work. Tried it, but  could not get it to 
> work.]
>> If I don’t set DYLD_LIBRARY_PATH, I get the same error than yours.
>> 
>> I compared the output of the next command in both cases
>> DYLD_PRINT_LIBRARIES="1" DYLD_PRINT_APIS="1" rexx -e "call bsf.cls”
>> 
>> In the working session:
>> dlopen(librexxapi.dylib, 0x0001)
>>   dlopen(librexxapi.dylib) ==> 0x10936da50
>> dlopen(libBSF4ooRexx.dylib, 0x0001)
>> dyld: loaded: 
>> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/install/64/libBSF4ooRexx.dylib
>> dyld: loaded: 
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/lib/server/libjvm.dylib
>> dyld: loaded: /usr/lib/libstdc++.6.0.9.dylib
>> 
>> In the not working session:
>> dlopen(librexxapi.dylib, 0x0001)
>>   dlopen(librexxapi.dylib) ==> 0x10dd4a990
>> dlopen(libBSF4ooRexx.dylib, 0x0001)
>>   dlopen() failed, error: 'dlopen(libBSF4ooRexx.dylib, 1): image not found'
>> dlopen(/usr/lib/libBSF4ooRexx.dylib, 0x0001)
>>   dlopen() failed, error: 'dlopen(/usr/lib/libBSF4ooRexx.dylib, 1): image 
>> not found'
>>919 *-* ::routine xBSF   PUBLIC   EXTERNAL "LIBRARY 
>> BSF4ooRexx BSF "
>>  1 *-* call bsf.cls
>> Error 98 running 
>> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/BSF.CLS
>>  line 919:  Execution error.
>> Error 98.903:  Unable to load library "BSF4ooRexx".
>> 
> Wow, learned about "DYLD_PRINT_LIBRARIES" and "DYLD_PRINT_APIS", very useful!
>> I find "/usr/lib” in one file:
>> SysLibrary.cpp
>> 
>> // try loading directly
>> libraryHandle = dlopen(nameBuffer, RTLD_LAZY);
>> // if not found, then try from /usr/lib
>> if (libraryHandle == NULL)
>> {
>> sprintf(nameBuffer, "/usr/lib/lib%s%s", name, 
>> 

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Rony G. Flatscher]

Bonjour Jean-Louis,

On 18.07.2021 00:02, Jean Louis Faucher wrote:
> I have an atypical configuration where I use DYLD_LIBRARY_PATH to locate the 
> BSF4OORexx library.
> This is because I don’t “install” BSF4OORexx, I just unzip the delivery, copy 
> and rename the
> libraries to bsf4oorex/install/64
> With this configuration, your test cases are working (not saying this is the 
> solution).

It seems that at least with macOS Big Sur (version 11.4) DYLD_LIBRARY_PATH does 
not work anymore
(for "security reasons"), as well as anything not rooted on the Mac computer 
gets quarantined (got
the same problem as with ooRexx and BSF4ooRexx from the Internet when I 
installed OpenOffice 4.1.10
yesterday), so one needs to remove the com.apple.quarantine extended attribute 
with xattr before the
packages become operable again. (Personally, I think that it is high time that 
someone has to stop
Apple to deprive the owners of Apple computers and also the Apple software 
developers.)

Cf. e.g.  at the bottom where 
LD_LIBRARY_PATH and
anything starting with DYLD_LIBRARY_PATH gets ignored all of a sudden, also

at the bottom. Some background here: 
, here the
authorative description:
.


[A few months ago I read that if one would run a copy of the shell program from 
the user location
then it would work. Tried it, but  could not get it to work.]

> If I don’t set DYLD_LIBRARY_PATH, I get the same error than yours.
>
> I compared the output of the next command in both cases
> DYLD_PRINT_LIBRARIES="1" DYLD_PRINT_APIS="1" rexx -e "call bsf.cls”
>
> In the working session:
> dlopen(librexxapi.dylib, 0x0001)
>   dlopen(librexxapi.dylib) ==> 0x10936da50
> dlopen(libBSF4ooRexx.dylib, 0x0001)
> dyld: loaded:
> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/install/64/libBSF4ooRexx.dylib
> dyld: loaded:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/lib/server/libjvm.dylib
> dyld: loaded: /usr/lib/libstdc++.6.0.9.dylib
>
> In the not working session:
> dlopen(librexxapi.dylib, 0x0001)
>   dlopen(librexxapi.dylib) ==> 0x10dd4a990
> dlopen(libBSF4ooRexx.dylib, 0x0001)
>   dlopen() failed, error: 'dlopen(libBSF4ooRexx.dylib, 1): image not found'
> dlopen(/usr/lib/libBSF4ooRexx.dylib, 0x0001)
>   dlopen() failed, error: 'dlopen(/usr/lib/libBSF4ooRexx.dylib, 1): image not 
> found'
>    919 *-* ::routine xBSF                   PUBLIC   EXTERNAL "LIBRARY 
> BSF4ooRexx BSF            
>     "
>      1 *-* call bsf.cls
> Error 98 running 
> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/BSF.CLS
> line 919:  Execution error.
> Error 98.903:  Unable to load library "BSF4ooRexx".
>
Wow, learned about "DYLD_PRINT_LIBRARIES" and "DYLD_PRINT_APIS", very useful!

> I find "/usr/lib” in one file:
> SysLibrary.cpp
>
>     // try loading directly
>     libraryHandle = dlopen(nameBuffer, RTLD_LAZY);
>     // if not found, then try from /usr/lib
>     if (libraryHandle == NULL)
>     {
>         sprintf(nameBuffer, "/usr/lib/lib%s%s", name, ORX_SHARED_LIBRARY_EXT);
>         libraryHandle = dlopen(nameBuffer, RTLD_LAZY);
>
> The part to investigate is how to make the first dlopen work without using 
> DYLD_LIBRARY_PATH:

Indeed.

> If I put libBSF4ooRexx.dylib in the lib folder of oorexx then it works 
> (RPATH).

Tried it on 11.4, but unfortunately does not work. It may have to do with 

... cut ...

While adding debug statements to SysLibrary.cpp (adding "/usr/local/lib" as 
another explicit
location) and using dlerror() I just got: "Library not loaded: 
"@rpath/libjvm.dylib | Referenced
from: /usr/local/lib/libBSF4ooRexx.dylib | Reason: image not found!".

This is strange as BSF4ooRexx explicitly looks in different locations for 
libjvm.dylib and is not
compiled with rpath in effect. And the first location 
("/opt/BSF4ooRexx/libjvm.dylib") exists in
this case (as a symbolic link) such that dlopen("/opt/BSF4ooRexx/libjvm.dylib", 
RTLD_LAZY |
RTLD_GLOBAL) should succeed. It seems that somehow ooRexx loading 
libBSF4ooRexx.dylib also causes an
error as "@rpath/libjvm.dylib" would not exist.

Adding a symbolic link to libjvm.dylib to ooRexx' lib directory indeed makes 
libBSF4ooRexx.dylib
load successfully! Interestingly, the code in BSF4ooRexx gets excercised then
"/opt/BSF4ooRexx/libjvm.dylib" gets loaded and not "@rpath/libjvm.dylib"!

Or with other words: ooRexx will find "libBSF4ooRexx.dylib", but cannot load it 
successfully because
dlopen() is not able to find "@rpath/libjvm.dylib" (which is somewhere else and 
will be searched for
in different locations). But I am stumped that that would be the case 

Re: [Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Jean Louis Faucher]

Gute nacht Rony

I have an atypical configuration where I use DYLD_LIBRARY_PATH to locate the 
BSF4OORexx library.
This is because I don’t “install” BSF4OORexx, I just unzip the delivery, copy 
and rename the libraries to bsf4oorex/install/64
With this configuration, your test cases are working (not saying this is the 
solution).


If I don’t set DYLD_LIBRARY_PATH, I get the same error than yours.

I compared the output of the next command in both cases
DYLD_PRINT_LIBRARIES="1" DYLD_PRINT_APIS="1" rexx -e "call bsf.cls”

In the working session:
dlopen(librexxapi.dylib, 0x0001)
  dlopen(librexxapi.dylib) ==> 0x10936da50
dlopen(libBSF4ooRexx.dylib, 0x0001)
dyld: loaded: 
/local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/install/64/libBSF4ooRexx.dylib
dyld: loaded: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/lib/server/libjvm.dylib
dyld: loaded: /usr/lib/libstdc++.6.0.9.dylib

In the not working session:
dlopen(librexxapi.dylib, 0x0001)
  dlopen(librexxapi.dylib) ==> 0x10dd4a990
dlopen(libBSF4ooRexx.dylib, 0x0001)
  dlopen() failed, error: 'dlopen(libBSF4ooRexx.dylib, 1): image not found'
dlopen(/usr/lib/libBSF4ooRexx.dylib, 0x0001)
  dlopen() failed, error: 'dlopen(/usr/lib/libBSF4ooRexx.dylib, 1): image not 
found'
   919 *-* ::routine xBSF   PUBLIC   EXTERNAL "LIBRARY 
BSF4ooRexx BSF "
 1 *-* call bsf.cls
Error 98 running 
/local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/BSF.CLS 
line 919:  Execution error.
Error 98.903:  Unable to load library "BSF4ooRexx".

I find "/usr/lib” in one file:
SysLibrary.cpp

// try loading directly
libraryHandle = dlopen(nameBuffer, RTLD_LAZY);
// if not found, then try from /usr/lib
if (libraryHandle == NULL)
{
sprintf(nameBuffer, "/usr/lib/lib%s%s", name, ORX_SHARED_LIBRARY_EXT);
libraryHandle = dlopen(nameBuffer, RTLD_LAZY);

The part to investigate is how to make the first dlopen work without using 
DYLD_LIBRARY_PATH:
If I put libBSF4ooRexx.dylib in the lib folder of oorexx then it works (RPATH).
If I put libBSF4ooRexx.dylib in the current directory then it works (see man 
dlopen).
I don’t know if other solutions are possible for the first dlopen

The other solution could to add “/usr/local/lib” as 2nd fallback.
But that brings the question of order.
Maybe a more general solution would be to use an environment variable like 
REXX_LIBRARY_PATH.
We have already REXX_PATH for locating the rexx files.


Jean-Louis

> On 17 Jul 2021, at 21:56, Rony G. Flatscher  wrote:
> 
> On MacOSX the BSF4ooRexx library is named "libBSF4ooRexx.dylib". 
> Testing the changes in the BSF4ooRexx installation scripts and then testing 
> the resulting installations surfaced a problem on MacOSX: libBSF4ooRexx.dylib 
> can be loaded via Java and used successfully. 
> However, loading "libBSF4ooRexx.dylib" via ooRexx is not successful. To be 
> precise, the 
> ::routine xbsf PUBLIC EXTERNAL "LIBRARY BSF4ooRexx BSF"
> fails with the execution error:
> 
> Error 98.903: Unable to load library "BSF4ooRexx".
> Here two rexxtry.rex sessions, the first one is run with "rexxj.sh 
> /usr/local/bin/rexxtry.rex" which loads a Java program that will load the 
> BSF4ooRexx library to then execute /usr/local/bin/rexxtry.rex. This is 
> followed by a "rexx rexxtry.rex" session which yields the exection error. 
> This is then followed by the "rexx -e" statement which does a call BSF.CLS 
> which then shows the full error message:
> 
> rony@ronymac2014 ~ % rexxj.sh /usr/local/bin/rexxtry.rex 
> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 12 Jul 2021
>   rexxtry.rex lets you interactively try REXX statements.
> Each string is executed when you hit Enter.
> Enter 'call tell' for a description of the features.
>   Go on - try a few...Enter 'exit' to end.
> call bsf.cls
>   .. rexxtry.rex on DARWIN
> say .bsf4rexx~display.version
> ooRexx 5.0.0 r12280 (12 Jul 2021) / BSF 641.20210715 / Java 1.8.0_162, 64-bit 
> / Darwin 20.5.0
>   .. rexxtry.rex on DARWIN
> exit
> rony@ronymac2014 ~ % rexxtry.rex 
> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 12 Jul 2021
>   rexxtry.rex lets you interactively try REXX statements.
> Each string is executed when you hit Enter.
> Enter 'call tell' for a description of the features.
>   Go on - try a few...Enter 'exit' to end.
> call bsf.cls
>   Oooops ! ... try again. Execution error.
>   Unable to load library "BSF4ooRexx".
>   rc = 98.903 .. rexxtry.rex on DARWIN
> exit
> rony@ronymac2014 ~ % rexx -e "call bsf.cls"
>919 *-* ::routine xBSF   PUBLIC   EXTERNAL "LIBRARY 
> BSF4ooRexx BSF "
>  1 *-* call bsf.cls
> Error 98 running /usr/local/bin/BSF.CLS line 919:  Execution error.
> Error 98.903:  Unable to load library 

[Oorexx-devel] MaxOS: Java can load libBSF4ooRexx.dylib, ooRexx cannot

[Rony G. Flatscher]

On MacOSX the BSF4ooRexx library is named "libBSF4ooRexx.dylib".

Testing the changes in the BSF4ooRexx installation scripts and then testing the 
resulting
installations surfaced a problem on MacOSX: libBSF4ooRexx.dylib can be loaded 
via Java and used
successfully.

However, loading "libBSF4ooRexx.dylib" via ooRexx is not successful. To be 
precise, the

::routine xbsf PUBLIC EXTERNAL "LIBRARY BSF4ooRexx BSF"

fails with the execution error:

Error 98.903: Unable to load library "BSF4ooRexx".

Here two rexxtry.rex sessions, the first one is run with "rexxj.sh 
/usr/local/bin/rexxtry.rex" which
loads a Java program that will load the BSF4ooRexx library to then execute
/usr/local/bin/rexxtry.rex. This is followed by a "rexx rexxtry.rex" session 
which yields the
exection error. This is then followed by the "rexx -e" statement which does a 
call BSF.CLS which
then shows the full error message:

rony@ronymac2014 ~ % rexxj.sh /usr/local/bin/rexxtry.rex 
REXX-ooRexx_5.0.0(MT)_64-bit 6.05 12
Jul 2021 rexxtry.rex lets you interactively try REXX statements. Each 
string is executed when
you hit Enter. Enter 'call tell' for a description of the features. Go on - 
try a few... Enter
'exit' to end. call bsf.cls .. 
rexxtry.rex on DARWIN
say .bsf4rexx~display.version ooRexx 5.0.0 r12280 (12 Jul 2021) / BSF 
641.20210715 / Java
1.8.0_162, 64-bit / Darwin 20.5.0 
.. rexxtry.rex on
DARWIN exit
rony@ronymac2014 ~ % rexxtry.rex REXX-ooRexx_5.0.0(MT)_64-bit 6.05 12 Jul 
2021 rexxtry.rex lets
you interactively try REXX statements. Each string is executed when you hit 
Enter. Enter 'call
tell' for a description of the features. Go on - try a few... Enter 'exit' 
to end. call bsf.cls
Oooops ! ... try again. Execution error. Unable to load library 
"BSF4ooRexx". rc = 98.903
.. rexxtry.rex on DARWIN exit
*rony@ronymac2014 ~ % rexx -e "call bsf.cls"919 *-* ::routine xBSF 
PUBLIC EXTERNAL "LIBRARY
BSF4ooRexx BSF "1 *-* call bsf.clsError 98 running 
/usr/local/bin/BSF.CLS line 919:
Execution error.Error 98.903: Unable to load library "BSF4ooRexx".*
rony@ronymac2014 ~ % 

It is the first of five external "LIBRARY BSF4ooRexx XXX" directives (these 
five external function
names are: "BSF", "BsfCreateRexxProxy", "BsfRexxProxy", "BsfUninit4JavaBean", 
"BsfLoadJava"). So it
is the first time the "BSF4ooRexx" library needs to be proecessed by ooRexx in 
this way.

This was tested against the Sourceforge version of ooRexx r12280, July 12 2021.

Is there anything I could do to help pinpoint the problem?

---rony


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