Re: Charges for Mac Binaries

[Alexander Hansen]

-----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
http://finkakh.wordpress.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9BNsoACgkQB8UpO3rKjQ+UqACgkL9wYKkPXdZC12u1fcoFwjJ7
730An3Xqkil3GCCJFw6hSXHM4gp9mR16
=eI6+
-----END PGP SIGNATURE-----