Does the behavior change if you use the Terminal window to explicitly set the 
environment and then `open -a OpenOffice`?

I had to do that in Catalina to access a Mozzila keystore.

> On Sep 29, 2021, at 8:03 AM, Rony G. Flatscher <[email protected]> 
> wrote:
> 
> On 28.09.2021 22:25, Jim Jagielski wrote:
>> Is this a regression?
> 
> Not really sure, it used to work on AOO 4.1.10 AFAICR, but now, testing 
> against 4.1.10 the same
> problem occurs, although java.library.path has a different value compared to 
> 4.1.11:
> 
>    
> java.library.path=[.:/Users/rony/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]
> 
>    java.runtime.version=[9.0.4+11]
> 
> However, I did update the operating system in between which now is macOS Big 
> Sur 11.6.
> 
> My (pure!) speculation is, that dlopen() on BigSur does not honor 
> DYLD_FALLBACK_LIBRARY_PATH which
> includes ~/lib:/usr/local/lib:/usr/lib, cf. [1], [2].
> 
> However, "man dlopen" would document that if DYLD_FALLBACK_LIBRARY_PATH was 
> not set, then dlopen
> operates as if this environment variable was set to 
> $HOME/lib:/usr/local/lib:/usr/lib. If that was
> the case then libBSF4ooRexx.dylib would be found as it is in /usr/local/lib, 
> but it is not (hence
> speculating).
> 
> So maybe these libraries should be explicitly added to the java.library.path 
> on Darwin to have
> System.loadLibrary(name) look through them.
> 
> ---rony
> 
> [1]  "Using Dynamic Libraries":
> <https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/UsingDynamicLibraries.html>
> 
> [2] Manpage for dlopen(3):
> <https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html>
> 
> 
>> 
>>> On Sep 28, 2021, at 1:36 PM, Rony G. Flatscher <[email protected]> 
>>> wrote:
>>> 
>>> Tested the MacOS version and ran into a problem: AOO does not consult 
>>> "/usr/local/lib" on MacOS when
>>> loading a native library.  Also, on "java.library.path" there seems to be a 
>>> wrong directory
>>> ("/Applications/OpenOffice.app/Contents").
>>> 
>>> The setting of "java.library.path" in effect:
>>> 
>>>   
>>> java.library.path=[/Applications/OpenOffice.app/Contents:/Users/rony/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]
>>> 
>>>   java.runtime.version=[9.0.4+11]
>>> 
>>> Placing a symbolic link into "/Applications/OpenOffice.app/Contents" allows 
>>> the library
>>> "libBSF4ooRexx.dylib" to be found in this version (and everything then 
>>> works as expected), however
>>> that directory should probably not be defined as it is does not contain any 
>>> native libraries (rather
>>> its subdirectory MacOS does).
>>> 
>>> So, this version does not consult "/usr/local/lib" to find and load 
>>> "libBSF4ooRexx.dylib".
>>> 
>>> ---rony
>>> 
>>> P.S.: Here the relevant stack trace (when attempting to load the scripting 
>>> engine for ooRexx to run
>>> an AOO macro via the Tools -> Macros menu):
>>> 
>>>   Caused by: java.lang.UnsatisfiedLinkError: no BSF4ooRexx in 
>>> java.library.path
>>>     at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2541)
>>>     at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873)
>>>     at java.base/java.lang.System.loadLibrary(System.java:1857)
>>>     at 
>>> org.rexxla.bsf.engines.rexx.RexxAndJava.<clinit>(RexxAndJava.java:880)
>>>     at 
>>> org.rexxla.bsf.engines.rexx.RexxEngine.initialize(RexxEngine.java:291)
>>>     at org.apache.bsf.BSFManager$8.run(BSFManager.java:854)
>>>     at java.base/java.security.AccessController.doPrivileged(Native Method)
>>>     at org.apache.bsf.BSFManager.loadScriptingEngine(BSFManager.java:852)
>>>     ... 40 more
>>> 
>>> 
>>> On 27.09.2021 21:21, Jim Jagielski wrote:
>>>> The macOS, Linux64 and Linux32 builds are also there!
>>>> 
>>>>> On Sep 23, 2021, at 9:48 AM, Matthias Seidel <[email protected]> 
>>>>> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I have uploaded all Windows binaries to:
>>>>> 
>>>>> https://dist.apache.org/repos/dist/dev/openoffice/4.1.11-RC1/binaries/
>>>>> 
>>>>> Although we have not yet announced AOO 4.1.11-RC1 officially please feel
>>>>> free to download and test them!
>>>>> 
>>>>> Regards,
>>>>> 
>>>>>  Matthias
>>>>> 
>>>>> P.S.: Linux/macOS builds will be uploaded next week
>>>>> 
>>>>> Am 22.09.21 um 17:33 schrieb Matthias Seidel:
>>>>>> Hi all,
>>>>>> 
>>>>>> I would be ready to upload the Windows binaries if we want to announce 
>>>>>> RC1?
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>>  Matthias
>>>>>> 
>>>>>> Am 21.09.21 um 23:15 schrieb Matthias Seidel:
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> Am 21.09.21 um 22:42 schrieb Pedro Lino:
>>>>>>>> Hi Dave, all
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 09/21/2021 9:07 PM Dave Fisher <[email protected]> wrote:
>>>>>>>>> windows - thanks Matthias
>>>>>>>>> https://www.dropbox.com/s/912galt8kr7wiem/Apache_OpenOffice_4.1.11_Win_x86_install_en-US.exe?dl=0
>>>>>>>> Installed and tested signing a document. Works as expected
>>>>>>>> 
>>>>>>>>> linux
>>>>>>>>> We are waiting for someone to do a build.
>>>>>>>> Can sign on Ubuntu 18.04 x64 using my PGP certificate
>>>>>>>> 
>>>>>>>> Unless there is a problem on Mac, seems like ready to go?
>>>>>>> It looks good for me!
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>>  Matthias
>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Pedro
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to