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 <rony.flatsc...@wu.ac.at
>> <mailto:rony.flatsc...@wu.ac.at>> 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
>> "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, such that awt/swing/JavaFX cannot be intertwined with
>> the MacOS event loop.
>> [If ooRexx was somehow able to initialize this support one could use rexx to
>> run the Rexx scripts
>> on this platform as well. If anyone has any ideas, knowledge or experimental
>> code, I would really
>> appreciate it a lot to learn about them! It may be even some silly little
>> piece of "how-to" to
>> make this work.]
>>
>> However starting Java first initializes its runtime environment in a way
>> that it allows for using
>> the MacOSX event loop and therfore its GUI classes. Therefore "rexxj.sh" on
>> MacOSX is mandatory
>> in the case the Rexx program uses any of the GUI classes. This is also the
>> reason why "rexxj.sh"
>> gets associated with the Rexx scripts on MacOSX.
>>
>> ---rony
>>
>>
>>>
>>> Side note about the shebang:
>>> https://stackoverflow.com/questions/12296308/shell-script-working-fine-without-shebang-line-why
>>> <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 <rony.flatsc...@wu.ac.at
>>>> <mailto:rony.flatsc...@wu.ac.at>> 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 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
