mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John W. Eaton
Subject: Re: [Mingw-cross-env-list] Status of build with shared libraries
Date: Mon, 14 Oct 2013 15:16:08 -0400

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]