Charles Wilson schreef op 2012-06-14 17:22:
> On 6/14/2012 9:51 AM, Earnie Boyd wrote:
>> Because of the -mms-bitfields default of the newly release GCC 4.7
>> have a complete mess on our hands with regard to package
>> Chris is about to release a -2 version of the current mingwrt and
>> w32api libraries compiled with this version of the compiler, however
>> should only be installed with GCC 4.7. The xml meta data for mingwrt
>> and w32api will need to reflect the GCC version requirements as well
>> the xml meta data for GCC needs to reflect the mingwrt and w32api
>> versions in its requirements. How do we best handle this issue?
> AFAIK, all of the add-on [*] libraries we distribute for mingw32 are
> compiled with -mms-bitfields and always have been at least as far
> as 2009, so this doesn't affect *our* offerings at all.
> [*] that is, everything *but* the core stuff (of which I am not sure
> whether they have previously been built with ms-bitfields or not) -
> as mingwrt and w32api.
> However, there is an *additional* ABI incompatibility in 4.7 IIRC,
> C++. I'll have to research the details but I'm swamped right now.
> Check the mailing list for a question I posted and Kai answered, no
> than 6 months ago (but at least 2 months back).
I maintain two libraries for mingw: libunistring and PDCurses.
For libunistring I used mgwport. Did mgwport automatically add option
-mms-bitfields? Do I need to rebuild?
PDCurses did not use mgwport yet, so I assume I have to rebuild the
libraries (with mgwport). Correct?
What happens if users keep on using an older than 4.7 gcc, and use the
new gcc 4.7 rebuild libraries? In other words, if all libraries are
rebuild, are the users than forced to use gcc 4.7?