| /usr/local/ is a long-standing Unix tradition as a place for user-installed software. It is so traditional that, for example, gcc will automatically include /usr/local/include in its search algorithms for header files without being told to explicitly. The nice thing about /usr/local is that Apple (and other Unix vendors) do not modify the contents of /usr/local during an upgrade cycle. Anything else in the /usr hierarchy is subject to change from revision to revision, and, if you've installed software in /usr/lib, /usr/libexec, etc., that software is at risk during an upgrade cycle.
Nothing says that /usr/local is pre-ordained ... you can put anything anywhere you like, as long as you respect the system allocated directories like /usr, etc.. /usr/local/libexec is another traditional place for user-install daemon executables (not necessarily present in all versions of Unix). Some versions also use /usr/local/sbin. If you have dynamic libraries related to your daemons, /usr/local/lib is as good as anyplace. If you have static libraries for use with clients of your daemon, /usr/local/lib is also a good place to go.
You have to explicitly create /usr/local/(lib,bin,etc,include,libexe,sbin).
Apple expands on this whole concept with launch agents (system and user), and launch daemons (again, system and user). There are some plist files that have to go into /Library/LaunchAgents and/or ~/Llibrary/LaunchAgents (see man(1) launchd), but, the file specifications for executables and such can point to anywhere in the file system.
For loading dynamic libraries, the runtime loader needs to be able to find your dynamic library. It is either encoded into the executable by the linker, or is resolved through something DYLD_LIBRARY_PATH, etc.. As long as the paths are made known to the loader, they can be located anywhere.
Jonathan On Jun 2, 2010, at 3:27 PM, Xochitl Lunde wrote:
When I create a BSD dynamic library
in a blank project, Xcode assigns the default Installation Directory as
/usr/local/lib. Is this really where I should be putting my daemon's
shared libraries? I don't even have that folder on my system, so
I guess nothing else that I've installed has tried to do that, which doesn't
make me very confident about choosing that for my own project.
I had a thread on the installer dev
list awhile back about where daemons should reside on the file system,
and the result I ended up with is from the 'hier' man page, in /usr/libexec.
I'm not sure if I should make a /usr/local/libexec, this seems weird
but I'm inexperienced at the general rules of the linux file system. I
have reviewed the software deployment documentation and read over the TN
2083 Daemons and Agents many times, as well as the launchd and launchctl
man pages, but I haven't noted any advice on where to put daemons and their
libraries other than the 'hier' man page.
I have inspected many application packages
from downloaded programs, and I see that some of them have their shared
libraries inside the bundle in the MacOS folder, sometimes under a 'lib'
folder, sometimes just there with the executable. Most of the 'background'
programs that I've been able to download look like they use the deprecated
StartupItems method to start their daemons. I want to put my libraries
with my daemon, but it again seems like it would be weird to put them in
/usr/libexec.
1. Should I really put my daemon's
libraries in /usr/local/lib?
2. Is there a way to tell
Xcode that I'm making a daemon specifically?
3. Does Xcode have other default
rules about where to put things that I might be able to reference?
Sorry if this is too off topic, but
I am really curious about Xcode's path choice for /usr/local/lib.
Thanks,
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|