Stephan Bergmann wrote:
I observed the following on unxmacxi.pro SRC680m238, but other versions
(like SRC680m240) appear to have the same problems:
When building sal, the following files are created in the local output
tree:
.../src.m238/sal/unxmacxi.pro/libuno_sal.dylib -> libuno_sal.dylib.3 #1
.../src.m238/sal/unxmacxi.pro/libuno_sal.dylib.3 #2
.../src.m238/sal/unxmacxi.pro/libuno_sal.dylib.3.jnilib -> libuno_sal.dylib.3
#3
When this is delivered (via the two sal/prj/d.lst:1.29 rules
..\%__SRC%\lib\*.dylib %_DEST%\lib%_EXT%\*.dylib
..\%__SRC%\lib\*.dylib.* %_DEST%\lib%_EXT%\*.dylib.*
), the result in the solver is
.../unxmacxi.pro/lib.m238/libuno_sal.dylib #4
.../unxmacxi.pro/lib.m238/libuno_sal.dylib.3 #5
.../unxmacxi.pro/lib.m238/libuno_sal.dylib.3.jnilib -> libuno_sal.dylib.3 #6
.../unxmacxi.pro/lib.m238/libuno_sal.dylib.3.jnilib.jnilib ->
libuno_sal.dylib.3.jnilib #7
.../unxmacxi.pro/lib.m238/libuno_sal.jnilib -> libuno_sal.dylib #8
There are two problems, one severe, one at least of a cosmetic nature:
First, #4 differs from #1 (i.e., #2) in that LC_ID_DYLIB of #1/#2 is
@executable_path/libuno_sal.dylib.3, whereas LC_ID_DYLIB of #4 is
@executable_path/libuno_sal.dylib (probably due to
solenv/bin/macosx-create-bundle:1.3 l. 98, whatever the intend behind
that code).
FYI, removed that line entirely from
solenv/bin/macosx-create-bundle:1.3.440.1 (reworking the install_name
stuff on CWS sb83, anyway; detailed information will follow).
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
