[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