On Thu, Jul 4, 2013 at 7:09 AM, Keith Marshall wrote:
> On 03/07/13 21:21, Earnie Boyd wrote:
>> This is not mimicking mingw-w64, not even close. It really has to
>> do with me thinking aloud.
>> My thought is that the host/target directories for various cross
>> compilers would contain the appropriate libraries.
> The concept of "target" doesn't apply to libraries, (because they don't
> *generate* code; they furnish code which has been generated already for
> a specific "host"). You are correct, in your subsequent references to
The linker must use the libraries specified for the target. While
building the library you use --host but when building the compiler and
linker you specify --target which will use the libraries you build
with --host. In this understanding my use of target is correct.
>> So if the user wants sjlj it goes in one named for that host. Or if
>> he wants dwarf2 it goes in that host. And then you add varying
>> threading models (currently a count of three); but we would choose
>> one hopefully but dwarf2 isn't supported in 64bit Windows versions
> I understand the intent; my concern is the maintenance burden.
I don't see it any harder to maintain than it is now. We need to do
something to help easily identify what's delivered in the package by
>> So you could do --host=i686-pc-mingw-dwarf2win32 for dwarf2 exceptions
>> and win32 threading model. Or do --host=i686-pc-mingw-dwarf2pthreads
>> for the dwarf2 exceptions and pthreads threading model.
> Sure. It's ugly, but not otherwise contentious. I would prefer that we
> retain the "mingw32" vs. "mingw64" distinction, because that's how
> mingw-get will discriminate between 32-bit and 64-bit packages.
We can retain it for the package names. I prefer to remove it for the
>> I'm not saying we distribute all of these but we have one set and
>> give instruction on using the source to create a cross. I agree it
>> is ugly but it does allow for proper use of the configure script and
>> the process picking the correct compiler for the users desires.
> Okay. There's nothing improper in that, but ... who's going to address
> the burden of documenting it?
Yeah, we need some help. We can create a starter page on the wiki and
plead for help in finishing it.
>>>> The user then uses -m32 or -m64 for if they want the alternative
>>>> library set. While this has some benefits I see this nearly
>>>> close to -mno-cygwin.
>> But it does support the lib/ lib32/ and lib64/ idea ...
> Does that really convey a significant advantage? Given ...
>>>> I would prefer we offer cross compilers 32bit to 64bit and 64bit to
>>>> 32bit and the user specifies the --host to configure.
> ... that each such cross-compiler will live in it's own distinct tree,
> so each will have its own host specific sysroot/subtree, in which all of
> its pertinent headers and libraries will reside. Your lib/ lib32/
> lib64/ arrangement only has benefit for a multi-arch compiler, which you
> are saying you would prefer not to offer. I agree with that preference:
> we may not have the manpower to maintain such a beast.
Right, I see no advantage to lib32 and lib64 other than confusion.
>> While we can go with mingw[32|64] as the host and
>> config.guess/config.sub are already coded for it. My question leads
>> me to do we want to? I don't care if we do; but should we consider
>> other options?
> My existing linux hosted cross-compiler is selected by a simple:
> $ .../configure --host=mingw32 ...
> It would be a minor inconvenience, (but an inconvenience nonetheless),
> if you were to demand that I rebuild it to require:
> $ .../configure --host=i686-pc-mingw ...
Yes, slight inconvenience but ...
> More crucially, I routinely use the $host_os component, derived from
> that via AC_CANONICAL_HOST, in my makefiles, to deduce the designated
> "sysroot" into which mingw-get should install generated packages; we
> need to preserve "mingw32" and "mingw64" to avoid ...
I'm not really understanding this issue. The first part of the
triplet will give you the bitness.
>> Because a user could accidently select a 64bit package to be
>> installed for his 32bit system, which would fail to work, ...
> The "accident" shouldn't occur, provided we keep the two separate
> $host_os classifications, because mingw-get will install the two into
> independent sysroots.
So you're saying it would be /mingw/mingw32 and /mingw/mingw64?
>> No need to get defensive or hostile about it;
> Neither was intended. However, you invited a discussion of a
> fundamental design decision, which I consider to be non-negotiable;
> mingw-get should not change its behaviour, based on whether it happens
> to have been built as a 32-bit or a 64-bit application, so let's not
> waste any more time in this blind alley.
>> we just need to understand how to help the user not install the wrong
>> thing. Suggestions for that appreciated.
> mingw-get will DTRT, provided we keep the sysroot classifications
> unambiguous; "mingw32" and "mingw64" packages would be installed to
> independent, sysroot and architecture specific, directory trees.
So I'm envisioning a user would install mingw64-gcc and mingw-get
would put the contents into ../ directory as it does today. Later
that same user wants g++ but forgets and accidentally installs
mingw32-g++ which will cause mingw-get to put the contents into ../ so
now he has corrupted his build environment.
But you're saying that mingw-get would rather install into ../mingw32/
or ../mingw64/ for each respective package? If that is the case then
the sysroot should be specified in the package xml data. I kind of
like that idea, the user would need to modify his PATH to use one or
the other. A helper script might be warranted to set the environment.
Maybe something like
alias setenv='. /bin/setenv'
$ setenv mingw32
$ setenv mingw64
and the setenv script would modify PATH by replacing the
/mingw/mingw32 or /mingw/mingw64 as appropriate.