Re: Charges for Mac Binaries

[Ben Abbott]

On Feb 19, 2012, at 12:52 PM, Alexander Hansen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2/18/12 9:31 PM, Ben Abbott wrote:
>> On Feb 18, 2012, at 8:10 PM, Rik wrote:
>> 
>>> There was a discussion on the bug tracker
>>> (https://savannah.gnu.org/bugs/?34667) about pre-built Mac
>>> binaries which deserves to be on the Maintainers list.  The
>>> executive summary is that Octave should perhaps charge for
>>> pre-built Mac binaries in the same way we are proposing to do for
>>> Window binaries.
>>> 
>>> --Rik
>> 
>> I've trimmed Rik's email. Please see the link below for what was
>> included in his original email
>> 
>> https://savannah.gnu.org/bugs/?34667
>> 
>> I'm wondering if a mac binary could be constructed by using "otool
>> -L" to trace the dependent dynamically linked libs, and then
>> populate an Octave-x.y.z.app with the required libs Octave depends
>> upon.
>> 
>> Could this be accomplished using Fink and/or Macports to satisfy
>> the dependencies ?
>> 
>> Ben
> 
> If you're proposing to have a "thin" app bundle which just contains
> the octave executable, libraries, and scripts, with all of the
> dependent libraries located elsewhere in the filesystem, it shouldn't
> be a problem to use Fink or Macports.
> 
> I know Fink is GPL'ed, so you're free to use it as you will :-), but
> I'd ask that you -not- use Fink's default path, however, because that
> invites trouble e.g.:
> 
> If a user installs the Octave binary on top of an existing default
> Fink tree and its libraries are older than those currently in Fink
> then that can cause problems within other Fink packages e.g. if this
> involves downgrading the compatibility_version.
> 
> Or if a Fink user removes a package that provides libraries that
> Octave needs, that will break Octave.
> 
> I'd presume similar arguments apply to Macports.  Admittedly, most
> Fink or Macports users will probably just use the octave packages
> within those systems, but it's best to avoid problems.
> 
> If you're proposing a "thick" app, with all of the libs inside of the
> app bundle, that's a more interesting proposition.
> 
> If the app bundle is not going to be set up to be relocatable then one
> could set up a Fink tree rooted in e.g.
> /Applications/Octave.app/Contents/Resources to build all of the
> dependencies.
> 
> If you want it to be relocatable, that's going to be a bit harder to
> do with Fink.  The individual package descriptions could be modified
> to make sure the libraries and executables use relative path variables
> (e.g. @executable_path) rather than absolute paths to the library
> dependencies.  Or you might be able to get away with using
> install_name_tool after the fact to do that.  I'd recommend that you
> do this kind of thing in the Octave build, too, so that mkoctfile,
> oct-conf.h, and the "octave_config_info" command will have the
> relative path variables encoded within them.
> 
> I can't speak for how Macports would handle the situation.
> - -- 
> Alexander Hansen, Ph.D.
> Fink User Liaison

I'd like a "thick" version, where all runtime libs and bins are bundled in one 
app (so neither a Fink or Macports install would be required to run Octave).

Would it be necessary to rebuild all the executables to use relative path 
variables ?

I never dug this deep into how Fink or Macports work, so I may be asking for 
the impractical, but I'm hoping to trace lib dependences by using "otool -L" 
and populate an app bundle with them. Next, I need to know what run time 
binaries are needed (gs, epsedit, gnuplot, etc) and populate the bundle with 
those as well. Hopefully, this can be done in an easy to maintain way.

Ben