Bonsoir Jean Louis,
thank you very much for your hints!
On 19.03.2021 18:46, Jean Louis Faucher wrote:
> The @path comes the dylib you link with.
> (LC_ID_DYLIB)
>
> otool -D librexx.dylib: @rpath/librexx.4.dylib
> otool -D librexxapi.dylib: @rpath/librexxapi.4.dylib
>
> Your library embeds this dependency:
> otool -L libBSF4ooRexx.dylib
> ./tmp/libBSF4ooRexx.dylib-64-x86_64 (compatibility version 0.0.0,
> current version 0.0.0)
> @rpath/librexx.4.dylib (compatibility version 4.0.0, current version
> 0.0.0)
> @rpath/librexxapi.4.dylib (compatibility version 4.0.0, current version
> 0.0.0)
> /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM
> (compatibility version 1.0.0, current version 1.0.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 400.9.4)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.250.1)
>
> In rexxj.sh, you declare -Djava.library.path="$DYLD_LIBRARY_PATH"
No, not that is not the case. On Macs /usr/local/rexxj.sh gets linked to
rexxj2.sh, by default java
gets invoked with
java org.rexxla.bsf.RexxDispatcher $*
which will run java (create the Java virtual machine and) have it run the Java
class
RexxDispatcher's main method which gets all command line arguments (like the
Rexx program file
name). RexxDispatcher will cause libBSF4ooRexx.dylib to be loaded which is
linked against rexx and
rexxapi. So no DYLD_LIBRARY_PATH there.
All these libraries are present in the system's standard location
"/usr/local/lib" (symbolic links
to either /Library/Frameworks/BSF4ooRexx.framework/Libraries/ or
/Library/Frameworks/ooRexx.framework/Libraries/) and therefore should be
locatable by the system.
[If an environment variable named "BSF4Rexx_JavaStartupOptions" is defined,
then java gets its
defined startup options passed on, such that e.g. the virtual machine's heap
space can be defined
and the like. But this is not the case for these use cases.]
It is really a bit puzzling! I will call it a day now (a little bit exhausted
from this week) ... :)
Best regards
---rony
P.S.: Locally I tested a version of libBSF4ooRexx.dylib where the link to
libjvm.dylib (the Java VM)
does not occur to a Framework directory, but to one of the
/Library/Java/JavaVirtualMachines Java
subdirectories (have multiple Java versions installed because of BSF4ooRexx)
which causes a
@rpath/libjvm.dylib entry to be created rather than
/System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM.
P.P.S.: The biggest problem is, that I cannot duplicate the student's problem.
So maybe I follow
P.O.'s advice and ask the student for reinstalling MacOS and only go on, if the
problem remains.
> On 19 Mar 2021, at 18:36, Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote:
>> Dear P.O.,
>>
>> On 19.03.2021 17:59, P.O. Jonsson wrote:
>> ... cut ...
>>> Two wild guesses: is the student maybe running macOS with encryption?
>> Hmm, would you have links that explain/describe about the implications of
>> doing so?
>>
>> One thing I start to speculate with is Apple's security measures that incur
>> side-effects for the
>> uninitiated (like myself in that regard) that cause this.
>>
>> When installing BSF4ooRexx Apple does not allow that to proceed as the
>> installation package is
>> unsigned and/or downloaded from the Internet. Rather she would go into
>> System Preferences where
>> there was an item (forgot which one) that allowed her to install that very
>> same BSF4ooRexx package.
>> If something went wrong there it may be the case that that inhibits
>> finding/loading the shared
>> libraries from that package?
>>
>>> Or use a case sensitive file system?
>> This should not pose a problem as BSF4ooRexx works on the case sensitive
>> Linux file systems.
>>> This problem looks to me like a „Windows-type“ problem, i.e. I guess the OS
>>> itself is rotten in
>>> some way. I would ask the student to reinstall macOS. And reinstall
>>> BSF/ooRexx after that.
>>>
>>> If that is to much work try to find another machine where s/he can do the
>>> same installation. If
>>> the problem arises again it is in his/her special setup.
>>>
>>> I have never once experienced something like what you describe, and I am
>>> juggling many different
>>> ooRexx/BSF/installer/dmg versions at the same time. On an older machine
>>> using hfs+ I have a
>>> problem with sub-second filenames but that is the only thing. And I have
>>> macOS on anything from
>>> High Sierra to Big Sur.
>> Thank you very much for your feedback and ideas, which are really helpful in
>> this situation!
>>
>> Having experimented with new builds of the shared library (on "Big Sur")
>> they all work and the
>> linking step creates @rpath/librexx.4.dylib, @rpath/librexxapi.4.dylib, and
>> @rpath/libjvm.dylib (but
>> also /usr/lib/libc++.1.dylib and /usr/lib/libSystem.B.dylib).
>>
>> Not sure whether further time investments would alleviate the problem on the
>> student's computer,
>> given your wealth of MacOS systems and experiences (will have to adapt the
>> Mac installer of
>> BSF4ooRexx to cater for zsh, and time permitting to change the installer to
>> check for the existence
>> of ooRexx on the system already, and if so use that ooRexx instead the one
>> on board of BSF4ooRexx
>> and the like)!
>>
>> Best regards
>>
>> ---rony
>>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
