On 03.12.2018 15:13, Rick McGuire wrote: > btw, this stacktrace is consistent with the mismatch theory. The > RexxAddMacro() api needs to > dynamically resolve and resolve the address of the > RexxTranslateInstoreProgram() callback to > translate the added macro. This stacktrace looks like what would happen if a > second version of the > rexx library got loaded and called. None of the static variables in the > classes have been > initialized, so there is an exception. Not a bug, but a problem in your setup. Thanks, that is what I have feared!
--- I could verify that all the files from the CMake defined installation directory (~/Application/ooRexx5.0.0/bin) are identical to the ones in /usr/local/bin and /usr/local/lib which stem from the BSF4ooRexx installation files. Or with other words: all ooRexx related files are identical. Setting PATH and DYLD_LIBRARY_PATH to ~/Application/ooRexx.5.0.0/bin makes the test run successfully. (The ooRexx files used in the B4R installation package stem from that directory.) As my Mac has been used for years for creating MacOS version of BSF4ooRexx and the installation packages include ooRexx compiled on that machine over many years, I am not sure whether that may have an influence on the result of running the Macrospace.testGroup. Any hints, suggestions what might be a subtle cause for this behavior (where and in which order would Darwin look for libraries) would be highly appreciated. (Maybe it has to do with the Framework installation type?) ---rony _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
