Przemyslaw, I was answering to Viktor since he named OS/2 and asking him why he did change linux (or more in general unix compitible) scripts instead of creating new ones for macosx.
I was not saying you're against adding new command for macosx or anything like that. This just for clarification. Best regards. Maurilio. PS. If I'm not wrong, usually on *nixes, the envars which deal with paths don't have '.' in them as a security measure, so that you're sure you're using the correct executable and/or library; this could mean that to be able to start something from a usb key (like Viktor would like to be able to do) requires a little script which adds '.' to the needed paths. > 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 > _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
