Re: MXE Octave: "... has no symbols" warning under Mac OS X

[Anirudha Bose]

On Mon, Sep 23, 2013 at 2:32 PM, c. <address@hidden> wrote:

On 23 Sep 2013, at 10:53, Anirudha Bose <address@hidden> wrote:

> On Mon, Sep 23, 2013 at 2:01 PM, Anirudha Bose <address@hidden> wrote:
>
> On Mon, Sep 23, 2013 at 11:14 AM, c. <address@hidden> wrote:
>
> On 22 Sep 2013, at 22:21, Anirudha Bose <address@hidden> wrote:
>
> > I basically used Macports to get gfortran in Mac OS X, and some deps like GhostScript. I was wondering if it is possible to specify a "--prefix" during Macports installation of a package. If yes, then we can include it in our MXE. This will eliminate the need for the presence of Macports gfortran in the target system in order to run Octave.
>
> Anirudha,
>
> I am a bit confused here, is MacPorts required during the build process or is it required to run the Octave binary as well?
>
> otool -L ./mxe-octave-anirudha/dist/octave.app/Contents/Resources/bin/octave-3.7.5 reports dynamic library paths to Macports. So it means MacPorts will be required to run Octave. I was proposing that the prefix for MacPorts installation could be the HOST_LIBDIR of MXE, so that these libraries can be included in the app bundle. In this way it might be possible to eliminate need for MacPorts from the target, if not from the host.
>
> If MacPorts is required, why not just do:
>
> sudo port mdmg octave
>
> from macports? this will produce a binary distribution of Octave and its dependencies on a disk image.
>
>> If you check the MacPorts website,  you will see that the latest version of Octave is 3.6.4.

That's because 3.6.4 is the latest stable release, the new portfile will not be created until there is a new release.

I don't know about how much Octave is maintained in MacPorts. The stable release of octave in Macports is 3.2.4, while the development snapshot of Octave is 3.6.4. I may be getting it wrong. If a new version of Octave is released, it is very simple and quick to build it for Windows or Mac OS X. The aim is get reproducible builds without any/much user intervention.

>> Creating an app bundle entirely from MacPorts is not a completely on the fly solution.

No, of course, it would still require updating the portfile for the new version of Octave,
but it saves the effort of creating and maintainig build scripts for all the dependencies.

>> MXE is a unified solution which will enable anyone to build a version of Octave for their systems with minimal knowledge about build systems.
>>
>
> Sorry if the question sounds stupid, as I said I'm just getting started trying to understand your binary packaging approach.
>
> If we can compile MacPorts with MXE and include it in our MXE directory, then I think we should be able to install the various dependencies inside our MXE usr/ directory. This way we can --
>
> 1. Install packages which can only be installed through MacPorts (Example, gfortran)
> 2. Eliminate need for installed MacPorts in the target machine.

But, if Macports is required, why not use it for ALL dependencies rather than mixing up different approaches?

Please note that I am not at all suggesting we SHOULD do this, just trying to understand ...

I would like to have input on what others think about this approach. It was just an idea which struck me in order to separate MacPorts from MXE.

c.