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: Tomasz Gajewski
Subject: Re: [Mingw-cross-env-list] Status of build with shared libraries
Date: Wed, 11 Sep 2013 07:52:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Tomasz Gajewski <address@hidden> writes:

> Tony Theodore <address@hidden> writes:
>
>> On 01/09/2013, at 6:40 AM, Tomasz Gajewski <address@hidden> wrote:
>>
>>>
>>> Hi,
>>>
>>> I'm interested in having a build of packages with shared libraries
>>> instead of static. I've seen in the archives that from time to time
>>> this subject comes up and in the issue "Multi-target approach"
>>> (https://github.com/mxe/mxe/issues/39) there where some
>>> considerations about adding an option to make shared build available.
>>>
>>> Is there some branch with options for shared libraries build or with
>>> multitarget approach taking into accound such build?
>>
>> There's nothing workable yet, but I was planning on getting qt5
>> working first as a preview. Do you have set of packages in mind that
>> you use for your project?
>
> Currently I treat it mostly as an excercise but probably I could use
> qt4 and qt5 in the future. Let's assume my goal is qt4 for now
>
> I've started with zlib and odbc++ as the are dependencies for qt4 and
> I have some at least two issues open:
>
>   - should we build packages with threads support - IMHO yes but
>     odbc++ was bouilt static without such support. I'm not even sure
>     for what it could be used by odbc++.
>
>   - 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
>
> 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?
>
> As about odbc++ I have a build but without threads enabled and
> realized that I don't know if it is needed e.g. for odbc qt plugin
> working if qt is build with threads support enabled.
>
> I can't dedicate how much time I can spend on this subject (probably
> not much) but if there was a place where shared libraries mxe would be
> developed I could add my 2 cents from time to time.
>
> 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.
>
> 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?

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.

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.

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?

Regards
Tomasz Gajewski



reply via email to

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