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

[Tomasz Gajewski]

Tony Theodore <address@hidden> writes:

>>> Also I wouldn't want to make invasive changes if you have some idea
>>> how to implement changes in core that would allow to have builds for
>>> different configurations side by side like stated in "Multi-target
>>> approach" issue. I think that core part should not be limited only
>>> to shared/static but maybe other named variants.
>
> It makes sense to enable more variants than simply lib type. There are
> two approaches I've explored so far, using a directory layout to
> separate the variants or using a modified target triplet. The former
> needs some ugly path manipulations or symlinks, the later doesn't
> necessarily work reliably. I see target triplets along the lines of:
>
> -i686-pc-mingw32.static # current default mxe
> -x86_64_w64_mingw32.shared.seh.c11 # structured exception handling and
> c++11 threading
>
> If that approach can be made to work, the changes wouldn't be invasive
> as we already have a target loop

I don't think that exploiting configuration triplet name is a good
idea. Not only because I expect problems with build machinery of
projects. I just think that configuration triplet and shared/static
(let's assume that we just talk about only those two configurations for
simplicity) are two distinct things. Even with currently supported three
triplets and only two options we would have to explicitly support 6
build recipies in all .mk files (I know that probably it could be
simplified a little but not much).

I would rather think about "configurations" that would be just parts
after target triplet. During build a concatenated target with
configuration should be used as installation directory and used as items
in mentioned by you "target loop".

Also looking at currently required changes I would rather think that
"configuration" should just define some variables which could be used
during BUILD (not different build rules) though I don't know how hard it
would be. Currently most packages required only options for enabling
shared and disabling static.

I also think that shared/static options should be specified on per
package basis - not globally. So there should be no problem to create
configuration "partially_shared" without changing build rules (assuming
all packages supported shared/static configuration option) where some
packages could be selected to be linked shared and some static.

I'm not sure it is clear what model I have in mind (it is late here) -
if not ask for details. I didn't think if it is feasible to implement
something like this. Just thoughts how I would like it to work.

>> Following to myself I've just built fully shared qt4 (with all
>> dependencies) based on mxe, though I haven't tried to run any
>> programs with this build yet.
>>
>> Changes were mostly simple. Non trivial things were in gnutls (patch
>> applied in gnutls trunk), libodbc++, openssl, postgresql, qt and
>> zlib.
>
> Nice work, could you post the changes you made somewhere?

Sure. I'm attaching a complete diff but I would rather like to share
this in some repository and at best in repository where both static and
shared builds would be supported :-).

>> My previous questions still hold especially about plans to support
>> static and shared build from single sources. I think branching a
>> project for shared build is not a good idea. Is there any work in
>> progress for this or just some plans how to manage those
>> configurations in mxe?
>
> 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. 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.

Regards
Tomasz Gajewski

shared.diff
Description: Text Data