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 <rony.flatsc...@wu.ac.at> 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 <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" >>> >>> 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 >>> RexxInterpreter before the very first usage (e.g. command handlers, exits, >>> file extensions, etc.); the BSF4ooRexx samples demonstrate this in form of >>> nutshell samples >>> >>> 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 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 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 >>>>> >>>>> 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> >>>>>>> >>>>>>> <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
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
