On 12/09/2011 10:44 AM, Alexander Thurgood wrote:
otool -L
/Users/Shared/LO/master/connectivity/unxmacxi.pro/lib/postgresql-sdbc-impl.uno.dylib
/Users/Shared/LO/master/connectivity/unxmacxi.pro/lib/postgresql-sdbc-impl.uno.dylib:
@__________________________________________________OOO/postgresql-sdbc-impl.uno.dylib
(compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
version 227.0.0)
@loader_path/../ure-link/lib/libuno_cppu.dylib.3 (compatibility
version 0.0.0, current version 0.0.0)
@loader_path/../ure-link/lib/libuno_cppuhelpergcc3.dylib.3
(compatibility version 0.0.0, current version 0.0.0)
@loader_path/../ure-link/lib/libuno_sal.dylib.3 (compatibility
version 0.0.0, current version 0.0.0)
@loader_path/../ure-link/lib/libuno_salhelpergcc3.dylib.3
(compatibility version 0.0.0, current version 0.0.0)
libpq.5.dylib (compatibility version 5.0.0, current version 5.3.0)
That way it won't be found at runtime. If it is a lib from the system,
it should have an absolute path (like the ones below), if it is part of
LO it should be referenced relatively via @loader_path (like the ones
above).
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.11)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
Note that I actually have 2 postgresql-sdbc-impl.uno.dylib files in my
tree, which have different sizes ! Not quite sure why, as my
understanding was that the one in solver was simply a copy of the one in
connectivity ?
For still-dmake-based modules, libraries are stripped when copied from
the local output tree to solver.
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
