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

[Tony Theodore]

On 11/09/2013, at 3:52 PM, Tomasz Gajewski <address@hidden> wrote:

> Tomasz Gajewski <address@hidden> writes:
> 
>> Tony Theodore <address@hidden> writes:
>> 
>>> On 01/09/2013, at 6:40 AM, Tomasz Gajewski <address@hidden> wrote:
>> 
>>  - try to build with import libraries or with direct linking to dlls
>>    (documentation says startup time for application linked in second
>>    way is shorter but there are some caveeats) - probably the safe
>>    way is to use import libraries

I'm not too sure about which is the better option, I suppose we can always 
change it later based on feedback.

>> As about zlib I've managed to make build but using makefile dedicated
>> for mingw instead of that for unix systems. It needed less
>> changes. I've seen that line that blocked working for mingw of this
>> "unixy" makefile is removed by patch. Do you know why this
>> implementation is used?

In my first attempt, I did the same thing with zlib:

https://github.com/tonytheodore/mxe/blob/shared/src/zlib.mk

I suppose the "unixy" makefile is used as it's easier to create a static build.

>> 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

>> In some other threads on mailing list I've seen something about using
>> pkgconf by project (I don't know anything about this yet). Would that
>> somehow influence development of shared libraries build. And if yes,
>> could you explain how it is used/it would be used?

pkgconf now has support for a "Cflags.private" fragment:

https://github.com/pkgconf/pkgconf/pull/50

This allows us to cleanly add the -DFOO_STATIC define that is sometimes 
required for windows - without affecting the shared build or trying to do 
tricky sed manipulations or target-specific patches.

> 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?

> The most surprising fix was in gcc.mk in which pkg-config script was
> created with '--static' flag embedded which caused problems for qt
> test. I think that it is not appropriate place for this. It took me
> quite some time to find out why pkg-config does not work properly
> according to documentation.

I can see how that would have caused problems if you didn't know about it. We'd 
handle this and the cmake toolchain file with something like:

https://github.com/tonytheodore/mxe/blob/shared/src/gcc.mk#L59

It's a handy convenience that makes ./configure scripts work and also allows 
reuse of the test program invocation.

> 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.

Cheers,

Tony