On 13/12/11 12:43, Earnie wrote:
> Keith Marshall wrote:
>> On 12 December 2011 12:56, Earnie <earnie@...> wrote:
>>> Keith Marshall wrote:
>>>> Here's a better reference, for [1]:
>>>> http://www.gnu.org/software/autoconf/manual/autoconf.html#Specifying-Target-Triplets
>>>
>>> Which supports that I mean target.
>>
>> Read it again. It does no such thing.
>>
>> w32api is a library-only package. There is no code generator provided,
>> therefore target is completely meaningless.
>
> --target=target-type
> the type of system for which any compiler tools in the package produce
> code (rarely needed). By default, it is the same as host.
>
> You're saying w32api isn't part of the compiler tools, rubbish.
I'm saying no such thing; YOU are attempting to put words in my mouth,
in a puerile attempt to defend your own position of wilful ignorance.
The only rubbish in evidence here is the shit filling the void between
your own ears. (Sorry if that seems harsh, but when the cap fits...)
What part of the phrase "compiler tools [which] produce code" is so
difficult to understand? What component, PROVIDED BY W32API, do you
consider as fulfilling this criterion, whereby $target might become
meaningful? For that matter, what component PROVIDED BY W32API, is even
RUNNABLE? To be able to produce code, a tool must, in the first
instance, be a runnable program.
>>> When --build=cygwin --host=cygwin --target=cygwin we want
>>
>> Sure, this is equivalent to a native build on cygwin, with none of these
>> specified, (or needed), so yes...
>>
>>> ${prefix}/include/w32api and ${exec_prefix}/lib/w32api.
>>
>> ...this is correct.
>>
>>> When --build=cygwin --host=cygwin --target=mingw we want
>>> ${prefix}/include and ${exec_prefix}/lib.
>>
>> Nope. 100% dead WRONG; target is meaningless, and this is EXACTLY
>> equivalent to your preceding example: native cygwin build for cygwin
>> host, (it will use the native cygwin compiler and tools to build the
>> object files and libraries), so again we want:
>>
>> ${prefix}/include/w32api and ${exec_prefix}/lib/w32api
>
> No we do not.
Yes, we DO! Or, would you offer a build of w32api with compiled-in
dependencies on cygwin-1.dll, (because that's what you get by selecting
cygwin's native compiler, i.e. $build == $host == cygwin), as suitable
for deployment as part of your MinGW compiler suite? How's that going
to work, exactly?
--target=mingw does not do what you think here. In fact, but for the
present BROKEN usage within the existing build system, it would do
nothing at all, for it would be meaningless; the present broken usage
serves only to allow you to subvert the appropriate selection of a
packaging convention, and so ultimately, to deliver a broken package.
> If we target MinGW we want it without the w32api. Just
> because this is a library the compiler will use doesn't mean that
> --target is useless, it is part of the compiler tool set.
Yes, it is part of the compiler tool suite. That doesn't imply that
--target is automatically useful. It isn't; it is meaningless here.
This is a common source of confusion: when you say you "target" MinGW,
what you really mean is you "build for deployment to $host = mingw32";
to specify this, you use --host=mingw32, NOT --target=mingw32.
If it helps, it is perhaps convenient to think of $target as a place
holder, used ONLY when you build the compiler APPLICATION PROGRAM, (but
NOT when you build its supporting libraries), for what will eventually
become the value assigned to $host, when you run that compiler program,
(including when you run the phase-1 build of that compiler, to build its
own support libraries). Beyond this context, (i.e. initialisation of
the effective $host when you RUN the compiler PROGRAM), $target is
meaningless. You never RUN the libraries; there is no concept of them
initialising $host, so there can be no meaningful reason to define
$target when you build them).
>>> When --build=mingw --host=mingw --target=cygwin we want
>>> ${prefix}/include/w32api and ${exec_prefix}/lib/w32api.
>>
>> Wrong again. What code generator, PROVIDED BY W32API, do you anticipate
>> running on your mingw host, which will subsequently cross-compile code
>> for the cygwin target? There is none, so --target=cygwin is completely
>> meaningless. This is just a native mingw build for a mingw host, so we
>> want:
>>
>> ${prefix}/include and ${exec_prefix}/lib
>>
>> To clarify this further, consider the case of building a linux-->mingw32
>> cross-compiler. We begin by building just the C language GCC compiler,
>> configured with:
>>
>> --build=i686-linux --host=i686-linux --target=mingw32
>>
>> This builds the linux-->mingw32 gcc-cross-compiler, to run on the linux
>> host, and to generate code for deployment on the mingw32 ultimate host.
>> We then use this gcc-cross-compiler to build the mingwrt and w32api
>> supporting libraries, (which must also be built for deployment on the
>> mingw32 ultimate host); when we do this, we shift the configure options
>> to the left, so they become:
>>
>> --build=i686-linux --host=mingw32
>>
>> and --target becomes nothing, (so it simply disappears).
>
> But why? I want to host the build on Linux and target MinGW.
Simply because it is the right thing to do. You appear to have a
fundamental misunderstanding of the formal relationship (which autoconf
defines) between $build and $host, and between $host and $target:
$target DOES NOT convey the meaning you seem to think.
In this example, you want to STAGE your BUILD on Linux:
--build=i386-linux
and you will DEPLOY the code you build TO a MinGW HOST:
--host=mingw32
Specifying --target=mingw32 conveys nothing useful here. Reading the
next section but one, following the quote above in the autoconf manual:
| The above examples all show ‘$host’, since this is where the code is
| going to run. Only rarely is it necessary to test ‘$build’ (which is
| where the build is being done).
|
| ...
|
| ‘$target’ is for use by a package creating a compiler or similar.
| For ordinary packages it's meaningless and should not be used. It
| indicates what the created compiler should generate code for, if
| it can cross-compile.
The operative phrase here is, "if it can cross-compile". While w32api
may be, (and indeed is), a fundamental and essential adjunct to the
compiler suite, it DOES NOT provide ANY component or tool which can
itself cross-compile, (or even compile, for that matter). While you
MUST build it, (or otherwise furnish it), to complement the compiler
suite, you build it just as you would any other (ordinary) library which
adds other (perhaps non-fundamental) capability to the code you use the
compiler suite to build. In this sense, it is just another ordinary
package, so by the above criterion $target is meaningless. It must
comprise object code suitable for running where any other code compiled
by this same compiler will run; that is the platform which is designated
by $host, at the time when you RUN (rather than when you BUILD) the
compiler.
Now, you may argue that the immediately following sentence:
| ‘$target’ generally selects various hard-coded CPU and system
| conventions, ...
may be construed as justification for abusing $target, for the purpose
of specifying a packaging convention. IMO however, since the preceding
statement should render $target to be meaningless, such that it "should
not be used", that becomes just another puerile argument; the packaging
convention may be perfectly reliably predicated on the value of $host,
without requiring any potentially confusing abuse of a $target value, in
a context where it is fundamentally meaningless.
>> Finally, with these supporting libraries available, we complete the GCC
>> build, to add any other language components desired; we do this with the
>> configure options specifying:
>>
>> --build=i686-linux --host=i686-linux --target=mingw32
>>
>> because we are again building code generators which will run on the
>> linux host, to generate code for deployment on the mingw32 ultimate
>> host; however, at no time do we specify --target=anything when we build
>> the mingwrt or w32api supporting libraries, because to do so would be
>> irrelevant.
>>
>> target is relevant ONLY when building a code generator; the reference I
>> cited makes this abundantly clear:
>> | --target=target-type
>> | the type of system for which any compiler tools in the package
>> | produce code (rarely needed).
>
> I say that the libraries are part of the compiler tools.
I do not dispute this; I do say that the libraries MUST be built for
deployment TO the HOST where the code, generated by the compiler tools,
will itself be deployed. This is designated by --host, NOT --target, so
within the configure && make process it is determined by $host; it is
NOT determined by $target.
This statement in no way undermines the assertion that the libraries are
a part, (indeed a fundamental part), of the compiler SUITE. They simply
are NOT, however, of themselves actually TOOLS.
> Really I do mean target ...
You may think you do, but I assert that you are wrong; in the sense in
which it is defined by autoconf, (and that is what MUST apply, since we
are discussing defects of a build system originating with an autoconf
generated configure script), you mean host. You appear to be hung up on
a misconception that $host represents what is actually represented by
$build, and that $target represents what really is $host.
> and do not believe that you've interpreted this wording correctly ...
My interpretation is based on several years of concrete experience,
backed up by clarifying discussion on the autoconf ML...
> ... just as you believe that I've misread them. Without the
> w32api library in ${prefix}/[include|lib]/w32api the Cygwin compiler
> which is built on Linux as --host=linux --build=linux --target=cygwin
> cannot execute.
This is not strictly true; if it were, you would never be able to build
those libraries in the first place. It is true that the compiler will
not be able to create executables, (because these will require linkable
objects furnished by those libraries), but it can still produce object
code for subsequent linking. This is why, in the build processes for
GCC itself, and for mingwrt and w32api, we must jump through hoops to
circumvent AC_PROG_CC's insistence that it must select a build time
compiler which can create executables.
> I need to target w32api library as --host=linux --build=linux
> --target=cygwin as well.
Did you even consider TESTING this bogus assertion, before you rushed
into print? I can tell you now that it will not work:
--host=linux --build=linux
tells configure to choose the $build's own native compiler, (which,
if it even succeeds in compiling the source, will generate ELF object
code). Since there are no tools, within the w32api package, which
themselves generate code:
--target=cygwin
will simply be ignored, for there is NOTHING to which it might apply.
How well do you anticipate that a w32api library suite, comprising ELF
object code modules, will deploy within a cygwin compiler suite, for
which the required object code format is PECOFF? You need to compile
w32api with a compiler which generates Cygwin-PECOFF object code. On a
Linux $build, that MUST be a linux-->cygwin cross-compiler, and to
instruct configure to enter cross-compiling mode, with selection of the
appropriate cross-compiler, you MUST specify[*]:
--build=i386-linux --host=i386-cygwin
and specifying --target is pointless, since it is meaningless in this
context.
[*] specifying i386 as the most basic cpu-type within the x86 family,
since config.sub does not recognise either linux or cygwin, without any
such qualification, as valid system type aliases; (however, it DOES
accept mingw32, as an alias for i386-pc-mingw32).
> I disagree strongly. The libraries supporting the compiler are as much
> a part of the compiler tool set as the compiler itself is.
I'll say it again: I DO NOT dispute this. Of course the libraries are
as much a fundamental and essential part of the compiler suite as is the
compiler itself. However, this does not in any way conflict with my
earlier assertion that the library packages provide no more than just
that -- libraries, and as such they are fundamentally no different (in
structure) from any other (ordinary) library. Nor does it necessarily
imply that the criteria which apply when building these libraries must
be identically the same as those which apply when building the compiler
tools; in this case, they are NOT the same, and if you force them to be
so, you will not be able to successfully build the entire suite.
Until you accept this fundamental reality, this entire discussion is
futile. I shall not be responding to any further bullshit, in which you
continue to merely reassert your present misconceptions.
--
Regards,
Keith.
|
