Re: [Mingw-cross-env-list] Status of build with shared libraries

[Tony Theodore]

Sorry, I didn't check the archives - you're right it didn't go through.

On 15/10/2013, at 6:16 AM, John W. Eaton <address@hidden> wrote:

> On 12-Sep-2013, Tomasz Gajewski wrote:
> 
> | Tony Theodore <address@hidden> writes:
> | 
> | > Indeed, a separate branch/fork will diverge too quickly - there's such
> | > a project already:
> | >
> | > http://hg.octave.org/mxe-octave
> | >
> | > but unfortunately there isn't much we can do to easily merge that back
> | > in (or for them to merge mxe and keep updated). They also have an
> | > interesting approach to creating shared libs from static ones that may
> | > interest you.
> | 
> | As I understand their goal is to build octave. So I don't think it is an
> | alternative for mxe.
> 
> Hi,
> 
> I am the Octave maintainer and the person who forked MXE for building
> Octave.
> 
> First, thank you for writing MXE and making it available.  It's been
> extremely helpful and has made building Octave and all its
> dependencies for Windows systems much easier than it would have been
> if we had to do all the work for that ourselves.
> 
> I apologize for not contacting you before now.  It was never my intent
> to permanently fork MXE and create some alternative to it.  My goal
> was just to be able to build Octave and all its dependencies.  When I
> was searching for a way to cross compile for Windows it seemed to me
> that MXE was the best choice.  The only problem was that it did not
> support shared libraries and we need them for Octave.  From what I
> read on the mailing list at the time there did not seem to be much
> interest in having MXE support shared library builds.  Given the
> choice of starting something from scratch or modifying MXE, I decided
> to try to modify MXE.
> 
> When I started, I initially hoped to be able to merge your changes
> with my branch and stay current with MXE development.  I also hoped
> that we could ultimately merge at least some of my changes back with
> MXE.  Unfortunately, given the changes that we were making, merging
> probably would have been difficult and I was very busy and never
> really tried.
> 
> We have also been using our MXE-based system to do native builds of
> Octave and all the dependencies on systems like Red Hat 5.x and
> Windows with MSVC that don't have up to date tools or packages for all
> the dependencies that Octave requires.
> 
> Now I am looking at building for mingw-w64 and I see that you already
> have a great start on that and I would rather not duplicate all the work
> you've done.
> 
> There are also things that you've done that just seem better than what
> we have done.  For example, your method of handling differences in
> targets with variables like $(PKG)_BUILD_$(TARGET) could work much
> better than what we've done with Make conditionals.  It seems to me
> that we could also extend that idea to handle "native" builds for
> systems like Red Hat 5.x and Windows with MSVC.
> 
> Although our sources have diverged significantly, I would still like
> to try to merge our changes with yours.  I would be very happy if we could
> work together so that we would not have to maintain a separate fork of
> MXE.
> 
> If you are interested, I would be happy to discuss a plan for how best
> to provide patches to you.  I expect that would be done by creating a
> new series of incremental changes to the current MXE.
> 
> | As about shared libraries from static ones I think
> | it should generally work for windows being a target as all code is
> | PIC. Problems may arise as no undefined symbols are allowed.
> 
> The way I am generating shared libraries from static libraries is
> simplistic but seems to work well enough for us for those packages
> that don't have build systems that build proper shared libraries.  My
> goal was to get something working quickly, so I decided to try to
> generate shared libraries from static libraries.  It was not meant as
> a long term solution.  I would prefer to fix the build systems in the
> packages so that they build proper shared libraries but there is not
> much incentive for doing that since what we are doing seems to work.
> 
> jwe