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 zip-archive, i.e. "bsf4oorexx/install" and
* run "setupBSF.rex" in "bsf4oorexx/install", then the installation and
companion scripts get
created and a symbolic link to the system's libBSF4ooRexx.dylib (there may
be different on
different Linuxes) gets created in the unzipped "bsf4oorexx" directory; the
created script
"setEnvironment4BSF.sh" will allow you to temporarily set your session's
environment to use this
version of BSF4ooRexx, just source it and the appropriate CLASSPATH
environment variable will be set
o if you have OpenOffice or LibreOffice installed and want to use it for
the AOO/LO Rexx
sample and utility scripts (file extensions ".rxo", rexx script for
OpenOffice), then run
"setupOOo.rex" in "bsf4oorexx/install" which will also create a
"setEnvironment4OOo.sh"
which you can source (CLASSPATH gets changed to point to the AOO/LO jar
files that allow to
use AOO/LO via BSF4ooRexx)
* if you then use PATH and DYLD_LIBRARY_PATH to point to the unzipped
"bsf4oorexx" directory you
should be able to run all ooRexx scripts of BSF4ooRexx in that session.
Again, many thanks for taking the time to test this version!
---rony
On 20.07.2021 11:36, Jean Louis Faucher wrote:
> 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, 0x00000001)
> 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, 0x00000009)
> 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, 0x00000001)
> dyld: loaded:
> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210719-beta/bsf4oorexx/install/64/libBSF4ooRexx.dylib
>
> libjvm is not found
> dlopen(/opt/BSF4ooRexx/libjvm.dylib, 0x00000009)
> 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, 0x00000001)
> 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, 0x00000009)
> 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 <rony.flatsc...@wu.ac.at
>> <mailto:rony.flatsc...@wu.ac.at>> 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
>> <https://sourceforge.net/projects/bsf4oorexx/files/beta/20200928/BSF4ooRexx_install_v641-20210719-beta.zip/download>.
>> (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, 0x00000001)
>>> dlopen(librexxapi.dylib) ==> 0x10936da50
>>> dlopen(libBSF4ooRexx.dylib, 0x00000001)
>>> 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, 0x00000001)
>>> dlopen(librexxapi.dylib) ==> 0x10dd4a990
>>> dlopen(libBSF4ooRexx.dylib, 0x00000001)
>>> dlopen() failed, error: 'dlopen(libBSF4ooRexx.dylib, 1): image not found'
>>> dlopen(/usr/lib/libBSF4ooRexx.dylib, 0x00000001)
>>> 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 <rony.flatsc...@wu.ac.at
>>>> <mailto:rony.flatsc...@wu.ac.at>> 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
>>>> "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?
>>>>
>>>> ---
>>>>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
