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] Using MXE for plugin based applications


From: Ronan Trépos
Subject: Re: [Mingw-cross-env-list] Using MXE for plugin based applications
Date: Wed, 13 Feb 2013 12:40:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

Hi Tony,

Thanks for your answer.

Le 09/02/2013 03:38, Tony Theodore a écrit :
Hi Ronan,

On 09/02/2013, at 3:47 AM, Ronan Trépos <address@hidden> wrote:

Hello,

For your information, I have investigated the possibility of using mxe for building our software relying on shared libgcc.
I have forked mxe in order to apply very few changes : git://github.com/rtrepos/mxe.git
It worked, not completely yet and only for our software, but exceptions sent by plugins are now caught by the main application.

I don't know much about shared libgcc, but the docs [1] indicate that it should be safe to enable in the gcc build since all the other package builds will use the static version when directed. It's also curious that libstdc++ is shared by default, but can be partially linked statically to freeze the version of libstdc++.


Yes, I think so, but I'm not sure this is a good strategy to mix the two of them.

Nevertheless I had to use the latest repositories of mingw during Mingw installation on windows.
The version of gcc (4.6) provided by the default installation is not compatible with the one used by mxe on ubuntu 12.10 (4.7.0) (?)

Again, I've never tried it, but wouldn't you be able to use the library created by mxe and ship it with your application? It's probably somewhere under $(PREFIX)/lib/gcc instead of the usual $(PREFIX)/$(TARGET)/lib.

I am sorry. I don't understand what you mean.
If you have any comments on this (e.g. is it a bad idea to use mxe for this purpose) don't hesitate.
It seems that MXE provides exactly what we need, and even much more, so thank you for that.

There are plans to support dynamic builds in the future, but it's still a way off - any feedback in this direction is helpful so please let us know any hints you find (e.g. would setting --enable-shared in gmp.mk cause the correct LDFLAGS to be set?)

The reason I modified the gmp makefile relies only on the fact that it did not compile after enabling shared libgcc for gcc. And setting this flag worked. The directive -enable-shared would lead to the build of a shared library for gmp.
Which is not exactly what we want.

For now, I encounter some difficulties linking to gtkmm static library. My main application is linked to it, so as the plugins are. Static variables of gtkmm library are reinitialized while opening the plugin (dlopen) and this causes an error.
Anyway thank you for your comments.
Ronan



-- 
Trépos Ronan
INRA unité BIA, équipe MAD, Toulouse
http://carlit.toulouse.inra.fr/wikiz/index.php/Ronan_TREPOS
tel : 05 61 28 51 89

reply via email to

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