From: Keith M. <kei...@us...> - 2011-12-07 20:41:20
|
I am following up on the issues raised in: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3063296&group_id=2435 https://sourceforge.net/tracker/?func=detail&aid=3447137&group_id=2435&atid=302435 https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3441135&group_id=2435 Initially, considering w32api, I plan to discard the aclocal.m4 file, which isn't currently, and never has been, relevant to this package. I would also like to take this opportunity to replace configure.in, as it currently exists, with a cleaned-up configure.ac, to bring us in line with current autoconf convention. Could some of the cygwin aficionados here please help me to understand the rationale behind the following obscure fragments from the makefiles of these packages? > host_alias = @host@ > build_alias = @build@ > target_alias = @target@ This just seems wrong to me. Firstly, autoconf attributes a clearly defined meaning to host_alias, build_alias, and target_alias; this does not respect that meaning, so is at the very least confusing. Secondly, neither of these packages has any reason to consider 'target'; that is specific to building code generators, (e.g. compilers); there are none provided by either of these packages, for which the conventional use of 'target' is completely meaningless. > with_cross_host = @with_cross_host@ What is this? It isn't a standard autoconf option, but its name suggests that it should derive from a user-defined --with-cross-host option. However, that would require an AC_ARG_WITH specification in configure.ac, to implement it; I see no such specification, either provided within the packages themselves, or in the top winsup directory, (whence it could have been inherited). > prefix = @prefix@ > exec_prefix = @exec_prefix@ > > ifeq ($(target_alias),$(host_alias)) > ifeq ($(build_alias),$(host_alias)) > tooldir = ${exec_prefix} > else > tooldir = ${exec_prefix}/$(target_alias) > endif > else > tooldir = ${exec_prefix}/$(target_alias) > endif > ifneq (,$(findstring cygwin,$(target_alias))) > includedir = $(tooldir)/include/w32api > libdir = $(tooldir)/lib/w32api > else > ifneq (,$(with_cross_host)) > includedir = $(tooldir)/include/w32api > libdir = $(tooldir)/lib > else > includedir = @includedir@ > libdir = @libdir@ > endif > endif (I've cleaned this up somewhat, but its essence is preserved). I can see WHAT effect this has; I just can't understand WHY it should do this. My confusion stems from: 1) Predicating ANYTHING on 'target', (in the autoconf sense, as it is subverted here to improperly define 'target_alias'), MUST be WRONG, as 'target' itself should have no legitimate meaning for either of these packages. 2) Why should it matter whether I'm performing a self-hosted or a cross-hosted build, (host == build vs. host != build)? Surely, the ONLY condition that SHOULD matter is: does 'host' match "*cygwin*", or not? I'm completely confident that I can DTRT in respect of a deployment for mingw32; I'm less confident in respect of cygwin, since I don't have a clear understanding of the requirements. FWIW, if I configure with: > configure --build=i686-linux --host=mingw32 (which is appropriate for a cross-hosted build for mingw32 deployment), I arrive at this configuration: > host_alias = i386-pc-mingw32 > build_alias = i686-pc-linux-gnu > target_alias = i386-pc-mingw32 > with_cross_host = > prefix = /usr/local > exec_prefix = ${prefix} > includedir = ${prefix}/include > libdir = ${exec_prefix}/lib This, with appropriate adjustment of $prefix, is correct for mingw32 deployment, either directly using 'make install', or when building the package set with 'make dist'. OTOH, if I subvert this to: > configure --build=i686-linux --host=mingw32 --target=i386-cygwin I arrive at: > host_alias = i386-pc-mingw32 > build_alias = i686-pc-linux-gnu > target_alias = i386-pc-cygwin > with_cross_host = > prefix = /usr/local > exec_prefix = ${prefix} > tooldir = ${exec_prefix}/$(target_alias) > includedir = ${tooldir}/include/w32api > libdir = ${tooldir}/lib/w32api This means that, for a mingw32 deployable build destined for a cygwin target, (whatever that might mean), installation will be directed to: ${prefix}/i386-pc-cygwin/include/w32api/*.h ${exec_prefix}/i386-pc-cygwin/lib/w32api/lib*.a with default substitution of /usr/local for both ${prefix} and ${exec_prefix}; these installation paths, with initial / stripped off, will also be reflected in the distributable binary package. Doesn't look sane to me, but what do I know? Is this what you guys want? -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-12-07 21:32:28
|
Keith Marshall wrote: > This means that, for a mingw32 deployable build destined for a cygwin > target, (whatever that might mean), installation will be directed to: > > ${prefix}/i386-pc-cygwin/include/w32api/*.h > ${exec_prefix}/i386-pc-cygwin/lib/w32api/lib*.a > > with default substitution of /usr/local for both ${prefix} and > ${exec_prefix}; these installation paths, with initial / stripped off, > will also be reflected in the distributable binary package. Doesn't > look sane to me, but what do I know? Is this what you guys want? > Yes, in Cygwin, w32api is delivered and required as /usr/include/w32api and /usr/lib/w32api. The mingwrt and w32api on the other hand is delivered in a cross tools directory for mingw32-gcc in /usr/i686-pc-mingw32/sysroot/mingw/. This though may be handled by cygport? -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Keith M. <kei...@us...> - 2011-12-07 23:28:50
|
On 07/12/11 21:32, Earnie wrote: > Keith Marshall wrote: >> This means that, for a mingw32 deployable build destined for a cygwin >> target, (whatever that might mean), installation will be directed to: >> >> ${prefix}/i386-pc-cygwin/include/w32api/*.h >> ${exec_prefix}/i386-pc-cygwin/lib/w32api/lib*.a >> >> with default substitution of /usr/local for both ${prefix} and >> ${exec_prefix}; these installation paths, with initial / stripped off, >> will also be reflected in the distributable binary package. Doesn't >> look sane to me, but what do I know? Is this what you guys want? > > Yes, in Cygwin, w32api is delivered and required as /usr/include/w32api > and /usr/lib/w32api. Okay. I probably need to think about it some more, but right now I don't see how the current logic can deliver this. For a completely self-hosted cygwin build, $build == $host == $target, (and, despite the improper naming within the makefile, as $*_alias, it is these which are actually examined); also, all three will incorporate the "cygwin" tag. Thus, $(tooldir) will be set equal to ${exec_prefix}, (which will be /usr/local by default, but can be easily overridden to make it /usr), and, since "cygwin" IS present within (misnamed) $(target_alias), the only logic path which can resolve to includedir = /usr/include/w32api and libdir = /usr/lib/w32api will be blocked by a FALSE predicate. I can't check it, because an all-native build on a linux host fails, but if I'm interpreting the logic correctly, the TRUE predicate, assuming that $with_cross_host is an empty string, (and there's no legitimate reason that I can see,why it would be anything else), will lead to includedir = /usr/include and libdir = /usr/lib, (assuming --prefix=/usr). So, what am I missing? > The mingwrt and w32api on the other hand is delivered in a cross tools > directory for mingw32-gcc in /usr/i686-pc-mingw32/sysroot/mingw/. This > though may be handled by cygport? Well, I see absolutely no way to EVER get to that; if I specify (and I consider this to be a hideous kludge) --target=i386-cygwin, I get: ${exec_prefix}/i386-pc-cygwin/include/w32api ${exec_prefix}/i386-pc-cygwin/lib/w32api (note reference to cygwin platform, NOT mingw32). OTOH, if I DON'T specify --target=i386-cygwin, and keep $with_cross_host empty, I get: ${prefix}/include ${exec_prefix}/lib or, if I export $with_cross_host=anything, I get: ${exec_prefix}/i386-pc-mingw32/include/w32api ${exec_prefix}/i386-pc-mingw32/lib none of which seem to match what you say is required, (apart from ${prefix}/include and ${exec_prefix}/lib being absolutely correct for any self-hosted or anything-->mingw32 cross-hosted build). Oh, and yes, those mappings which don't match the mingw32 native pattern really DO use ${exec_prefix} rather than ${prefix}, which is technically incorrect per GCS, but maybe the cygwin folks don't care about this? -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-12-08 14:10:09
|
Keith Marshall wrote: > On 07/12/11 21:32, Earnie wrote: >> Keith Marshall wrote: >>> This means that, for a mingw32 deployable build destined for a cygwin >>> target, (whatever that might mean), installation will be directed to: >>> >>> ${prefix}/i386-pc-cygwin/include/w32api/*.h >>> ${exec_prefix}/i386-pc-cygwin/lib/w32api/lib*.a >>> >>> with default substitution of /usr/local for both ${prefix} and >>> ${exec_prefix}; these installation paths, with initial / stripped off, >>> will also be reflected in the distributable binary package. Doesn't >>> look sane to me, but what do I know? Is this what you guys want? >> >> Yes, in Cygwin, w32api is delivered and required as /usr/include/w32api >> and /usr/lib/w32api. > > Okay. I probably need to think about it some more, but right now I > don't see how the current logic can deliver this. For a completely > self-hosted cygwin build, $build == $host == $target, (and, despite the > improper naming within the makefile, as $*_alias, it is these which are > actually examined); also, all three will incorporate the "cygwin" tag. > Thus, $(tooldir) will be set equal to ${exec_prefix}, (which will be > /usr/local by default, but can be easily overridden to make it /usr), > and, since "cygwin" IS present within (misnamed) $(target_alias), the > only logic path which can resolve to includedir = /usr/include/w32api > and libdir = /usr/lib/w32api will be blocked by a FALSE predicate. > My opinion is that it should only need to be /usr/include/w32api during the install phase of a Cygwin target. > I can't check it, because an all-native build on a linux host fails, but > if I'm interpreting the logic correctly, the TRUE predicate, assuming > that $with_cross_host is an empty string, (and there's no legitimate > reason that I can see,why it would be anything else), will lead to > includedir = /usr/include and libdir = /usr/lib, (assuming --prefix=/usr). > > So, what am I missing? > Some history maybe. Cygnus developed this stuff before autoconf improvements came about. >> The mingwrt and w32api on the other hand is delivered in a cross tools >> directory for mingw32-gcc in /usr/i686-pc-mingw32/sysroot/mingw/. This >> though may be handled by cygport? > > Well, I see absolutely no way to EVER get to that; if I specify (and I > consider this to be a hideous kludge) --target=i386-cygwin, I get: > > ${exec_prefix}/i386-pc-cygwin/include/w32api > ${exec_prefix}/i386-pc-cygwin/lib/w32api > > (note reference to cygwin platform, NOT mingw32). OTOH, if I DON'T > specify --target=i386-cygwin, and keep $with_cross_host empty, I get: > > ${prefix}/include > ${exec_prefix}/lib > > or, if I export $with_cross_host=anything, I get: > > ${exec_prefix}/i386-pc-mingw32/include/w32api > ${exec_prefix}/i386-pc-mingw32/lib > > none of which seem to match what you say is required, (apart from > ${prefix}/include and ${exec_prefix}/lib being absolutely correct for > any self-hosted or anything-->mingw32 cross-hosted build). > > Oh, and yes, those mappings which don't match the mingw32 native pattern > really DO use ${exec_prefix} rather than ${prefix}, which is technically > incorrect per GCS, but maybe the cygwin folks don't care about this? > I don't know that it is "cygwin folks don't care" as much as it is a historical development that no one has taken the time to improve. I do see that the original 1.3.3 version of the top-level configure.in file (which was not an autoconf input file) has been removed and replaced with an autoconf configure.ac file which happened back in 2007. So as long as the Cygwin target installs to /usr/include/w32api and /usr/lib/w32api there shouldn't be an issue with changes. The same for mingwrt, if Cygwin target install to /usr/include/mingw and /usr/lib/mingw. The winsup configure script does traverse to winsup/mingw to build it. So the packager must remove the directories before packaging it up. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Keith M. <kei...@us...> - 2011-12-08 22:30:07
|
On 08/12/11 14:09, Earnie wrote: > My opinion is that it should only need to be /usr/include/w32api > during the install phase of a Cygwin target. Undoubtedly, some of the prevalent confusion stems from such careless misuse of terminology, (in the strict autoconf sense); by "target" here you actually mean "host". The "install" rule is used, not only to install to the final location, but also to create a staged installation snapshot, from which the deliverable tarball is packaged. Thus, if $prefix is set as /usr, the binary deliverable will also have usr/{include,lib}/w32api. This seems to be what the cygwin folks want. In the mingw32 case, we explicitly void $prefix, (and $exec_prefix) for the staged installation, and we don't append /w32api. Thus, our binary distributable simply has include and lib. >> So, what am I missing? > > Some history maybe. Cygnus developed this stuff before autoconf > improvements came about. While it may be interesting, the history cannot explain how the current logic implementation would deliver what is expected; AFAICS, it will DTRT in only a few limited build environments -- in the general case, it appears to me that it is definitively broken. -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-12-09 12:59:59
|
Keith Marshall wrote: > On 08/12/11 14:09, Earnie wrote: >> My opinion is that it should only need to be /usr/include/w32api >> during the install phase of a Cygwin target. > > Undoubtedly, some of the prevalent confusion stems from such careless > misuse of terminology, (in the strict autoconf sense); by "target" here > you actually mean "host". > No, I really mean target. I can host a cygwin target on a mingw, linux, etc. host. In this case I need the w32api headers in include/w32api and libraries in lib/w32api regardless of which host it is destined for. I can also host a mingw target on a cygwin host in which case the headers and libraries need to be in include and lib respectfully. > The "install" rule is used, not only to install to the final location, > but also to create a staged installation snapshot, from which the > deliverable tarball is packaged. Thus, if $prefix is set as /usr, the > binary deliverable will also have usr/{include,lib}/w32api. This seems > to be what the cygwin folks want. > Yes, it makes sense. > In the mingw32 case, we explicitly void $prefix, (and $exec_prefix) for > the staged installation, and we don't append /w32api. Thus, our binary > distributable simply has include and lib. > Yes. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Keith M. <kei...@us...> - 2011-12-09 22:20:11
|
On 09/12/11 12:59, Earnie wrote: > Keith Marshall wrote: >> On 08/12/11 14:09, Earnie wrote: >>> My opinion is that it should only need to be /usr/include/w32api >>> during the install phase of a Cygwin target. >> >> Undoubtedly, some of the prevalent confusion stems from such careless >> misuse of terminology, (in the strict autoconf sense); by "target" here >> you actually mean "host". > > No, I really mean target. With respect, no you do not. If you don't get this, then perhaps you should go RTFM[1] again. You mean HOST; autoconf's TARGET is something very different[2]. > I can host a cygwin target on a mingw, linux, etc. host. Nope. You can STAGE a cygwin HOST on a mingw, linux, etc. BUILD. Then yes, to accompany that staged cygwin HOST > In this case I need the w32api headers in include/w32api and > libraries in lib/w32api relative to the cygwin HOST prefix, yes, this much is true; however... > regardless of which host it is destined for. ...this is nonsense. Those components are destined for the cygwin host exclusively. > I can also host a mingw target on a cygwin host Wrong again; you can STAGE a mingw HOST on a cygwin BUILD > in which case the headers and libraries need to be in include and > lib respectfully [sic]. Once again, relative to and exclusive to the mingw HOST prefix, yes. I agree that the terminology is potentially confusing, and frequently misunderstood; it is misunderstanding such as yours which has created the mess in which we now find ourselves. [1] http://www.gnu.org/s/hello/manual/autoconf/Hosts-and-Cross_002dCompilation.html [2] For the record, TARGET has meaning ONLY when building a compiler, assembler, or similar code generator; it specifies the platform which will become the ultimate HOST, when that compiler itself is run on the intermediate HOST for which you have build it. If you don't specify TARGET when building your compiler, in which case it will default to the same as HOST, or if if you do specify it as explicitly the same as HOST, then your compiler will be self-hosted; if you specify TARGET to differ from HOST, then it will be a cross-compiler. Since a library, such as w32api, ISN'T a code generator, you NEVER build it for a specific TARGET; it is ALWAYS specific to a HOST. To complete the picture, what you seem to be referring to as a host is, in reality, your BUILD platform. More specifically, BUILD is what you run your compiler on, (or even more specifically, what you would like your compiler tools to assume they are running on), and HOST is where what you are building will run. If BUILD == HOST, then your compiler must be self-hosted, (BUILD-->BUILD); if BUILD != HOST, then you are cross compiling, and you need a BUILD-->HOST cross-compiler. In both of these cases, the compiler must have been built with TARGET matching the HOST for which you will use it to compile code, but for the subsequently compiled code, TARGET is meaningless. Yes, I said it was potentially confusing, and the foregoing is likely about as clear as mud :( -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2011-12-09 23:34:57
|
On 09/12/11 22:20, Keith Marshall wrote: >> No, I really mean target. > With respect, no you do not. If you don't get this, then perhaps you > should go RTFM[1] again. Here's a better reference, for [1]: http://www.gnu.org/software/autoconf/manual/autoconf.html#Specifying-Target-Triplets -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-12-12 12:57:03
|
Keith Marshall wrote: > On 09/12/11 22:20, Keith Marshall wrote: >>> No, I really mean target. >> With respect, no you do not. If you don't get this, then perhaps you >> should go RTFM[1] again. > > 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. When --build=cygwin --host=cygwin --target=cygwin we want ${prefix}/include/w32api and ${exec_prefix}/lib/w32api. When --build=cygwin --host=cygwin --target=mingw we want ${prefix}/include and ${exec_prefix}/lib. When --build=mingw --host=mingw --target=cygwin we want ${prefix}/include/w32api and ${exec_prefix}/lib/w32api. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Keith M. <kei...@us...> - 2011-12-12 15:00:19
|
On 12 December 2011 12:56, Earnie <ea...@us...> 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. > 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 > 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). 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). It is rarely needed because the majority of packages do not provide compiler tools; both mingwrt and w32api are in this category -- indeed neither provides any tools of any kind, since both provide only libraries and their supporting header files. -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-12-13 12:43:52
|
Keith Marshall wrote: > On 12 December 2011 12:56, Earnie <ea...@us...> 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. >> 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. 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. >> 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. > 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. Really I do mean target and do not believe that you've interpreted this wording correctly 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. I need to target w32api library as --host=linux --build=linux --target=cygwin as well. > It is rarely needed because the majority of packages do not provide > compiler tools; both mingwrt and w32api are in this category -- indeed > neither provides any tools of any kind, since both provide only > libraries and their supporting header files. > I disagree strongly. The libraries supporting the compiler are as much a part of the compiler tool set as the compiler itself is. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Keith M. <kei...@us...> - 2011-12-14 22:09:29
|
On 13/12/11 12:43, Earnie wrote: > Keith Marshall wrote: >> On 12 December 2011 12:56, Earnie <ea...@us...> 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. |
From: Earnie <ea...@us...> - 2011-12-15 13:21:26
|
Keith Marshall wrote: > On 13/12/11 12:43, Earnie wrote: >> Keith Marshall wrote: >>> On 12 December 2011 12:56, Earnie <ea...@us...> 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. > I understand fully and I do not believe the intention to be solely left to that which produces code seeing that libraries that the compiler tools use to complete the set required by the compiler itself are to be excluded from the use of --target. Our w32api and mingwrt have a special assignment with regard to the --target to add /w32api and /mingw to the include and lib paths when the target is Cygwin. If I have a compiler that was configured with --host=linux --build=linux --target=cygwin then I need my w32api and mingw libraries for Cygwin to match the Cygwin requirement and that can only be accomplished with --target. The Cygwin compiler intrinsics look for windows.h in a default path of include/w32api and adds lib/w32api to the search paths for libraries. To not do so when I build w32api with --host=linux --build=linux --target=cygwin is, well, not polite of the package maintainer. You're saying that --host=cygwin --build=linux --prefix=/path/to/target is the way to go and I would say based on the documentation present, yes you're correct. But in that case --target is set to cygwin anyway because unless specified --target == --host. So when I say I mean target, I really mean target since target regardless of if I specify it directly via --target or indirectly via --host is still what needs to be keyed on. If we use the target variable we don't have complaints when someone DTWT since --host=cygwin specifies a --target of cygwin as well and if someone adds w32api to the GCC source to build a compiler with --host=linux --build=linux --target=cygwin it also works. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Keith M. <kei...@us...> - 2011-12-16 19:18:28
Attachments:
transcript
|
Okay, if we're past trading insults -- about which I felt decidedly uncomfortable, but could see little option to prod you out of the rut of misconception, without the intervention of a third party -- let's see if we can get back to rational and productive discussion. On 15/12/11 13:21, Earnie wrote: > Keith Marshall wrote: >> 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. > > I understand fully and I do not believe the intention to be solely left > to that which produces code seeing that libraries that the compiler > tools use to complete the set required by the compiler itself are to be > excluded from the use of --target. Our w32api and mingwrt have a > special assignment with regard to the --target to add /w32api and /mingw > to the include and lib paths when the target is Cygwin. Huh? I don't understand what you're trying to say here; it may be correct, if I didn't find it to be incomprehensible. > If I have a compiler that was configured with --host=linux --build=linux > --target=cygwin then I need my w32api and mingw libraries for Cygwin to > match the Cygwin requirement ... Which, as you note below, is ${prefix}/include/w32api for header files, and ${exec_prefix}/lib/w32api, where ${prefix} and ${exec_prefix} assume the values assigned when the cross-compiler is built, (either using the autoconf defaults, or perhaps more likely, defined by the user). > ... and that can only be accomplished with --target. Uhmm, not exactly. Yes, it is deduced from the value assigned to $target when the cross-compiler suite itself is configured, but when the libraries are built, (whether independently, or as an integral component of the overall cross-compiler build), that $target value *must* be promoted to $host; (see below). > The Cygwin compiler intrinsics look for windows.h in a > default path of include/w32api and adds lib/w32api to the search paths > for libraries. To not do so when I build w32api with --host=linux > --build=linux --target=cygwin is, well, not polite of the package > maintainer. But, you *can't* build w32api with these settings; (the attached session transcript shows you what happens, if you try). Those settings are correct for the gcc and binutils builds, but as I explained before, when building w32api and/or mingwrt (or other requisite libraries), the $build<--$host<--$target progression *must* have $target shifted left into $host, (and at this point, you must have already built a cross compiler for $build-->$target). If you build independently, then *you* must make that adjustment; if you build "in tree", as an integral component library, then the "outer" system makefiles *must* make the adjustment when invoking the "inner", (i.e. w32api, etc.) configure script, as prerequisite for the "inner" make. Really, it *is* $host which should predicate the choice of installation path; it's coincidental that $target would likely have the same value, and then only because it shouldn't be explicitly specified at all. > You're saying that --host=cygwin --build=linux --prefix=/path/to/target > is the way to go and I would say based on the documentation present, yes > you're correct. Yes, I think we can now agree that this is technically correct. > But in that case --target is set to cygwin anyway because unless > specified --target == --host. Sure, but just because that happens to be so, by coincidence, doesn't make it right to predicate a decision on this technically incorrect choice. > So when I say I mean > target, I really mean target since target regardless of if I specify it > directly via --target or indirectly via --host is still what needs to be > keyed on. I disagree; I can understand why you may believe that to be an acceptable compromise, but what if someone manages to really make $target != $host? That would certainly have an unpredictable, and likely undesirable outcome. > If we use the target variable we don't have complaints when > someone DTWT since --host=cygwin specifies a --target of cygwin as well > and if someone adds w32api to the GCC source to build a compiler with > --host=linux --build=linux --target=cygwin it also works. I might accept an argument in favour of keeping this incorrect usage, as a compromise, *provided* the rationale is documented in place, *if* it actually worked. However, AFAICT, it *doesn't* work! While I can build w32api for mingw32, using a linux-->mingw32 cross-compiler, this is entirely fortuitous, because the right choice is made when "cygwin" doesn't appear in *any* of $build, $host, or $target. OTOH, it appears to me that there is *no* *way* to build correctly for cygwin, *unless* $build == $host == $target == cygwin; i.e. a valid cygwin build can *only* be accomplished, using the current build system, by building *natively* on a cygwin machine; cross-compiling appears to be out of the question. We really ought to fix this, so why not do so correctly, instead of promulgating a nasty, kludgy, broken percept? -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-12-07 21:41:43
|
Keith Marshall wrote: > > Could some of the cygwin aficionados here please help me to understand > the rationale behind the following obscure fragments from the makefiles > of these packages? > >> host_alias = @host@ >> build_alias = @build@ >> target_alias = @target@ > I think this and the rest of your confusion stems from the old cygnus mode of autoconf. I'm probably wrong and Chuck can correct me. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Charles W. <cwi...@us...> - 2011-12-08 03:26:21
|
It's best to treat mingwrt and w32api separately. mingwrt: on cygwin, this is (now) only supported as part of the mingw cross tools. In the past, when 'gcc -mno-cygwin' was an alias for a mingwish compiler, cygwin wanted the mingwrt objects, libs, and headers to live in /usr/{include,lib}/mingw/ and the cygwin compiler's specs file Did The Right Thing(tm) to put those dirs into the compiler's -isystem search paths. However, *now*...cygwin doesn't care. So, here's what the cygwin mingw-runtime package's cygport build procedure is: ---- CROSS_HOST="i686-pc-mingw32" inherit cross cygconf # -nostdinc is used but w32api is assumed to be in parallel sources cygmake W32API_INCLUDE="-idirafter ${CROSS_SYSROOT}/mingw/include" ---- Note that cygport, when 'inherit cross' AND host is mingw, configures as: CHOST=$(__canonicalize_triplet ${CROSS_HOST}) CTARGET=${CHOST} CROSS_SYSROOT="/usr/${CHOST}/sys-root" prefix=${CROSS_SYSROOT}/mingw --build=${CBUILD} --host=${CHOST} --target=${CTARGET} --prefix=${prefix} --exec-prefix=${prefix} --bindir=${prefix}/bin \ --sbindir=${prefix}/sbin --libexecdir=${prefix}/lib \ --datadir=${prefix}/share --localstatedir=${prefix%/usr}/var \ --sysconfdir=${prefix%/usr}/etc --datarootdir=${prefix}/share --docdir=${prefix}/share/doc/${PN} CFLAGS="${CFLAGS} -mms-bitfields" CXXFLAGS="${CXXFLAGS} -mms-bitfields" F77FLAGS="${F77FLAGS} -mms-bitfields" FCFLAGS="${FCFLAGS} -mms-bitfields" GCJFLAGS="${GCJFLAGS} -mms-bitfields" OBJCFLAGS="${OBJCFLAGS} -mms-bitfields" OBJCXXFLAGS="${OBJCXXFLAGS} -mms-bitfields" So...working thru the variable replacements, you end up with mingw-runtime installing as: /usr/i686-pc-mingw32/sys-root/mingw/bin/mingwm10.dll (this is handled as a special case by the package-specific .cygport script) /usr/i686-pc-mingw32/sys-root/mingw/include/*.h /usr/i686-pc-mingw32/sys-root/mingw/lib/*.o /usr/i686-pc-mingw32/sys-root/mingw/lib/*.a /usr/i686-pc-mingw32/sys-root/mingw/share/man/man3/basename.3.gz /usr/i686-pc-mingw32/sys-root/mingw/share/man/man3/dirname.3.gz Now, w32api on the other hand, is needed by "true" cygwin compilers. BUT, they don't want those headers/libs to be commingled with posix ones, so they go into /usr/include/w32api /usr/lib/w32api In the past, the "cygwin gcc -mno-cygwin" flavor automatically added the w32api subdirectory to the search path, along with the mingw/ subdir -- but now the only supported mingwish compiler is a cygwin->mingw[64] cross one. So...the copy of w32api in /usr/{include,lib}/w32api is strictly for the use of the "true" cygwin compiler, and the cross-to-mingw compiler has its own copy, dumped directly into /usr/i686-pc-mingw32/sys-root/mingw/{include,lib} with no "w32api/" subdir. I'm not sure how cygwin w32api package is configured; the cygwin "-src" package is not provided in a way that reveals this information (no .cygport script, no build script, no cyg-specific readme...just an exploding tarball). You'll have to ask Chris Sutcliffe -- he maintains both the "cygwin" w32api package as well as the cygwin "mingw-w32api" version, for cygwin's mingw cross toolchain. One word of, perhaps, caution: one thing that has led to the current "cruftiness" of the mingwrt and w32api build system is the fact that it is embedded within the "src" tree along with winsup/cygwin, gcc, binutils, etc -- and somewhat supports that tree's rather arcane top-level build logic. Making the local build system more rational may end up breaking that top-level-driven usage. But...IMO that's just an argument for removing w32api and mingwrt from the src tree altogether, and spinning them off as completely separate repositories. I think this has come up before; IIRC the cygwin folks were not opposed, and even offered to host new repos for them on sourceware (outside of the "src" tree). Anybody remember more details on that? -- Chuck |
From: Chris S. <ir0...@gm...> - 2011-12-08 11:38:30
|
On 7 December 2011 22:25, Charles Wilson wrote: > It's best to treat mingwrt and w32api separately. Agreed. > mingwrt: on cygwin, this is (now) only supported as part of the mingw > cross tools. In the past, when 'gcc -mno-cygwin' was an alias for a > mingwish compiler, cygwin wanted the mingwrt objects, libs, and headers > to live in > /usr/{include,lib}/mingw/ > and the cygwin compiler's specs file Did The Right Thing(tm) to put > those dirs into the compiler's -isystem search paths. However, > *now*...cygwin doesn't care. So, here's what the cygwin mingw-runtime > package's cygport build procedure is: As Chuck said, mingwrt is a MinGW only package now. I build it using the cygport script Chuck provided, so it builds directly from the mingw.org hosted tarballs (i.e. I don't build it from CVS for Cygwin anymore). > I'm not sure how cygwin w32api package is configured; the cygwin "-src" > package is not provided in a way that reveals this information (no > .cygport script, no build script, no cyg-specific readme...just an > exploding tarball). You'll have to ask Chris Sutcliffe -- he maintains > both the "cygwin" w32api package as well as the cygwin "mingw-w32api" > version, for cygwin's mingw cross toolchain. I still build this from CVS for Cygwin, the mingw.org tarball for the Cygwin hosted MinGW cross compiler, and CVS for the native MinGW compiler. When building for Cygwin I execute the tried and true configure, make, make dist. Since I am using the native Cygwin compiler, I don't worry about --host, --build or --target (it Does The Right Thing with the existing configure magic, so I figured it's better not to play with things I don't fully understand). > One word of, perhaps, caution: one thing that has led to the current > "cruftiness" of the mingwrt and w32api build system is the fact that it > is embedded within the "src" tree along with winsup/cygwin, gcc, > binutils, etc -- and somewhat supports that tree's rather arcane > top-level build logic. Making the local build system more rational may > end up breaking that top-level-driven usage. Agreed, I can't speak for how the Cygwin developers compile w32api when building the Cygwin DLL. > But...IMO that's just an argument for removing w32api and mingwrt from > the src tree altogether, and spinning them off as completely separate > repositories. I think this has come up before; IIRC the cygwin folks > were not opposed, and even offered to host new repos for them on > sourceware (outside of the "src" tree). Anybody remember more details > on that? I seem to remember this as well. In fact I think the thought was to break apart the whole winsup repository, but I could be mistaken. I'll dig through my email tonight and see if I can track down the email chain. Cheers, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Earnie <ea...@us...> - 2011-12-08 13:35:52
|
Chris Sutcliffe wrote: > On 7 December 2011 22:25, Charles Wilson wrote: >> One word of, perhaps, caution: one thing that has led to the current >> "cruftiness" of the mingwrt and w32api build system is the fact that it >> is embedded within the "src" tree along with winsup/cygwin, gcc, >> binutils, etc -- and somewhat supports that tree's rather arcane >> top-level build logic. Making the local build system more rational may >> end up breaking that top-level-driven usage. > > Agreed, I can't speak for how the Cygwin developers compile w32api > when building the Cygwin DLL. > Yes, it is the Cygnus method. IIRC the top-level configure script isn't even an autoconf script and is designed to drive into the sub-directories to execute each package configure script. The Cygwin CVS played server side scripting magic to pull in various repositories such as newlib when you requested the Cygwin source. It is this same magic that could allow the offer of a separated repository hosted on sourceware.org. >> But...IMO that's just an argument for removing w32api and mingwrt from >> the src tree altogether, and spinning them off as completely separate >> repositories. I think this has come up before; IIRC the cygwin folks >> were not opposed, and even offered to host new repos for them on >> sourceware (outside of the "src" tree). Anybody remember more details >> on that? > > I seem to remember this as well. In fact I think the thought was to > break apart the whole winsup repository, but I could be mistaken. > I'll dig through my email tonight and see if I can track down the > email chain. It was mentioned by CGF years ago. I'm not as concerned today about where the repository lives or is structured as I am concerned about the future direction Cygwin will take vis a vis 64 bit Windows. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Keith M. <kei...@us...> - 2011-12-08 22:10:29
|
On 08/12/11 11:38, Chris Sutcliffe wrote: > As Chuck said, mingwrt is a MinGW only package now. I build it using > the cygport script Chuck provided, so it builds directly from the > mingw.org hosted tarballs (i.e. I don't build it from CVS for Cygwin > anymore). However you ultimately choose to build it, CVS is the definitive canonical source. Presumably you generate the mingw.org tarballs from it; the primary build system for that SHOULD support direct packaging to any reasonable standards base you might choose. If you've configured on, or even just for a cygwin host, 'make dist' should just work, and the resulting packages should be cygwin deployable OOTB: configure --build=i386-linux --host=mingw32 && make dist does exactly the right thing wrt reproducing the mingw.org tarballs; configure --build=i386-linux --host=mingw32 && make dist should do the same, on a cygwin $build platform, and: configure --build=foo --host=i386-cygwin && make dist should do likewise, should you wish to recreate a cygwin deployable distribution, (which you likely don't need any more, given Chuck's comments regarding continued need for such a package). > I still build [w32api] from CVS for Cygwin, the mingw.org tarball for > the Cygwin hosted MinGW cross compiler, and CVS for the native MinGW > compiler. When building for Cygwin I execute the tried and true > configure, make, make dist. Since I am using the native Cygwin > compiler, I don't worry about --host, --build or --target (it Does The > Right Thing with the existing configure magic, so I figured it's > better not to play with things I don't fully understand). On your cygwin platform, you SHOULD be able to build all three straight off, just by judicious specification of configure options; e.g.: mkdir -p build/cygwin build/mingw32 build/cross cd build/cygwin; rm -rf *; ../../configure && make dist to create the cygwin package; follow that with: cd ../mingw32 ; rm -rf * ../../configure --build=i386-cygwin --host=mingw32 && make dist to create the mingw32 package; then finish up with: cd ../cross ; rm -rf * ../../configure --prefix=/usr/i386-pc-mingw32/sys-root/mingw \ --build=i386-cygwin --host=mingw32 && make dist for the cygwin-->mingw32 cross. Now, I DO understand how that configure magic is set up, and I think that the latter two cases may already work; (but I haven't tested them exhaustively); the first SHOULD also work, but ONLY for $build == $host == cygwin. It SHOULD also work for me, (if I were to build myself a linux-->cygwin cross-compiler), with --build=i386-linux --host=i386-cygwin, yielding packages with the ${prefix}/include/w32api and ${exec_prefix}/lib/w32api structure; however, with the present logic implementation, I can't see how it can possibly DTRT; I'd like to fix that anomaly. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2011-12-08 17:44:34
|
On 08/12/11 03:25, Charles Wilson wrote: > It's best to treat mingwrt and w32api separately. Oh, I wasn't planning to merge them :-) I fully intend to keep them as entirely separate entities; however, even considered individually they do exhibit many similar peculiarities, which we may discuss generically. I plan to overhaul w32api first, since it seems relatively less complex. > mingwrt: on cygwin, this is (now) only supported as part of the mingw > cross tools. In the past, when 'gcc -mno-cygwin' was an alias for a > mingwish compiler, cygwin wanted the mingwrt objects, libs, and headers > to live in > > /usr/{include,lib}/mingw/ Which, if I've interpreted your message correctly, would imply that for any deployment aimed at --host=i386-cygwin, we should initialise: includedir = ${prefix}/include/mingw libdir = ${exec_prefix}/lib/mingw However, ... > and the cygwin compiler's specs file Did The Right Thing(tm) to put > those dirs into the compiler's -isystem search paths. However, > *now*...cygwin doesn't care. ... this implies that we no longer need to support this configuration. > So...working thru the variable replacements, [for a cross-compiler > build scenario], you end up with mingw-runtime installing as: > > /usr/i686-pc-mingw32/sys-root/mingw/bin/mingwm10.dll (this is handled as > a special case by the package-specific .cygport script) > /usr/i686-pc-mingw32/sys-root/mingw/include/*.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/*.o > /usr/i686-pc-mingw32/sys-root/mingw/lib/*.a > /usr/i686-pc-mingw32/sys-root/mingw/share/man/man3/basename.3.gz > /usr/i686-pc-mingw32/sys-root/mingw/share/man/man3/dirname.3.gz Well, there's nothing outlandish there. In fact, it's indistinguishable from the standard case, where: includedir = ${prefix}/include libdir = ${exec_prefix}/lib datarootdir = ${prefix}/share datadir = ${datarootdir} mandir = ${datarootdir}/man The builder of the cross-compiler system simply has to configure such that '${prefix} = /usr/i686-pc-mingw32/sys-root/mingw', and standard autoconf convention will take care of the rest. > Now, w32api on the other hand, is needed by "true" cygwin compilers. > BUT, they don't want those headers/libs to be commingled with posix > ones, so they go into > > /usr/include/w32api > /usr/lib/w32api This is analogous to the mingwrt case above, building with (applying proper autoconf convention) --host=i386-cygwin; easily accommodated, within a conventional (corrected) configure script, by: AC_INIT([MS-Windows API],[x.xx],[...],[w32api]) ... AS_CASE([$host],[*cygwin*], [test "x$includedir" = 'x${prefix}/include' \ && includedir=$includedir/$PACKAGE_TARNAME test "x$libdir" = 'x${exec_prefix}/lib' \ && libdir=$libdir/$PACKAGE_TARNAME ]) > ... the cross-to-mingw compiler has its own copy, dumped directly > into > > /usr/i686-pc-mingw32/sys-root/mingw/{include,lib} > > with no "w32api/" subdir. Once again, this is completely conventional; $host SHOULD be *mingw* (definitely no reference to *cygwin*), and the builder simply has to configure with $prefix appropriately specified, and standard autoconf convention will DTRT. > One word of, perhaps, caution: ... > Making the local build system more rational may end up breaking that > (winsup) top-level-driven usage. That's what I'm concerned about ... > But...IMO that's just an argument for removing w32api and mingwrt from > the src tree altogether, and spinning them off as completely separate > repositories. Maybe, if it's now becoming less critical from a cygwin perspective, we should just go ahead and rationalise; if that breaks the outer build, then either pull the repository out of winsup, or offer assistance to implement a proper fix at the upper level. > I think this has come up before; IIRC the cygwin folks were not > opposed, and even offered to host new repos for them on sourceware > (outside of the "src" tree). Anybody remember more details on that? I remember discussing the build logic with Corinna, after she'd added yet more layers of kludgy cruft. She couldn't explain what she'd done; seems like she just kept adding kludges, until she achieved her desired effect, without really understanding the intent of the GCS specified features she was abusing, and in the process, making an already bad implementation even worse. -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-12-08 22:00:36
|
Keith Marshall wrote: >> One word of, perhaps, caution: ... >> Making the local build system more rational may end up breaking that >> (winsup) top-level-driven usage. > > That's what I'm concerned about ... > >> But...IMO that's just an argument for removing w32api and mingwrt from >> the src tree altogether, and spinning them off as completely separate >> repositories. > > Maybe, if it's now becoming less critical from a cygwin perspective, we > should just go ahead and rationalise; if that breaks the outer build, > then either pull the repository out of winsup, or offer assistance to > implement a proper fix at the upper level. > Hmm... Shouldn't the winsup configure.in add the appropriate --includedir=$(prefix)/include/mingw and --libdir=$(prefix)/lib/mingw when it executes the configure script for that sub-directory? Is there something with AC_CONFIG_SUBDIRS to add to these options? -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Keith M. <kei...@us...> - 2011-12-08 22:50:09
|
On 08/12/11 22:00, Earnie wrote: > Hmm... Shouldn't the winsup configure.in add the appropriate > --includedir=$(prefix)/include/mingw and --libdir=$(prefix)/lib/mingw > when it executes the configure script for that sub-directory? Yes, that would be the correct approach. > Is there something with AC_CONFIG_SUBDIRS to add to these options? Not that I know of, but there are other ways to achieve the desired effect; simply running configure directly, with a filtered subset of the options specified to the outer instance, plus additional options as necessary, is always a possibility. Alternatively, it may be possible to fool the outer configure into thinking it had different options than it really had, when it comes to run config.status, (and hence processes the AC_CONFIG_SUBDIRS); I'd need to play with it, to confirm. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2011-12-24 22:30:33
|
I'd appreciate some further cygwin specific comment regarding the following analysis:-- On 07/12/11 14:08, Keith Marshall wrote: > I am following up on the issues raised in: > https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3063296&group_id=2435 > https://sourceforge.net/tracker/?func=detail&aid=3447137&group_id=2435&atid=302435 > https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3441135&group_id=2435 If we consider the w32api package, (so ${top_srcdir} would refer to a working copy of the src/winsup/w32api directory from sourceware.org), and we examine Makefile.in respectively in each of ${top_srcdir}/lib, ${top_srcdir}/lib/ddk and ${top_srcdir}/lib/directx, we see several references of the form ${srcdir}/.. and ${srcdir}/../..; these have clearly been manually encoded by the original maintainer, with intent to refer to ${top_srcdir}. This method of encoding is inherently unreliable, particularly since autoconf provides a definition for ${top_srcdir} which is guaranteed to generate the correct reference. Given that, in each case, ${srcdir} will always refer to directory in which the Makefile.in itself resides, in ${top_srcdir}/lib/Makefile.in any reference to ${srcdir}/.. must refer to ${top_srcdir} itself. By the same reasoning, any reference in ${top_srcdir}/lib/ddk/Makefile.in or in ${top_srcdir}/lib/directx/Makefile.in to ${srcdir}/../.. is also a reference to ${top_srcdir}. Now if I normalise all such ${srcdir}/.. and ${srcdir}/../.. to make them directly refer to ${top_srcdir}, (and if I elide references which are not germane to the point I wish to discuss), in lib/Makefile.in I see the following:-- $ grep '${top_srcdir}' lib/Makefile.in EXTRA_INCLUDES = -I ${top_srcdir}/../include \ -I ${top_srcdir}/../../newlib/libc/include \ -I ${top_srcdir}/../../newlib/libc/sys/cygwin EXTRA_INCLUDES = -I ${top_srcdir}/../mingw/include INCLUDES = -I ${top_srcdir}/include $(EXTRA_INCLUDES) (the first EXTRA_INCLUDES definition is cygwin specific; the second relates to MinGW). This seems mostly correct, with two exceptions:-- 1) ${top_srcdir}/../mingw/include is correct for a full winsup check out, but needs a fix-up for a tree built manually from MinGW.org source packages; I propose handling that using a --with-mingwrt-srcdir option to configure, similar to the --with-w32api-srcdir option proposed for the mingwrt package,on the third of the above tickets; it could use _mingw.h as a representative file for directory identification. 2) ${top_srcdir}/../include (in the cygwin EXTRA_INCLUDES) looks bogus; it would refer to src/winsup/include on sourceware.org, (and a comment in the file suggests that this is the intent); however, there is no such directory in the repository. Is this an error? Should I simply discard this phantom reference? Or, given this cygwin specific comment relating to the definition of EXTRA_INCLUDES: ifeq ($(BUILDENV), cygwin) # winsup/include # winsup/../newlib/libc/include # winsup/../newlib/libc/sys/cygwin do the cygwin developers anticipate that the currently non-existent src/winsup/include directory will become an imminent requirement? Or was the intent to refer to (libiberty's?) src/include directory, (from one level higher in the repository tree)? If so, is this needed? In lib/ddk/Makefile.in, and in lib/directx/Makefile.in, I see similar definitions:-- $ grep -r top_srcdir lib/ddk/Makefile.in EXTRA_INCLUDES = -I ${top_srcdir}/include \ -I ${top_srcdir}/../newlib/libc/include \ -I ${top_srcdir}/../newlib/libc/sys/cygwin EXTRA_INCLUDES = -I ${top_srcdir}/mingw/include $ grep -r top_srcdir lib/directx/Makefile.in EXTRA_INCLUDES = -I ${top_srcdir}/include \ -I ${top_srcdir}/../newlib/libc/include \ -I ${top_srcdir}/../newlib/libc/sys/cygwin EXTRA_INCLUDES = -I ${top_srcdir}/mingw/include However, these are clearly incorrect -- it appears that the original definitions, in terms of ${srcdir}/../, were simply copied verbatim from lib/Makefile.in, without regard for the extra level of removal from ${top_srcdir}. The same is true of the definition of INCLUDES, which also appears in each of these two files, but, lacking the appropriate ${srcdir}/../../ reference, escaped substitution: s,${srcdir}/\.\./\.\./,${top_srcdir}/,g so it remained (incorrectly specified), in lib/ddk/Makefile.in, as: INCLUDES = -I ${srcdir}/../include $(EXTRA_INCLUDES) and in lib/directx/Makefile.in, as: INCLUDES = -I ${srcdir}/../include \ -I ${srcdir}/../include/directx \ $(EXTRA_INCLUDES) Indeed, this is the underlying issue which each of the first two tickets sets out to address; the foregoing analysis shows that neither of the two patches originally proposed adequately addresses it. Thus, I propose to:-- 1) Replace all unreliable references of the form ${srcdir}/../... with normalised and corrected references, relative to ${top_srcdir}, and 2) Factor out the common EXTRA_INCLUDES definitions, into a single Makefile.comm.in file, to be included by all subdirectory makefiles as required, (as I've already done for other common makefile code). However, I would appreciate some guidance from the cygwin experts, on the following cygwin specifics:-- 1) Do we keep the reference to the non-existent winsup/include? If so, do we need a --with-winsup-include option to locate it? If we do, what possible criterion can we adopt to auto-detect it? 2) Should we provide a --with-libc-srcdir option to specify the location of the newlib headers, (as we need --with-mingwrt-srcdir)? If so, is existence of newlib.h a suitable auto-detection criterion? Is there a more suitable alternative? 3) The newlib/libc/sys/cygwin directory is currently empty; it did have content at one time, but this has been removed. Should we now drop the reference from w32api's makefiles? -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-12-25 02:36:47
|
On 12/24/2011 5:30 PM, Keith Marshall wrote: > I'd appreciate some further cygwin specific comment regarding the > following analysis:-- I've "starred" this message and will respond in a few days -- family commitments right now... FWIW, cgf has unsub'ed from this list (and corinna never was), so if you want their opinion on these issues you should send a copy privately (or, perhaps, start a similar thread on cygwin AT cygwin DOT com) -- but I'm sure you'll need to wait a few days for a reply in either case as well. -- Chuck |
From: Keith M. <kei...@us...> - 2011-12-25 07:02:31
|
On 25/12/11 02:36, Charles Wilson wrote: > On 12/24/2011 5:30 PM, Keith Marshall wrote: >> I'd appreciate some further cygwin specific comment regarding the >> following analysis:-- > > I've "starred" this message and will respond in a few days -- family > commitments right now... Understood. Merry Christmas. I'll be curtailing my own development activities for a day or two too. > FWIW, cgf has unsub'ed from this list Yeah, I saw that. > (and corinna never was), so if you > want their opinion on these issues you should send a copy privately (or, > perhaps, start a similar thread on cygwin AT cygwin DOT com) I've no personal interest in cygwin, (beyond having no desire to break it). IIRC, neither CGF nor Corinna welcome off-list mail; neither do I relish participating in a cygwin list in which I have no interest, beyond the impact of correcting this one issue. I did broach the subject with Corinna, some time ago. Her attitude was mostly "if it ain't broke, don't fix it", (which is a philosophy I too whole-heartedly endorse); at the time it didn't seem broken to her. We now see that it IS broken, so maintaining the status quo is no longer an option, and the crufty ugliness of it all is, at least partly, at the root of the problem. -- Regards, Keith. |