On Mar 14, 2006, at 5:18 AM, Alexander Hansen wrote:
I successfully built openoffice.org-firefox-2.0.1+m156-104 on my
PowerBook, which is currently set up for 10.4-transitional. So far
everything seems to run as it did on prior versions.
However, I was looking around at some of the object files to see if
I would have to rebuild the package on my 10.4 (real) setup. The
files that I looked at all look like the following:
$ otool -L /sw/lib/openoffice.org-firefox/program/uno.bin
/sw/lib/openoffice.org-firefox/program/uno.bin:
@executable_path/libuno_sal.dylib.3 (compatibility version
0.0.0, current version 0.0.0)
@executable_path/libuno_salhelpergcc3.dylib.3
(compatibility version 0.0.0, current version 0.0.0)
@executable_path/libuno_cppu.dylib.3 (compatibility version
0.0.0, current version 0.0.0)
@executable_path/libuno_cppuhelpergcc3.dylib.3
(compatibility version 0.0.0, current version 0.0.0)
/usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0,
current version 6.2.0)
@executable_path/libstlport_gcc.dylib (compatibility
version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.1.5)
$ otool -L /sw/lib/openoffice.org-firefox/program/libreg.dylib.3
/sw/lib/openoffice.org-firefox/program/libreg.dylib.3:
@executable_path/libreg.dylib.3 (compatibility version
0.0.0, current version 0.0.0)
@executable_path/libuno_sal.dylib.3 (compatibility version
0.0.0, current version 0.0.0)
@executable_path/libuno_salhelpergcc3.dylib.3
(compatibility version 0.0.0, current version 0.0.0)
@executable_path/libstore.dylib.3 (compatibility version
0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.1.5)
@executable_path/libstlport_gcc.dylib (compatibility
version 0.0.0, current version 0.0.0)
(i.e. @executable_path didn't get replaced by '/sw/lib/
openoffice.org-firefox/program/ when the install_name for any of
the libraries was set).
@executable_path is used for libraries that are to go into a bundle,
like a .app bundle. We don't see this very often in Fink because we
don't have very many packages which produce .app bundles as their
output. It should be OK, if openoffice.org is building a bundle.
I don't know if this matters for libraries that are only used
internally (I'm sending -devel this message too to get information
there), but I thought I should mention it.
Also, is there a reason that the libraries are named "libreg dylib.
3" (for example) rather than "libreg.3.dylib"?
This looks like a bug in the libtool (or other buildsystem) used by
the package.
-- Dave
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
