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

[Volker Grabsch]

Tony Theodore <address@hidden> schrieb:
> On 20 April 2010 21:13, Volker Grabsch <address@hidden> wrote:
> > Tony Theodore <address@hidden> schrieb:
> >>
> >> 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.

Why do we need different library directories at all? Since we
have different target prefixes, everything should go into "lib".
That's it. So we'd have:

    usr/i686-w64-mingw32/lib/

and

    usr/x86_64-w64-mingw32/lib/

What's the problem?

BTW, why does the 64-bit prefix end with "...-mingw32" instead
of "...-mingw64" or just "...-mingw"?

And why is the vendor noted as "...-w64-..." instead of the
more usual "...-pc-..."?

Is it just a matter of taste of the mingw-w64 people, or are
there good reasons I should know about?

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

I really hope that we can fix all packages in a way that they
build successfully on both platforms, 32-bit and 64-bits.

> > 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.

Okay, so I'll fix that.

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

Oh, I don't think this is a good idea. It was always very helpful
for debugging that one could execute the build commands of the
src/*.mk directly at the command line (except for trivial place
holders such as "$(TARGET)").

Also, why should we use a different Flex than the one of the
operating system? That might lead to a lot of confusion.

I generally don't like the idea that a "$(MAKE)" during "make zlib"
might produce different results than calling it by hand, outside
the mingw-cross-env Makefile ("cd tmp-zlib/zlib-1.2.5/ ; make").

Sorry for stopping you on that, but I fear that this might go
into a horribly bad direction.


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR