Re: RFC: x86_64-pc-mingw64 and getting it mapped out

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

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
>> yet.
>
> 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
package name.

>> 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
host/build/target designators.

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

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk