On Fri, 21 Nov 2008, Maurilio Longo wrote:
Hi Maurilio,
> in OS/2 there is an envvar, LIBPATH=, which always contains '.' and is used by
> OS/2 to find needed DLLs; so every program looks at the dirctory it was
> started from when looking for .DLLs.
> I don't think this is available on MacOSX.
It is just like in other *nixes. The envvar name is of course different:
DYLD_LIBRARY_PATH
This is a colon separated list of directories that contain
libraries. The dynamic linker
searches these directories before it searches the default locations for
libraries. It allows
you to test new versions of existing libraries.
For each library that a program uses, the dynamic linker looks for
it in each directory in
DYLD_LIBRARY_PATH in turn. If it still can't find the library, it
then searches DYLD_FALL-BACK_FRAMEWORK_PATH DYLD_FALLBACK_FRAMEWORK_PATH
BACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH in turn.
Use the -L option to otool(1). to discover the frameworks and shared
libraries that the exe-cutable executable
cutable is linked against.
DYLD_FALLBACK_LIBRARY_PATH
This is a colon separated list of directories that contain libraries.
It is used as the
default location for libraries not found in their install path.
By default, it is set to
$(HOME)/lib:/usr/local/lib:/lib:/usr/lib.
Please also look at defaults which shows how to create non system wide
user customized installation and where should be put shared libraries
to not force any environment variable settings.
Whole necessary information is easy accessible in MacOSX. It's enough to
read few man pages like man ld, man dlld, man dlopen, ...
It's said that I have to find such information in the internet without
MacOSX and real MacOSX user cannot so resolves the problem by disabling
shared linking in default builds. It causes that I stop to trust in any
other opinions about this system because it may be only result of
insufficient knowledge about MacOSX.
> > as possible. In OS X, installation is rather the exception
> > than the rule, which is just one more reason to allow support
> > for it (especially if it doesn't hurt anyone).
> I agree with you here, and with something you wrote later, MacOSX is not
> linux, so it is wrong to see it just like a unix dialect with some fancy
> window manager.
Yes, it's not Linux. It's modified BSD.
,--------------------------------------------------------------------------
| Berkeley Software Distribution (BSD)
| Part of the history of Mac OS X goes back to Berkeley Software
| Distributions (BSD) UNIX of the early seventies. Specifically,
| Mac OS X is based in part on BSD 4.4 Lite. On a system level, many
| of the design decisions are made to align with BSD-style UNIX systems.
| Most libraries and utilities are from FreeBSD, but some are derived
| from NetBSD. For future development, Mac OS X has adopted FreeBSD as
| a reference code base for BSD technology. Work is ongoing to synchronize
| all BSD tools and libraries more closely with the FreeBSD-stable branch.
`--------------------------------------------------------------------------
> That said, what about having MacOSX specific commands instead of changing the
> ones that work on most the other *nixes?
I have nothing against adding any extensions to MacOSX builds.
This is what I'm asking for. Add any new extensions to customized
MacOSX builds but please do not reduce existing functionality and
do not forbid users to create binaries compatible with other *nixes.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
