Re: protocol for installing DP libs using binary installers?
Re: protocol for installing DP libs using binary installers?
- Subject: Re: protocol for installing DP libs using binary installers?
- From: Kurt Bigler <email@hidden>
- Date: Sun, 2 May 2004 21:49:23 -0700
On May 2, 2004, at 6:14 PM, Bob Ippolito wrote:
On May 2, 2004, at 6:23 PM, Kurt Bigler wrote:
I was just starting to look into building a binary installer for an
app that uses shared libraries that I built using DP.
How do people typically approach this situation? Are there any
general guidelines? Are there special protocols I should follow to
avoid doing the wrong thing in the (currently obscure) case that the
end user will have installed other things that depend on DP-generated
libraries?
It it considered safe and appropriate for an installer to to create
/opt/local/lib and put stuff into it?
If so, when the /opt/local/libs my executable references are symbolic
links, what am I obliged to install to be a good citizen? Is it a
good idea to actually recreate the identical symbolic link structure
rather than just installing libraries corresponding to the links on
my development system? Actually it looks like there are several
links to the same library. Is there some reason that I need to worry
about creating library links other than the ones my application uses?
Thanks for any info.
In general I would suggest trying to build a real .app bundle. You
will need to relocate all of the non-system mach-o load commands to
@executable_path relative,
Interesting. That slightly shoots in the foot the whole concept of
shared libraries, but I guess it still accomplishes that motivated
users can update shared libraries within the executable bundle.
but you can generally do that with install_name_tool(1).
Hmm, just read the man pages on that--all new to me. Thanks.
This sounds like a good candidate for an automated tool, doesn't it?
It might almost be no more trouble to protototype such a tool as it
will be to do this by hand anyway, especially when lib configs might
change with each subsequent release. Let me run these idea by you and
see if it makes sense.
Filter the output from otool -L to get the original list of libraries
with system libs removed. Loop through the list of libs. For each lib
follow links to determine the pathname of the actual library file.
Produce as output:
(1) a shell script (perhaps) that copies the libraries from their
development location to the application bundle
(2) input needed by install_name_tool to alter the executable
That's a rough sketch anyway. Does this sound feasible? Has anyone
else worked on such a tool?
In the cases where install_name_tool doesn't work, you should relink
the culprit library with the -header-pad_max_install_names LDFLAG.
Why wouldn't it work? Mind you I've never heard of it until today.
It's a lot of work, especially if you don't have experience with it,
but it makes (un)installation a breeze and it doesn't interfere with
the user's existing software. For example, if they have an existing
DP installation your installer may stomp all over it with old
libraries. That wouldn't be very nice, now would it?
Indeed, that's the kind of issue I was worrying about.
Thanks,
Kurt
_______________________________________________
x11-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/x11-users
Do not post admin requests to the list. They will be ignored.