Re: [Mingw-cross-env-list] Combining 32-bit and 64-bit suport (was: gcc 4.5 error)

[Tony Theodore]

On 20 April 2010 21:13, Volker Grabsch <address@hidden> wrote:
> Tony Theodore <address@hidden> schrieb:
>> On 19 April 2010 23:12, Volker Grabsch <address@hidden> wrote:
>> > Have you tried to build 32-bit binaries with mingw-w64? I.e., is there
>> > any "-m32" switch or similar?
>> >
>> > Is there a possibility to build a "32-bit-only" or "32-bit-by-default"
>> > compiler with mingw-w64? If so, we could try to switch to that one,
>> > and sort out 64-bit issues later.
>>
>> Yes, there's two targets - x86_64-w64-mingw32 (can be multilib) and
>> i686-w64-mingw32. With the multilib, you have to do a lot of double
>> builds with "-m32" and it's not always obvious where to install
>> libraries.
>
> Maybe the cleanest way is to build 32-bit stuff using the
> 'i686-w64-mingw32' prefix and 64-bit stuff using the
> 'x86_64-w64-mingw32' prefix. That way, both could reside
> within the usr/ directory and share the "usr/bin/" directory
> because of different prefixes.
>
> The disadvantage would be the need to build the Binutils and GCC
> twice, but that might be the lesser evil. On the other hand, we
> might build one multilib GCC and provide wrapper shell scripts
> that are named "i686-w64-mingw32-gcc" etc. and which call the
> corresponding tool with an added "-m32" argument.

It does seem to be the lesser evil, though another problem I find is
that there's no standard location for libraries. There's lib, lib32,
lib64, and an underscore prefix. This thread made me give up on it,
even though it's enabled by default.

http://sourceforge.net/mailarchive/forum.php?thread_name=960e7eac1003221407q5a1431a1t71a7cc8bd6f38918%40mail.gmail.com&forum_name=mingw-w64-public

Another future problem we may have is coditionally patching/excluding
packages based on the build type.

> However, that's to be decided in the future. Let's concentrate
> on 32-bit-only for now.

Agreed, unless someone has lots of spare time :)

> BTW, this discussion shows the importance of the "i686-pc-mingw32-"
> prefixes in usr/bin/. So it appears to me that the unsolved NSIS
> question as of:
>
> http://lists.gnu.org/archive/html/mingw-cross-env-list/2010-02/msg00113.html
>
> should be decided as "option (2)":
>
>    (2) Treat NSIS like as, i.e. keep it in Mingw-cross-env and
>        prefix its tools with i686-pc-mingw32.
>
> What do you think about it?

It sounds reasonable, it seems to be more like as and it's generally
better to clean up exceptions. Even if there isn't a shared usr/bin,
it's still very clear what these programs output.

I was also experimenting installing flex and other build time
requirements in usr/local and adding that to the PATH only in the
Makefile.

Tony