From: Charles W. <cwi...@us...> - 2009-06-21 22:38:58
|
I'm gearing up to refresh some of the packages I've created in the past for mingw and msys, especially the autotools. Now, the autotools come in two different flavors: 1) intended for use within an MSys environment for maintaining/building "native" mingw packages, and 2) intended for use within an MSysDvlpr environment for maintaining/building other MSYS packages. Based on previous discussions on this list, I propose that the autotools in category #1 follow this naming convention: autoconf-6-1-mingw32-bin.tar.lzma (wrapper) autoconf-6-1-mingw32-src.tar.lzma autoconf2.1-2.13-4-mingw32-bin.tar.lzma autoconf2.1-2.13-4-mingw32-src.tar.lzma autoconf2.5-2.63-1-mingw32-bin.tar.lzma autoconf2.5-2.63-1-mingw32-src.tar.lzma These would be configured with prefix=/mingw, and would be packaged from within /mingw so that they contain: bin/autoconf-2.63 bin/autoheader-2.63 ... etc. I'm also open to (a) possibly splitting the documentation out into a -doc pkg for each, and/or (b) using -dev in preference to -bin for the package that contains the actual scripts. However, this becomes tricky with regards to gettext. There's (a) the package that contains the DLLs (-dll-N, obviously) -- perhaps multiple, to track different libraries with different evolving API numbers. e.g libintl vs. libasprintf. (b) the package that contains the gettext utility programs (c) the package that contains the import libs, static libs, and header files (d) the package that contains the documentation for the utilities (e) the package that contains the API documentation for the libraries (f) the package that contains the GIANT set of examples I lean towards -bin for (b), -dev for (c), and combining all of (d-f) as -doc. BUT, if the gettext *utilities* are in -bin, then why shouldn't the autoconf *utilities* ALSO be in a -bin package? That's my reasoning for using -bin, in the examples above. The real controversy here is the use of "mingw32" as the subsystem identifier. Technically, these packages are *msys* utilities, because they depend on msys-perl, msys-bash, etc. However, the question is how to distinguish THESE packages from the msysdvlpr ones -- I don't really like "-msys-" vs. "-msysdvlpr-". And besides, these really should reside in /mingw/bin, so that the typical PATH settings which have /mingw/bin precede /usr/bin when !msysdvlpr will enable the typical mingw user to have default access to the "mingw32"-specific autotool utilities, and not "accidentally" get the msys-specific ones. I'm also planning to create these packages using tar's --hard-dereference option, so that hardlinks get turned into copies when the tarball is created. This will enable non-msys-aware unpackers like 7zip or mingw-native-tar to unpack without issue. I'd create new "Packages" (in the SourceForge sense) as follows: MinGW Utilities: autoconf [*] MinGW Utilities: automake MinGW Utilities: libtool MinGW Utilities: gettext [**] [*] This "package" would contain multiple "Releases" (in sourceforge lingo): autoconf-wrapper autoconf2.1 autoconf2.5 where these these "Releases" would contain the obvious files (the '2.5' is not a typo. This represents the 2.5x API of autoconf, which was a significant change from 2.1x, but which has not changed significantly even though we are now at 2.63). Eventually, I could see the autoconf2.5 "release" containing also tarballs/dists derived from upstream autoconf-2.64, -2.65, etc. Ditto the autoconf-wrapper "release" containing tarballs/dists derived from (upstream) -7, -8, etc. [**] I'm not sure whether this is a "utility" or a should be "MinGW Libs: gettext (libintl?)" like "MinGW Libs: libiconv". On the one hand, for development purposes it provides a lot of utility programs like gettext.exe, xgettext.exe, msgcat.exe. On the other hand, it contains the libintl library (among others). At least in this case, tho, I am *sure* it deserves the -mingw32- subsystem moniker -- all the executables and libraries would be native win32 ones, even though (e.g.) the autopoint script is a shell script requiring (msys)bash. The autotools in category #2 would be configured with prefix=/usr, and would be packaged from within /usr so that they, too, look like: bin/autoconf-2.63 bin/autoheader-2.63 Naturally, it is up to the end user (or our installation program) to unpack the "mingw32" version and the "msys" version in the correct, non-conflicting, locations. Those autotools that have compiled components would naturally be compiled using the msysDVLPR gcc-2.95.3 compiler. Proposed package naming convention for these msys/msysdvlpr packages: autoconf-6-1-msys-bin.tar.lzma (wrapper) autoconf-6-1-msys-src.tar.lzma autoconf2.1-2.13-1-msys-bin.tar.lzma autoconf2.1-2.13-1-msys-src.tar.lzma autoconf2.5-2.63-1-msys-bin.tar.lzma autoconf2.5-2.63-1-msys-src.tar.lzma (Or, perhaps the subsystem should be versioned, as in -msys-1.0.12- ?) In a manner similar to the discussion above, I'd create "Packages" (in the SourceForge sense) as follows (note that, at present, the autotools in category #2 are currently distributed as part of the "MSYS System Builder" "Package"). MSysDvlpr Utilities: autoconf MSysDvlpr Utilities: automake MSysDvlpr Utilities: libtool MSysDvlpr Utilities: libiconv [***] MSysDvlpr Utilities: gettext [***] [***] again, "MSysDvlpr Utilities", or "MSys Libs"? Not sure. Naturally, the DLLs themselves would be named 'msys-foo-N.dll' (Aside: I think, eventually, the "MSys Supplementary Tools" package should be retired, and its contents dispersed to multiple separate "MSys Utilities: Foo" or "MSys Libs: Foo" Packages.) Concerning .lzma: IIRC, all of the known mingw setup/installer programs support .lzma (tho some may not yet support .xz). Plus, .lzma does a MUCH better job when a tarball contains multiple copies of the same (large) file than does .gz or .bzip2 -- and this eventuality will be quite common if packages use the --hard-dereference option, as I think they should, for portability. We presently have an lzma utility in msys, and an --lzma-capable tar in msys (1.0.12). We do not YET have a native utility for that, but that is on my list for this round of package updates. (Another aside: I plan to eventually create binary mingw packages for: zlib bzip2 xz libarchive specifically so that we can distribute/have available a statically-linked native win32 bsdtar.exe that supports lzma, gz, and bzip2 without delegating to external decompression, which IIRC GNU tar doesn't do well on native win32. I'm NOT making a win32 native openssl, so this bsdtar won't support the mtree format and its required cryptographic hashes <g>). Now, the autotools are (mostly) just scripts, so "which compiler to use" is not a concern. However, when I get to libtool and gettext (and maybe libiconv, if Keith's current 1.13 is insufficient for some unforeseen reason) "which compiler" WILL be an issue. I'd LIKE to use Aaron's 4.4.0 release -- but (a) I can't find it anywhere, (b) I'm not sure it actually exists anywhere but on Aaron's computer, and (c) rumor has it that "4.4.0 is broken OOTB". I *don't* want to use the 1-year-old "release candidate" 4.3.0. I *don't* want to use the 4-year-old 3.4.5. So, unless there are strong objections, for now I'm planning to use TDM's 4.4.0-dw2 compiler, with plans to rebuild any packages that need it, using Aaron's 4.4.0, once that compiler is actually available in -beta or -rc form. (we're not talking about a lot of non-script packages, here. Just libiconv(?), gettext, and libtool. Plus maybe the four culminating in libarchive/bsdtar, listed above). Comments, Questions? -- Chuck |
From: John E. / T. <td...@td...> - 2009-06-22 00:06:16
|
Charles Wilson wrote: > So, unless there are strong objections, for > now I'm planning to use TDM's 4.4.0-dw2 compiler, with plans to rebuild > any packages that need it, using Aaron's 4.4.0, once that compiler is > actually available in -beta or -rc form. (we're not talking about a lot > of non-script packages, here. Just libiconv(?), gettext, and libtool. > Plus maybe the four culminating in libarchive/bsdtar, listed above). > > Comments, Questions? > I certainly don't object, but would like to mention that there is one bug reported on TDM-GCC 4.4.0 with a chance of affecting these tools' usability. Bug 2803234 [1] reports that a std::ofstream (ergo, this probably only affects C++ programs) cannot seek past 2GB. I haven't had the opportunity to track down the source of this bug yet. If none of the tools you compile are written using C++ iostreams, then this probably wouldn't affect them. Looking forward to using the new packages! -John E. [1] <http://sourceforge.net/tracker/?func=detail&aid=2803234&group_id=200665&atid=974439> |
From: Charles W. <cwi...@us...> - 2009-06-22 01:16:13
|
John E. / TDM wrote: > I certainly don't object, but would like to mention that there is one > bug reported on TDM-GCC 4.4.0 with a chance of affecting these tools' > usability. Bug 2803234 [1] reports that a std::ofstream (ergo, this > probably only affects C++ programs) cannot seek past 2GB. I haven't had > the opportunity to track down the source of this bug yet. > > If none of the tools you compile are written using C++ iostreams, then > this probably wouldn't affect them. The only C++ library in the set is libasprintf, which is part of gettext [*]. However, that library is intended for formatting error messages using std::ostreams, but in a manner that supports easy i18n. That is: cerr << autosprintf ("syntax error in %s:%d: %s", filename, line, errstring) is a lot easier to internationalize than cerr << "syntax error in " << filename << ":" << line << ": " << errstring; because the former lets you rearrange words to follow language-specific grammar rules (especially as libasprintf's autosprintf class supports "positional specifiers" if your C [s]printf routines do). BUT...error messages of this sort really should not be 2GB. I dunno about you, but I won't read them if they're that long. [*] To support Bruno's wild and wacky way of handling DLLs on "woe32", he compiles and links the gettext utility applications using C++ even though the code itself is C. So, it still uses stdout/stderr, not std::cout or std::cerr. So this buglet shouldn't matter here, either. But thanks for the heads up. -- Chuck |
From: Aaron W. L. <aar...@aa...> - 2009-06-22 16:39:45
|
Charles Wilson wrote: > I'd LIKE to use Aaron's 4.4.0 release -- but (a) I can't find it > anywhere, (b) I'm not sure it actually exists anywhere but on Aaron's > computer, and (c) rumor has it that "4.4.0 is broken OOTB". I will be uploading 4.4.0 today, all languages, final release, by around 06:00 UTC. There's a lot of stuff that's broken, but as usual, C language stuff is solid as usual, so regarding what you intend to do, I think this compiler will work for you. There's about a billion minor bugs, which are each individually probably major to someone. This is nothing new to MinGW series compilers. The first thing I'm going to do after posting the announcement is post a call-for-help highlighting the areas in GCC that I think are most in need for attention. There's a lot of talented developers in the MinGW community; maybe just having a TODO list would be enough to get people interested. :) |
From: Chris S. <ir0...@gm...> - 2009-06-22 18:59:59
|
Hey Aaron, > I will be uploading 4.4.0 today, all languages, final release, by around > 06:00 UTC. There's a lot of stuff that's broken, but as usual, C > language stuff is solid as usual, so regarding what you intend to do, I > think this compiler will work for you. That's great news! Just to clarify, in your opinion, is this 4.4.0 build stable enough (given the issues) to become the default compiler, or do we still stick with 3.4.5 (given it's issues) to generate the MinGW packages? Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Aaron W. L. <aar...@aa...> - 2009-06-23 02:39:46
|
Chris Sutcliffe wrote: > Hey Aaron, > >> I will be uploading 4.4.0 today, all languages, final release, by around >> 06:00 UTC. There's a lot of stuff that's broken, but as usual, C >> language stuff is solid as usual, so regarding what you intend to do, I >> think this compiler will work for you. > > That's great news! Just to clarify, in your opinion, is this 4.4.0 > build stable enough (given the issues) to become the default compiler, > or do we still stick with 3.4.5 (given it's issues) to generate the > MinGW packages? Yes, I think it is stable enough for general use. Most languages other than C have a lot of issues. However, for most of them, this is nothing new on MinGW. There are no regressions that I am familiar with that are so serious as to not warrant a final release. As some individuals have pointed out, there's really no way MinGW GCC can proceed without getting a full, non-testing release. As people start using 4.4, we can get a feel for what problems are important, and do what we can with our limited manpower to fix them. As Agner Fog mentioned on the GCC list not too long ago, recent GCC is actually quite good and is very competitive with other i386 compilers. He said, "I think that when gcc gets a reputation as the best compiler, more people will be motivated to update cygwin/mingw." Let's hope he's right. |
From: Charles W. <cwi...@us...> - 2009-06-23 01:06:12
|
Aaron W. LaFramboise wrote: > I will be uploading 4.4.0 today, all languages, final release, by around > 06:00 UTC. There's a lot of stuff that's broken, but as usual, C > language stuff is solid as usual, so regarding what you intend to do, I > think this compiler will work for you. Outstanding. I wasn't really trying to give you a poke; I've been following the binutils/gcc lists and see that there are/have been issues. -- Chuck |
From: Keith M. <kei...@us...> - 2009-06-22 19:54:18
|
On Sunday 21 June 2009 23:38:19 Charles Wilson wrote: > I propose that the autotools > in category #1 follow this naming convention: > > autoconf-6-1-mingw32-bin.tar.lzma (wrapper) > autoconf-6-1-mingw32-src.tar.lzma > autoconf2.1-2.13-4-mingw32-bin.tar.lzma > autoconf2.1-2.13-4-mingw32-src.tar.lzma > autoconf2.5-2.63-1-mingw32-bin.tar.lzma > autoconf2.5-2.63-1-mingw32-src.tar.lzma > > These would be configured with prefix=/mingw, and would be > packaged from within /mingw so that they contain: > > bin/autoconf-2.63 > bin/autoheader-2.63 > ... > etc. Looks good to me. > I'm also open to (a) possibly splitting the documentation out into > a -doc pkg for each, Makes sense, if it's easily separated out. > and/or (b) using -dev in preference to -bin > for the package that contains the actual scripts. I'd be inclined to stick with -bin; -dev really implies header files, libraries, (and maybe associated docs, if not separated). Autoconf doesn't provide such components, so a -dev package here would seem to be an anomaly. > The real controversy here is the use of "mingw32" as the subsystem > identifier. Technically, these packages are *msys* utilities, > because they depend on msys-perl, msys-bash, etc. Yes, and to classify them as such really does seem more natural, than to suggest that they may be MinGW utilities, which most would expect to be able to run independently of MSYS. > However, the > question is how to distinguish THESE packages from the msysdvlpr > ones -- I don't really like "-msys-" vs. "-msysdvlpr-". I take your point, but I am concerned that autoconf-*-mingw32 may lead to end user confusion, and an expectation that these should run without MSYS, where in fact this isn't the case. If -MSYS- alone is to serve for tools used in MSYS with the MINGW32 host personality -- as is the case for the majority of other packages -- then we really do need a distinct identifier for MSYSDVLPR. Whether that ends up as -MSYSDVLPR-, -MSYS-DVLPR-, -MSYS-SDK- or some other moniker -- I'm open to suggestions -- it really *shouldn't* be just -MSYS-. > And > besides, these really should reside in /mingw/bin, so that the > typical PATH settings which have /mingw/bin precede /usr/bin when > !msysdvlpr will enable the typical mingw user to have default > access to the "mingw32"-specific autotool utilities, and not > "accidentally" get the msys-specific ones. Agreed. However, I've never really understood why the one set of autotools can't suffice for both purposes, (with the exception of libtool perhaps, and gettext which I don't view as a natural component of the autotools in any case). > (Another aside: I plan to eventually create binary mingw packages > for: > zlib > bzip2 > xz I was planning to do these myself; (already have them built, and just the split, packaging and distribution to complete). Do you want to take them over, or shall I continue with them? > libarchive However, I ran into a brick wall with this -- and please *don't* tell me I need to kludge it, by using CMake to generate a build system. If I can't build it with a simple ../path/to/configure --build=i686-pc-linux --host=mingw32 ... I consider it to be broken. (FTR, libarchive-2.7.0 appears to configure fine, but the source then fails to compile correctly; it breaks at the outset, in libarchive/archive-entry.c, which is the very first file in the compilation sequence)[*]. > specifically so that we can distribute/have available a > statically-linked native win32 bsdtar.exe that supports lzma, gz, > and bzip2 without delegating to external decompression, Yep. That was my motivation for playing with zlib, libbz2, liblzma and libarchive, but I wasn't aiming for a standalone bsdtar -- I'd like to integrate the unpacking function directly into mingw-get. I started out with the groundwork John E. has already put in place, (but eschewing his decomposition of the prerequisite libraries in favour of linking against the full library code from upstream). I had no difficulty in getting the decompression filters working -- gzip from libz, bzip2 from libbz2, lzma and xz from liblzma. Rather than hack around the issues with libarchive, I took Tim Kientzle's untar.c, and adapted it. > which IIRC GNU tar doesn't do well on native win32. Maybe. I don't know. I've never attempted to build GNU tar for native w32. My understanding is that bsdtar is better in any case, and I was disappointed that libarchive failed to build. > I'm NOT making a win32 > native openssl, so this bsdtar won't support the mtree format and > its required cryptographic hashes <g>). No problem with that; I don't think we need anything beyond ustar format archives. [*] Yes, I am aware that there are known issues with 2.7.0 and MinGW; the issues I saw -- very quickly -- didn't seem to be related to the issues I saw reported on the libarchive wiki. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-06-23 02:51:29
|
Keith Marshall wrote: > On Sunday 21 June 2009 23:38:19 Charles Wilson wrote: >> I propose that the autotools >> in category #1 follow this naming convention: >> >> autoconf-6-1-mingw32-bin.tar.lzma (wrapper) > Looks good to me. Except that this contradicts your comments below, concerning -mingw- vs. -msys- vs. -msysDVLPR- >> I'm also open to (a) possibly splitting the documentation out into >> a -doc pkg for each, > > Makes sense, if it's easily separated out. Easy peasy. >> and/or (b) using -dev in preference to -bin >> for the package that contains the actual scripts. > > I'd be inclined to stick with -bin; -dev really implies header files, > libraries, (and maybe associated docs, if not separated). Autoconf > doesn't provide such components, so a -dev package here would seem > to be an anomaly. That was my thought as well. >> The real controversy here is the use of "mingw32" as the subsystem >> identifier. Technically, these packages are *msys* utilities, >> because they depend on msys-perl, msys-bash, etc. > > Yes, and to classify them as such really does seem more natural, than > to suggest that they may be MinGW utilities, which most would expect > to be able to run independently of MSYS. > >> However, the >> question is how to distinguish THESE packages from the msysdvlpr >> ones -- I don't really like "-msys-" vs. "-msysdvlpr-". > > I take your point, but I am concerned that autoconf-*-mingw32 may > lead to end user confusion, and an expectation that these should run > without MSYS, where in fact this isn't the case. If -MSYS- alone is > to serve for tools used in MSYS with the MINGW32 host personality -- > as is the case for the majority of other packages -- then we really > do need a distinct identifier for MSYSDVLPR. Whether that ends up > as -MSYSDVLPR-, -MSYS-DVLPR-, -MSYS-SDK- or some other moniker -- > I'm open to suggestions -- it really *shouldn't* be just -MSYS-. So here's the real kicker: libtool. From your reasoning, then, we should have: libtool-2.2.7a-1-mingw32-dll-7.tar.lzma (contains a mingw DLL) libtool-2.2.7a-1-msys-bin.tar.lzma (contains an (msys)bash script) libtool-2.2.7a-1-???-doc.tar.lzma (ok, now I'm confused) libtool-2.2.7a-1-???-src.tar.lzma (and this makes my head hurt) I'd guess there would be a lot of packages like that. Take your/my native build of bzip2. The .exe's, dll's, and libs are all -mingw-. BUT, bzip2 also provides bzcmp bzdiff bzegrep bzfgrep bzgrep bzless bzmore which are all (msys)sh scripts. So, my -bin package which contains these scripts, plus the perfectly usable native bzip2.exe, is what? bzip2-1.0.5-1-mingw32-bin.tar.lzma bzip2-1.0.5-1-msys-bin.tar.lzma I think we're going to have to accept the following: 1) sometimes there is no "correct" choice -- all choices are to some degree wrong. 2) we should err on the side of least surprise (or, when all choices are to some extent surprising, fall back to the hobgoblin of little minds like my own: consistency) So, for my bzip2 example, I'd definitely call it -mingw32-, and perhaps add a blurb to the ReleaseNotes that "executables and libraries provided by this package are native win32, but some of the scripts provided require msys to operate correctly" and let it go. For libtool...what's more important: libltdl-7.dll is mingw32, or libtool requires (a lot) of msys support? I could go either way...punt to "whatever we decide for the rest of the autotools". Principle of least surprise: all the autotool packages for MSYS-as-MinGW-personal should at least use the SAME subsys id. Concerning gettext, I do consider to be an autotool because of autopoint. libintl-2.dll is mingw. All the .exe utilities are mingw. But autopoint is an (msys)sh script, and requires (msys)cvs. MOST of gettext is mingw32. Similarly, (the native build of) gettext's apps and dll's depend on (the native build of) libiconv -- which as currently distributed contains nothing which relies on msys. So certainly libiconv should be -mingw32- (-msys- would be just silly, AND misleading). But, back to "use the SAME subsys id" -- by my argument, libiconv and gettext should be -mingw32-. BUT gettext::autopoint requires msys support programs. Now, that just knocks the legs out of the argument that the libtool "script" forces all of the libtool packages to use the -msys- subsys id. A tie (libtool-bin vs. libtool-dll) goes to the runner (gettext & libiconv use -mingw32-, and gettext-bin contains autopoint, just like libtool-bin contains libtool proper). Which finally brings us back to automake/autoconf. Well, if libtool/gettext/libiconv all claim -mingw32-, these boys should too. >> And >> besides, these really should reside in /mingw/bin, so that the >> typical PATH settings which have /mingw/bin precede /usr/bin when >> !msysdvlpr will enable the typical mingw user to have default >> access to the "mingw32"-specific autotool utilities, and not >> "accidentally" get the msys-specific ones. > > Agreed. However, I've never really understood why the one set of > autotools can't suffice for both purposes, (with the exception of > libtool perhaps, and gettext which I don't view as a natural > component of the autotools in any case). While autoconf and automake are platform-agnostic [*], libtool is not, as you point out. But it's worse: the autotools expect to work together, in that aclocal creates aclocal.m4 using m4 fragments from 1) local m4/ dir 2) $prefix/share/aclocal 3) $prefix/ahare/aclocal-X.Y 4) wherever $prefix/share/aclocal/.dirlist says AND the aclocal.m4 it creates is supposed to work with the autoconf/automake you use. Ditto libtoolize is going to copy ITS $ltprefix/share/aclocal/libtool.m4 & friends into the local m4/ dir for aclocal to use -- and that better match the ltmain.sh you have, as well. [*] contrary to early reports from long ago, autoconf and automake should NOT be configured with the typical mingw '--prefix=`cd /mingw && pwd -W`'. This is because they are entirely comprised of perl and shell scripts, and in our environment rely on (msys)perl and (msys)bash. Thus, throwing C:\Dos\Style\Path\With Spaces\ at them just doesn't work. They actually want --prefix=/mingw (or $unix_prefix_of_your_choice). Then, consider all the libraries that stick their .m4 files (esp. gettext! Wow, it supplies almost as many .m4 files as automake itself) Now, suppose I have only ONE common installation of autoconf and automake, to be used by both msysdvlpr and msys-as-mingw environments. Suppose this is the "msys" build of those tools, and thus was configured with --prefix=/usr NOT --prefix=/mingw. There is only one search path for .m4 files -- /usr/share/aclocal/ and friends. Well, I've got a native build of libxml configured and installed, like a good little mingw user, in /mingw. I'm developing a package that uses that library, and I want to reference libxml.m4 from my package's configure.ac. /usr/bin/aclocal will look in /usr/share/aclocal/ and friends, and will NOT find libxml.m4 unless a) I explicitly use 'aclocal -I /mingw/share/aclocal' b) I add ACLOCAL_FLAGS = -I /mingw/share/aclocal to my project's Makefile.am. That's not very cross-platform... c) I add /mingw/share/aclocal to /usr/share/aclocal/.dirlist However, this has other problems, in that it breaks the msysdvlpr usage...there's now an .m4 file in aclocal's search path associated with a library for which I don't have an msys build (so what? you say. Well, you're right: this isn't REALLY a problem. It's not presence/vs/absence that is the real trouble. It's version mismatch. See below) None of these choices seem good to me. It oughta Just Work without extra effort on the developer's part -- or platform specific ACLOCAL_FLAGS settings in a supposedly cross-platform Makefile.am. So here's the REAL problem with c): different VERSIONS of an .m4 file. We *will* have multiple versions -- native and msys -- of libiconv and libintl/gettext. Each provides lots of .m4 files. These .m4 files are not always intercompatible across versions. So, to allow a single autoconf installation, I/We have to ensure that libiconv-win32 and libiconv-msys are always kept in sync, so that the .m4 files stay compatible. Ditto libintl-win32 and libintl-msys. AND we have to ensure that all USERS always upgrade both simultaneously if they have them installed at all. IMO it's easier to simply have a separate entire autotoolchain for msys, and a separate entire autotoolchain for native. What 'subsys id' we give em', I dunno. See above. Plus, this actually simplifies things a bit. I can distribute just One True Autoconf Version and One True Automake Version for msysdvlpr (plus, recall that the msys versions are patched to support the -msys- $host triple, which Earnie explicitly does NOT want leaking outside of the msysdvlpr environment). The mingw autotoolchains can be all tricked out with multiple versions and wrapper scripts and whatnot -- and I don't have to worry if all that junk actually WORKS in the msysdvlpr environment. I just have to ensure that the One True Version works in msysdvlpr. >> (Another aside: I plan to eventually create binary mingw packages >> for: >> zlib >> bzip2 >> xz > > I was planning to do these myself; (already have them built, and just > the split, packaging and distribution to complete). Do you want to > take them over, or shall I continue with them? It's probably better if I take over xz just for synergy. I'm already bouncing patches back and forth with Lasse Collin concerning the build issues. I also maintain the cygwin builds of zlib, mingw-zlib [*], bzip2, and mingw-bzip2 [*], so I could do those two as well, but in the interests of preserving my sanity, how about you go ahead with zlib and bzip2? [*] these are actually mingw-native builds, but are built using cygwin gcc -mno-cygwin, are intended SOLELY to support developers of setup.exe, and whose DLL names are munged to avoid conflict with anything the MinGW project might ever distribute. There will soon also be a cygwin mingw-xz package... >> libarchive > > However, I ran into a brick wall with this -- and please *don't* tell > me I need to kludge it, by using CMake to generate a build system. > If I can't build it with a simple > > ../path/to/configure --build=i686-pc-linux --host=mingw32 ... > > I consider it to be broken. I agree. I'm actually one of the project members for libarchive. I've helped to get it building on cygwin (configure/make) but haven't had a chance to do the same for mingw. That's already on my list... > (FTR, libarchive-2.7.0 appears to > configure fine, but the source then fails to compile correctly; it > breaks at the outset, in libarchive/archive-entry.c, which is the > very first file in the compilation sequence)[*]. Cute. That always gives me warm fuzzies. >> specifically so that we can distribute/have available a >> statically-linked native win32 bsdtar.exe that supports lzma, gz, >> and bzip2 without delegating to external decompression, > > Yep. That was my motivation for playing with zlib, libbz2, liblzma > and libarchive, but I wasn't aiming for a standalone bsdtar -- I'd > like to integrate the unpacking function directly into mingw-get. Well, once the libraries are available, all sorts of things become possible. > I started out with the groundwork John E. has already put in place, > (but eschewing his decomposition of the prerequisite libraries in > favour of linking against the full library code from upstream). That's my preferred approach, too. > I > had no difficulty in getting the decompression filters working -- > gzip from libz, bzip2 from libbz2, lzma and xz from liblzma. Rather > than hack around the issues with libarchive, I took Tim Kientzle's > untar.c, and adapted it. That'll work. >> which IIRC GNU tar doesn't do well on native win32. > > Maybe. I don't know. I've never attempted to build GNU tar for > native w32. My understanding is that bsdtar is better in any case, > and I was disappointed that libarchive failed to build. GNU tar tries to fork/exec external decompression programs except for compress, gz, and bz2. Without lots of TLC (or gnulib code) this doesn't work on native win32 the way GNU tar expects it to. > [*] Yes, I am aware that there are known issues with 2.7.0 and MinGW; > the issues I saw -- very quickly -- didn't seem to be related to the > issues I saw reported on the libarchive wiki. Well, it oughta work. And it WILL work. Just as soon as I can get to it. <g> -- Chuck |
From: Keith M. <kei...@us...> - 2009-07-06 16:52:50
|
On Tuesday 23 June 2009 01:25:19 Charles Wilson wrote: > I'm actually one of the project members for libarchive. Yes, I'd noticed that, posted on their web site. > > I had no difficulty in getting the decompression filters working > > -- gzip from libz, bzip2 from libbz2, lzma and xz from liblzma. > > Rather than hack around the issues with libarchive, I took Tim > > Kientzle's untar.c, and adapted it. > > That'll work. Yes. It may even be preferable for mingw-get's needs; for example tracking of installed files can be hooked right into the extraction function; links could be resolved as copies, etc. (although it may be useful to teach libarchive to do that automatically, on w32, if it doesn't already do so -- I didn't look that closely). -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2009-07-06 16:52:58
|
On Tuesday 23 June 2009 01:25:19 Charles Wilson wrote: > >> zlib > >> bzip2 > >> xz > > > > I was planning to do these myself; (already have them built, and > > just the split, packaging and distribution to complete). Do you > > want to take them over, or shall I continue with them? > > It's probably better if I take over xz just for synergy. I'm > already bouncing patches back and forth with Lasse Collin > concerning the build issues. One of them, perhaps, being: .../mingw32/bin/as: BFD (GNU Binutils) 2.19.1 assertion fail .../bfd/coff-i386.c:583 .../src/liblzma/check/crc32_x86.S: Assembler messages: .../src/liblzma/check/crc32_x86.S:117: Error: cannot represent relocation type BFD_RELOC_386_GOTPC make[4]: *** [libcheck_la-crc32_x86.lo] Error 1 make[4]: Leaving directory `/home/keith/sandbox/xz-4.999.8beta/mingw32/src/liblzma/check' This is xz-4.999.8beta configured with --disable-nls --disable-rpath (in addition to --build=i686-pc-linux --host=mingw32); if I also add --disable-shared, I can successfully build and deploy as a completely static library. > I also maintain the cygwin builds of zlib, mingw-zlib [*], bzip2, > and mingw-bzip2 [*], so I could do those two as well, but in the > interests of preserving my sanity, how about you go ahead with > zlib and bzip2? Ok, I'll go ahead with that. FWIW, I have bzip2 ready to deploy; (I autoconfiscated it, to make cross-compilation easier -- <sigh> why do some developers assume that their package needs are too modest to justify using autoconf? Hand crafted configure scripts, or no configure scripts at all, are a total pain for those of us who have build requirements differing from those of the original developer). I'm in two minds, whether or not to repeat the exercise for zlib; the proliferation of make variables which need manual reassignment to achieve a successful cross-build are, again, a total pain with their non-standard, hand-crafted configure script. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2009-07-06 16:53:07
|
On Tuesday 23 June 2009 01:25:19 Charles Wilson wrote: >>> autoconf-6-1-mingw32-bin.tar.lzma (wrapper) >> >> Looks good to me. > > Except that this contradicts your comments below, concerning > -mingw- vs. -msys- vs. -msysDVLPR- Maybe I was being too economical with my words; I meant "looks good, but with reservations", (but I guess you realised that). -- Regards, Keith. |
From: Cesar S. <ces...@gm...> - 2009-06-23 12:03:24
|
On Sun, Jun 21, 2009 at 7:38 PM, Charles Wilson < cwi...@us...> wrote: > I'm gearing up to refresh some of the packages I've created in the past > for mingw and msys, especially the autotools. > > Thanks! > Now, the autotools come in two different flavors: > 1) intended for use within an MSys environment for > maintaining/building "native" mingw packages, and > 2) intended for use within an MSysDvlpr environment for > maintaining/building other MSYS packages. > > Based on previous discussions on this list, I propose that the autotools > in category #1 follow this naming convention: > > autoconf-6-1-mingw32-bin.tar.lzma (wrapper) > autoconf-6-1-mingw32-src.tar.lzma > autoconf2.1-2.13-4-mingw32-bin.tar.lzma > autoconf2.1-2.13-4-mingw32-src.tar.lzma > autoconf2.5-2.63-1-mingw32-bin.tar.lzma > autoconf2.5-2.63-1-mingw32-src.tar.lzma > > These would be configured with prefix=/mingw, and would be packaged from > within /mingw so that they contain: > > bin/autoconf-2.63 > bin/autoheader-2.63 > ... > etc. > > Seems reasonable. > I'm also open to (a) possibly splitting the documentation out into a > -doc pkg for each, Seems a good idea. > and/or (b) using -dev in preference to -bin for the > package that contains the actual scripts. I would prefer to reserve -dev to packages providing headers files and libraries. I would include scripts only if they are used to get the build flags (e.g. "foo-config"). > However, this becomes tricky > with regards to gettext. There's > (a) the package that contains the DLLs (-dll-N, obviously) > -- perhaps multiple, to track different libraries with different > evolving API numbers. e.g libintl vs. libasprintf. > (b) the package that contains the gettext utility programs > (c) the package that contains the import libs, static libs, and header > files > (d) the package that contains the documentation for the utilities > (e) the package that contains the API documentation for the libraries > (f) the package that contains the GIANT set of examples > I lean towards -bin for (b), -dev for (c), and combining all of (d-f) as > -doc. Seems right. > BUT, if the gettext *utilities* are in -bin, then why shouldn't > the autoconf *utilities* ALSO be in a -bin package? That's my reasoning > for using -bin, in the examples above. > Agreed. Regards Cesar |
From: Cesar S. <ces...@gm...> - 2009-06-23 15:17:31
|
Charles Wilson wrote: The real controversy here is the use of "mingw32" as the subsystem > identifier. Technically, these packages are *msys* utilities, because > they depend on msys-perl, msys-bash, etc. However, the question is how > to distinguish THESE packages from the msysdvlpr ones -- I don't really > like "-msys-" vs. "-msysdvlpr-". And besides, these really should > reside in /mingw/bin, so that the typical PATH settings which have > /mingw/bin precede /usr/bin when !msysdvlpr will enable the typical > mingw user to have default access to the "mingw32"-specific autotool > utilities, and not "accidentally" get the msys-specific ones. > > I would use the subsystem name to indicate under which root the file should be unpacked: *-mingw32-* should be unpacked in /mingw *-msys-* should be unpacked in /usr Regards, Cesar |
From: Cesar S. <ces...@gm...> - 2009-06-23 17:36:33
|
Terribly sorry for the MIME/HTML encoded email. I will use Gmail in IMAP/SMTP mode from now on. Resent in text mode. Charles Wilson wrote: > I'm gearing up to refresh some of the packages I've created in the past > for mingw and msys, especially the autotools. Thanks! > Now, the autotools come in two different flavors: > 1) intended for use within an MSys environment for > maintaining/building "native" mingw packages, and > 2) intended for use within an MSysDvlpr environment for > maintaining/building other MSYS packages. > > Based on previous discussions on this list, I propose that the autotools > in category #1 follow this naming convention: > > autoconf-6-1-mingw32-bin.tar.lzma (wrapper) > autoconf-6-1-mingw32-src.tar.lzma > autoconf2.1-2.13-4-mingw32-bin.tar.lzma > autoconf2.1-2.13-4-mingw32-src.tar.lzma > autoconf2.5-2.63-1-mingw32-bin.tar.lzma > autoconf2.5-2.63-1-mingw32-src.tar.lzma > > These would be configured with prefix=/mingw, and would be packaged from > within /mingw so that they contain: > > bin/autoconf-2.63 > bin/autoheader-2.63 > ... > etc. > Seems reasonable. > I'm also open to (a) possibly splitting the documentation out into a > -doc pkg for each, Seems a good idea. > and/or (b) using -dev in preference to -bin for the > package that contains the actual scripts. I would prefer to reserve -dev to packages providing headers files and libraries. I would include scripts only if they are used to get the build flags (e.g. "foo-config"). > However, this becomes tricky > with regards to gettext. There's > (a) the package that contains the DLLs (-dll-N, obviously) > -- perhaps multiple, to track different libraries with different > evolving API numbers. e.g libintl vs. libasprintf. > (b) the package that contains the gettext utility programs > (c) the package that contains the import libs, static libs, and header > files > (d) the package that contains the documentation for the utilities > (e) the package that contains the API documentation for the libraries > (f) the package that contains the GIANT set of examples > I lean towards -bin for (b), -dev for (c), and combining all of (d-f) as > -doc. Seems right. > BUT, if the gettext *utilities* are in -bin, then why shouldn't > the autoconf *utilities* ALSO be in a -bin package? That's my reasoning > for using -bin, in the examples above. > Agreed. > > The real controversy here is the use of "mingw32" as the subsystem > identifier. Technically, these packages are *msys* utilities, because > they depend on msys-perl, msys-bash, etc. However, the question is how > to distinguish THESE packages from the msysdvlpr ones -- I don't really > like "-msys-" vs. "-msysdvlpr-". And besides, these really should > reside in /mingw/bin, so that the typical PATH settings which have > /mingw/bin precede /usr/bin when !msysdvlpr will enable the typical > mingw user to have default access to the "mingw32"-specific autotool > utilities, and not "accidentally" get the msys-specific ones. I would use the subsystem name to indicate under which root the file should be unpacked: *-mingw32-* should be unpacked in /mingw *-msys-* should be unpacked in /usr So, one would be able to know where to unpack the files just by looking at the file name. Regards, Cesar |
From: Charles W. <cwi...@us...> - 2009-06-23 23:15:55
|
Cesar Strauss wrote: > Charles Wilson wrote: >> The real controversy here is the use of "mingw32" as the subsystem >> identifier. Technically, these packages are *msys* utilities, because >> they depend on msys-perl, msys-bash, etc. However, the question is how >> to distinguish THESE packages from the msysdvlpr ones -- I don't really >> like "-msys-" vs. "-msysdvlpr-". And besides, these really should >> reside in /mingw/bin, so that the typical PATH settings which have >> /mingw/bin precede /usr/bin when !msysdvlpr will enable the typical >> mingw user to have default access to the "mingw32"-specific autotool >> utilities, and not "accidentally" get the msys-specific ones. > > I would use the subsystem name to indicate under which root the file > should be unpacked: > > *-mingw32-* should be unpacked in /mingw > *-msys-* should be unpacked in /usr Hmmm...I like it (especially as it ratifies my original proposal). But let's expand: The subsys indicates the standard installation prefix for which the package was configured. Thus, packages named *-mingw32-* were configured using --prefix=/mingw (or, in many cases, --prefix=`cd /mingw && pwd -W`. This formulation should always resolve to C:\MinGW for official MinGW packages). Thus, the subsys indicates the expected directory in which the package should be installed: C:\MinGW In almost all cases, these package contain native win32 executables and libraries, and are usable without an msys installation. In some few cases, the packages may also include *scripts* written in shell or perl. In those cases, the scripts may not operate correctly unless an msys installation also exists. One notable group of packages that contain such scripts are the family of autotool packages with the -mingw32- subsys id. *-msys-* were configured using --prefix=/usr. It is expected that these packages will be unpacked in /usr == / directory. That is, these packages should be unpacked into the versioned root directory for msys. Typically, this is C:\msys\1.0 These packages will never have been configured using the --prefix=`cd foo && pwd -W` formulation. > So, one would be able to know where to unpack the files just by looking > at the file name. Right. --chuck |
From: Earnie B. <ea...@us...> - 2009-06-26 17:43:29
|
Quoting Charles Wilson <cwi...@us...>: > > *-mingw32-* were configured using --prefix=/mingw (or, in many > cases, --prefix=`cd /mingw && pwd -W`. This formulation > should always resolve to C:\MinGW for official MinGW > packages). Thus, the subsys indicates the expected > directory in which the package should be installed: > C:\MinGW I agree. > *-msys-* were configured using --prefix=/usr. It is expected that > these packages will be unpacked in /usr == / directory. > That is, these packages should be unpacked into the > versioned root directory for msys. Typically, this is > C:\msys\1.0 > These packages will never have been configured using the > --prefix=`cd foo && pwd -W` formulation. > I agree. >> So, one would be able to know where to unpack the files just by looking >> at the file name. > > Right. > Except that it shouldn't matter if they are unpacked in /usr or /mingw for 1.0.11 other than for msysDVLPR which I put in /msys. I put all other packages in /usr regardless of if it requires the MSYS dll or not. I understand the support model being represented with what is proposed so I'm just throwing a wrench in the wheel. -- Earnie |
From: Charles W. <cwi...@us...> - 2009-06-26 20:47:54
|
On Fri, 26 Jun 2009 17:42 +0000, "Earnie Boyd" wrote: > Quoting Charles Wilson: > >> So, one would be able to know where to unpack the files just by looking > >> at the file name. > > > > Right. > > > > Except that it shouldn't matter if they are unpacked in /usr or /mingw > for 1.0.11 other than for msysDVLPR which I put in /msys. I put all > other packages in /usr regardless of if it requires the MSYS dll or > not. I understand the support model being represented with what is > proposed so I'm just throwing a wrench in the wheel. I'll take your agreement, and move forward. But...your wrench is begging for comment: We're not talking about whether msys DLL is happy about "native" binaries and "msys" binaries coexisting in the same directory, or segregated to only-msys and only-mingw directories, or even scattered/intermingled willy-nilly in a bunch of different directories. The issue here is for those tools -- be they scripts, binaries, or utility libraries -- that hardcode their own compilation prefix location (or some relative path derived from it). That is, the aclocal script has a hardcoded reference to ${prefix}/share/aclocal. autopoint has hardcoded references. All binaries that use libintl have hardcoded references to the message catalog location. Some tools take special care to handle such relocation problems; as it happens, gettext/libintl and libiconv DO, if they are compiled with --enable-relocatable (and it hasn't bitrotted on win32 since the last time I looked at it). But not every package is so thoughtful. Now, IIRC Tor Lillqvist has said "any binary package on win32 that doesn't handle installation into a different directory is broken". That's a bit harsh IMO -- and I'd rather not wait three years for "perfect", when I can supply "pretty d@mn good" today (or relatively soon), provided we reach a consensus on these policy issues. MSYS's 1.0.12 improvements with respect to "mixing native and msys binaries in /bin" have very little to do with this issue. Now, if an end-user wants to compile, say, "gettext" for mingw and install it and all its tools into [/usr]/ -- bully for them. It'll work ok (as long as they never try to use the *stock* msysDVLPR tools which -- according to policy -- will be installed to [/usr]/). If she wants to recompile ALL "official" mingw binary packages with --prefix=`cd / && pwd -W` -- fine and dandy [*]. As you say, the MSYS dll no longer cares. But we will be shipping multiple versions of some small set of tools: libiconv (mingw, msys), gettext (ditto), auto*. They can't ALL go into "/" -- we'd be silly to deliberate ship packages that, having the same prefix, can't be installed simultaneously (e.g. msys-libiconv and mingw-libiconv). So, for *official* packages...we need *policy*. [*] probably. Unless the "mingw" package she's compiling clashes with an already-provided msys one. Say, cvs for instance. Then, she's going to clobber her msys version with the new mingw one...which is fine, as long as she knows that. She gets to keep all the pieces. -- Chuck |
From: Keith M. <kei...@us...> - 2009-06-27 18:33:14
|
On Friday 26 June 2009 18:42:28 Earnie Boyd wrote: > > *-mingw32-* were configured using --prefix=/mingw (or, in many > > cases, --prefix=`cd /mingw && pwd -W`. This > > formulation should always resolve to C:\MinGW for official MinGW > > packages). Thus, the subsys indicates the expected directory in > > which the package should be installed: C:\MinGW > > I agree. Sorry; while I see the logic behind this suggestion, I respectfully *disagree*. I consider it utterly arcane that a package such as autoconf, which is 100% dependent on MSYS to do anything even remotely useful, should be touted as a MinGW package. There are many users, who do not use MSYS, (and who may not wish to use it), and who will expect any package branded as *-mingw32-* to offer at least a *primary* deliverable which does *not* require MSYS; autoconf and friends can never meet this criterion. While we offer packages intended for *three* distinct "user lands", I don't see how we can expect to achieve the mathematically impossible feat of describing them with only two unique identifiers; we *need* an additional unique subsystem identifier, for those packages which are specifically intended for exclusive use in "MSYS Developer land"; IMO, *-msys-* cannot suffice for that. On Friday 26 June 2009 21:47:50 Charles Wilson wrote: > So, for *official* packages...we need *policy*. Yes, we need policy, but it needs to be *rational* policy; I don't think we are yet at a point of consensus, where we can formulate any such policy. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-06-27 21:24:38
|
Keith Marshall wrote: > On Friday 26 June 2009 18:42:28 Earnie Boyd wrote: >>> *-mingw32-* were configured using --prefix=/mingw (or, in many >>> cases, --prefix=`cd /mingw && pwd -W`. This >>> formulation should always resolve to C:\MinGW for official MinGW >>> packages). Thus, the subsys indicates the expected directory in >>> which the package should be installed: C:\MinGW >> I agree. > > Sorry; while I see the logic behind this suggestion, I respectfully > *disagree*. I knew that you would. This is where we ended over a year ago, when a similar discussion died without resolution. > I consider it utterly arcane that a package such as > autoconf, which is 100% dependent on MSYS to do anything even > remotely useful, should be touted as a MinGW package. There are > many users, who do not use MSYS, (and who may not wish to use it), > and who will expect any package branded as *-mingw32-* to offer at > least a *primary* deliverable which does *not* require MSYS; > autoconf and friends can never meet this criterion. Are you arguing that the autotool family, intended to support a single development flow, should have DIFFERENT subsys id's? For development of For development of msys mingw/native apps/libs apps and libs ======================= ============================= autoconf-msys autoconf-msysdvlpr automake-msys automake-msysdvlpr libiconv-mingw libiconv-msys gettext- ? [*] gettext-msys (unless clashes with whatever resolution goes at left <<) libtool- ? [**] libtool-msys (unless clashes...) The left column, whatever the subsys id, are all installed into one prefix (most likely /mingw === C:/MinGW). The right column are all installed into a different prefix, most likely / == /usr. Regardless of how [*] and [**] are resolved, I consider the above "design"...less than sound. [*] contains libraries and binary utilities that are perfectly happy native mingw applications. However, the autopoint and gettextize tools themselves (aside from xgettext, THE reason gettext is considered an autotool at all, given when and how it is supposed to be used) are (msys)shell scripts that invokes/relies on (msys)cvs. So, are the gettext subpackages -msys- for that reason? Or -mingw- because the libraries/exes are native? Or split into pieces where some are one, and some are the other, yet all derive from the same -src- which is...non-subsys-id marked? Insanity... [**] Similarly here. libtool and libtoolize are shell scripts, and a lot of the functionality is provided by m4 files which rely on a working (msys) m4.exe. But the binary library is native, as it must be if you're going to build native apps using the ltdl functionality. Again, -msys-, -mingw-, or an insane mixture of both? As I said initially, there is NO single answer that makes perfect sense in all cases. A slightly less insane scheme than the one above is For development of For development of msys mingw/native apps/libs apps and libs ======================= ============================= autoconf-msys autoconf-msysdvlpr automake-msys automake-msysdvlpr libiconv-msys libiconv-msysdvlpr gettext-msys gettext-msysdvlpr libtool-msys libtool-msysdvlpr But that's no more rational than my original scheme (-mingw on the left, -msys on the right) because libiconv-"msys", gettext-"msys", and libtool-"msys" all contain pieces that are native win32 binaries, useful by themselves without any MSYS installation at all. > While we offer packages intended for *three* distinct "user lands", I > don't see how we can expect to achieve the mathematically impossible > feat of describing them with only two unique identifiers; we *need* > an additional unique subsystem identifier, for those packages which > are specifically intended for exclusive use in "MSYS Developer > land"; IMO, *-msys-* cannot suffice for that. > > On Friday 26 June 2009 21:47:50 Charles Wilson wrote: >> So, for *official* packages...we need *policy*. > > Yes, we need policy, but it needs to be *rational* policy; I don't > think we are yet at a point of consensus, where we can formulate any > such policy. Right. So propose something SPECIFIC rather than general accusations of irrationality. Break it down. I've listed all of the proposed packages in each work flow, sans subsystem id. Please go thru all 72 packages and tell me what subsystem id you think each should have. If you make different choices for packages which fall under the same workflow, explain why that will not confuse our users trying to figure out just what in the H*** they are supposed to download. If you DO choose the same subsys id for all packages under the same workflow, it will be ipso facto wrong for some of those packages. Explain why your choice, with its inherent wrongness for certain packages, is better than any other (uniform) choice, with ITS inherent wrongness. targetting mingw development ============================ autoconf-6-1-*-bin.tar.lzma (wrapper) autoconf-6-1-*-src.tar.lzma autoconf2.1-2.13-4-*-bin.tar.lzma autoconf2.1-2.13-4-*-doc.tar.lzma autoconf2.1-2.13-4-*-src.tar.lzma autoconf2.5-2.63-1-*-bin.tar.lzma autoconf2.5-2.63-1-*-doc.tar.lzma autoconf2.5-2.63-1-*-src.tar.lzma automake-4-1-*-bin.tar.lzma (wrapper) automake-4-1-*-src.tar.lzma automake1.4-1.4p6-1-*-bin.tar.lzma automake1.4-1.4p6-1-*-doc.tar.lzma automake1.4-1.4p6-1-*-src.tar.lzma automake1.5-1.5-1-*-bin.tar.lzma automake1.5-1.5-1-*-doc.tar.lzma automake1.5-1.5-1-*-src.tar.lzma automake1.6-1.6.3-1-*-bin.tar.lzma automake1.6-1.6.3-1-*-doc.tar.lzma automake1.6-1.6.3-1-*-src.tar.lzma automake1.7-1.7.9-1-*-bin.tar.lzma automake1.7-1.7.9-1-*-doc.tar.lzma automake1.7-1.7.9-1-*-src.tar.lzma automake1.8-1.8.5-1-*-bin.tar.lzma automake1.8-1.8.5-1-*-doc.tar.lzma automake1.8-1.8.5-1-*-src.tar.lzma automake1.9-1.9.6-3-*-bin.tar.lzma automake1.9-1.9.6-3-*-doc.tar.lzma automake1.9-1.9.6-3-*-src.tar.lzma automake1.10-1.10.2-3-*-bin.tar.lzma automake1.10-1.10.2-3-*-doc.tar.lzma automake1.10-1.10.2-3-*-src.tar.lzma automake1.11-1.11-1-*-bin.tar.lzma automake1.11-1.11-1-*-doc.tar.lzma automake1.11-1.11-1-*-src.tar.lzma libtool-2.2.7a-1-*-bin.tar.lzma libtool-2.2.7a-1-*-doc.tar.lzma libtool-2.2.7a-1-*-dev.tar.lzma libtool-2.2.7a-1-*-dll7.tar.lzma libtool-2.2.7a-1-*-src.tar.lzma gettext-0.17-1-*-bin.tar.lzma [A] gettext-0.17-1-*-dev.tar.lzma [B] gettext-0.17-1-*-dll8.tar.lzma [C] gettext-0.17-1-*-doc.tar.lzma [D] gettext-0.17-1-*-ext.tar.lzma [E] gettext-0.17-1-*-src.tar.lzma libiconv-1.13-1-*-bin.tar.lzma libiconv-1.13-1-*-dev.tar.lzma libiconv-1.13-1-*-dll2.tar.lzma libiconv-1.13-1-*-doc.tar.lzma libiconv-1.13-1-*-src.tar.lzma [A] contains just the "gettext-runtime" native gettext executables, gettext, ngettext, envsubst, and gettext.sh (rats! another msys-dependent item). This follows the upstream suggestion about how to categorize the various utilities provided by gettext. This package also provides the libasprintf DLL. [B] The "gettext-tools" native development utilities like msg*.exe, xgettext.exe, and (gettextize + autopoint: more msys-dependent stuff!). Plus the import and static libraries for libintl. Also the /usr/share/gettext stuff like .m4 files and whatnot. Contains the libgettextpo DLL itself, as well as its import and static libraries and "private" DLLS, mainly because I can't think of a better package to put them in, while still following our naming convention. Finally, contains the libasprintf headers, import, and static libraries. [C] Contains only libintl-8.dll because that's what most external binary packages would actually depend on. They don't need also libasprintf and libgettextpo. [D] just man pages and basic documentation [E] All the other documentation including the gigantic examples directory. We can discuss the specific breakdown of the gettext package later in a different thread. I have some ideas that may help make this tiny corner of the problem a little more sane. Just save this email for now if you have issues with that -- let's keep this (sub)thread focused on the dadgummed subsys id thing. targetting msys development ============================ autoconf-2.63-1-*-bin.tar.lzma autoconf-2.63-1-*-doc.tar.lzma autoconf-2.63-1-*-src.tar.lzma automake-1.11-1-*-bin.tar.lzma automake-1.11-1-*-doc.tar.lzma automake-1.11-1-*-src.tar.lzma libtool-2.2.7a-1-*-bin.tar.lzma libtool-2.2.7a-1-*-doc.tar.lzma libtool-2.2.7a-1-*-dev.tar.lzma libtool-2.2.7a-1-*-dll7.tar.lzma libtool-2.2.7a-1-*-src.tar.lzma gettext-0.17-1-*-bin.tar.lzma [A] gettext-0.17-1-*-dev.tar.lzma [B] gettext-0.17-1-*-dll8.tar.lzma [C] gettext-0.17-1-*-doc.tar.lzma [D] gettext-0.17-1-*-ext.tar.lzma [E] gettext-0.17-1-*-src.tar.lzma libiconv-1.13-1-*-bin.tar.lzma libiconv-1.13-1-*-dev.tar.lzma libiconv-1.13-1-*-dll2.tar.lzma libiconv-1.13-1-*-doc.tar.lzma libiconv-1.13-1-*-src.tar.lzma -- Chuck |
From: Keith M. <kei...@us...> - 2009-07-06 17:08:48
|
On Saturday 27 June 2009 22:23:05 Charles Wilson wrote: > Keith Marshall wrote: > > On Friday 26 June 2009 18:42:28 Earnie Boyd wrote: > >>> *-mingw32-* were configured using --prefix=/mingw (or, in > >>> many cases, --prefix=`cd /mingw && pwd -W`. This formulation > >>> should always resolve to C:\MinGW for official MinGW > >>> packages). Thus, the subsys indicates the expected directory > >>> in which the package should be installed: C:\MinGW > >> > >> I agree. > > > > Sorry; while I see the logic behind this suggestion, I > > respectfully *disagree*. > > I knew that you would. This is where we ended over a year ago, > when a similar discussion died without resolution. Indeed. It died because we all became distracted by other issues and priorities; now may be a good time to resurrect it. To that end... > Right. So propose something SPECIFIC rather than general > accusations of irrationality. Break it down. Yes, I agree that I need to do that, but I also need some time to give the matter the consideration it deserves. I'm not even arguing that your choices are necessarily irrational -- indeed, they may even be the most rationally correct choices, but saying that they are so because of where we recommend installing isn't a rational basis for the choice; rather, the choice of standard installation path is a natural *consequence* of the initial subsystem choice. To determine a rational choice of subsystem, I think we need to consider how the $host is specified in the package build; in my case, where I cross compile with configuration options: --build=i686-pc-linux --host=mingw32 there is little doubt that the package should be classified as intended for a mingw32 subsystem. For users running MSYS in its default personality, they typically would specify neither --build nor --host; in such cases, both $build and $host are deemed to be identically equal to the output of config.guess, and for the system under consideration, with stock config.guess, that too is mingw32. Considered from this perspective, you have a completely rational basis for the choice you have already proposed, which is unaffected by Earnie's "wrench in the wheel" -- on this side of the Atlantic, we would call it a "spanner in the works" -- so I unreservedly withdraw my previous objections to your proposals. However, if we do proceed on this basis, there remains the potential for confusing users, who may expect a package classified as mingw32 to be suitable for use within a cmd.exe hosted workflow[*], where that may not, in fact, be the case. We need to make a clear statement to clarify this, perhaps adopting wording similar to that which you have proposed; I suggest that we do that via a PackageIdentificationHOWTO on MinGW.org [*] Do we need any package naming convention to discriminate MSYS hosted and cmd.exe hosted variants of the mingw32 subsystem? I am somewhat reluctant to further inflate the convention which we have currently agreed; however, if deemed necessary, pkginfo.l (which I have now developed further, such that it may be integrated into mingw-get as a dependency resolver component), will accept a qualified subsystem identifier, e.g.: $ ./pkginfo foo-1.0-mingw32-msys-bin.tar.xz Package Name: foo Package Version: 1.0 Package Build: <unspecified> Subsystem Name: mingw32-msys Subsystem Version: <unspecified> Subsystem Build: <unspecified> Release Status: <unspecified> Release Reference: <unspecified> Component Type: bin Component Version: <unspecified> Archive Format: tar Compression Type xz -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-07-06 21:06:02
|
On Mon, 06 Jul 2009 10:28 +0100, "Keith Marshall" wrote: > On Saturday 27 June 2009 22:23:05 Charles Wilson wrote: > > Right. So propose something SPECIFIC rather than general > > accusations of irrationality. Break it down. > > Yes, I agree that I need to do that, but I also need some time to > give the matter the consideration it deserves. I'm not even arguing > that your choices are necessarily irrational -- indeed, they may > even be the most rationally correct choices, but saying that they > are so because of where we recommend installing isn't a rational > basis for the choice; rather, the choice of standard installation > path is a natural *consequence* of the initial subsystem choice. > > To determine a rational choice of subsystem, I think we need to > consider how the $host is specified in the package build; That seems like a reasonable starting point. > in my > case, where I cross compile with configuration options: > > --build=i686-pc-linux --host=mingw32 > > there is little doubt that the package should be classified as > intended for a mingw32 subsystem. Right. > For users running MSYS in its > default personality, they typically would specify neither --build > nor --host; in such cases, both $build and $host are deemed to be > identically equal to the output of config.guess, and for the system > under consideration, with stock config.guess, that too is mingw32. Ooookay... > Considered from this perspective, you have a completely rational > basis for the choice you have already proposed, which is unaffected > by Earnie's "wrench in the wheel" -- on this side of the Atlantic, > we would call it a "spanner in the works" -- so I unreservedly > withdraw my previous objections to your proposals. Great...but now *I* have concerns. > However, if we > do proceed on this basis, there remains the potential for confusing > users, who may expect a package classified as mingw32 to be suitable > for use within a cmd.exe hosted workflow[*], where that may not, in > fact, be the case. Right. There may be MANY packages like that: any package that includes not just binary applications or libraries, but also scripts. Such as bzless, gzdiff, etc. That having been said... 1) MSYS and MinGW are supposed to be minimal. Really, there won't ever be all THAT many packages. (nothing even as comprehensive as cygwin, nor remotely approaching the size of your basic Linux distribution). So, this problem is limited (obviously) only to those packages we actually provide. Other than the autotools, what do we actually plan on shipping as -mingw32- binary packages? zlib, bzip2, xz, (maybe libarchive/bsdtar), and ? 2) If I see bzip2-*-mingw32, I'll assume that the DLL and EXEs are native mingw programs. If the package also includes helper scripts that happen to require a posix shell, I'm not going to be all that upset that "the -mingw32- subsystem marker is a LIE!". I certainly wouldn't expect TWO different packages, one called "mingw32-msys" and the other called "mingw32-cmd" where the latter contains those scripts rewritten as .bat files! I'd just accept that some of the ancillary scripts just aren't usable from a cmd-hosted workflow. And that's ok, as long as the main executables are. 3) Now, for packages (like most of the autotools), for which the "main" element of the package IS a shell (or perl) scripts requiring an MSYS host environment, the breezy justification in #2 above doesn't apply. Hence... > We need to make a clear statement to clarify > this, perhaps adopting wording similar to that which you have > proposed; I suggest that we do that via a PackageIdentificationHOWTO > on MinGW.org OK. Something like the following, maybe? The subsys indicates the standard installation prefix for which the package was configured. Thus, packages named *-mingw32-* In general, these packages were configured using --host=mingw32 (or, were configured and built "natively" within an MSYS environment, in which --host was not explicitly specified. In this circumstance, these builds behave as if --host=mingw32 was specified). In addition, these packages were all configured using --prefix=/mingw (or, in many cases, --prefix=`cd /mingw && pwd -W`; this formulation should always resolve to C:\MinGW for official MinGW packages). In almost all cases, these packages contain native win32 executables and libraries, and are usable without an MSYS installation. However, in some few cases the packages may also contain *scripts* written in shell or perl. In these cases, the scripts may not operate correctly unless an MSYS installation also exists. One notable group of packages that contain such scripts are the family of autotool packages with the -mingw32- subsys id. These package are: autoconf, automake, libtool, and gettext. Other packages, such as bzip2, provide primary functionality via native executables and libraries, and as such operate correctly in the absense of MSYS -- but provide addon features via scripts that require MSYS. In most cases, official MinGW packages with the -mingw32- subsystem id should be installed into the C:\MinGW directory. You may have limited success installing these packages into a different directory, and then "mounting" that directory via MSYS's /etc/fstab to "/mingw". (Obviously, this does not apply for non-MSYS-hosted environments -- and is not guaranteed to work even with MSYS. You're best to stick with C:\MinGW). *-msys-* These packages were configured using --host=msys and compiled using the special msysdvlpr environemnt. Binary executables and libraries in these packages depend on the MSYS DLL; they are not "native" mingw32 applications. These packages were configured using --prefix=/usr (and will *never* have been configured using the --prefix=`cd foo && pwd -W1 formulation). It is expected that these packages will be unpacked in the /usr == / directory -- that is, they should be unpacked into the versioned root directory for msys. Typically, this is C:\msys\1.0. Packages with the -msys- subsystem id are part of the msys environment, and generally help to provide a more "unix-like" experience for users building native mingw32 applications. > [*] Do we need any package naming convention to discriminate MSYS > hosted and cmd.exe hosted variants of the mingw32 subsystem? I don't think so; I believe that will just make things even more confusing. I hope we can simply refine the words above sufficiently that the nomenclature is clear enough for most people. -- Chuck |
From: Aaron W. L. <aar...@aa...> - 2009-06-27 23:19:06
|
My only input to this is that any resolution needs to be respectful of the fact that non-MSYS tools can be used with MinGW. In particular, Cygwin tools and ad-hoc Unix-like tool collections (such as unxutils and GnuWin32) should be supported as first-order MinGW configuration. Anything that assumes that MSYS is the only tool configuration for MinGW is incorrect, and the package structure needs to be set up to communicate this effectively. Unfortunately there are goofy and completely wrong things like the following that crop up if we don't keep this distinction clear. This particular instance I still need to look into and have corrected. From a recent libtool: > *mingw* ) > lt_sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g' > case $build in > *mingw* ) # actually, msys > # awkward: cmd appends spaces to result > lt_sed_strip_trailing_spaces="s/[ ]*\$//" > func_to_host_path_tmp1=`( cmd //c echo "$1" |\ It's wrong to assume the system is MSYS, and it is wrong to call cmd--mostly, because this doesn't actually work on both old model and late model systems. Getting this decision-making process wrong could yield substantial detriment to the future of GNU tools on Windows. |
From: Earnie B. <ea...@us...> - 2009-06-28 03:20:04
|
Quoting "Aaron W. LaFramboise" <aar...@aa...>: > Unfortunately there are goofy and completely wrong things like the > following that crop up if we don't keep this distinction clear. This > particular instance I still need to look into and have corrected. > > From a recent libtool: >> *mingw* ) >> lt_sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g' >> case $build in >> *mingw* ) # actually, msys >> # awkward: cmd appends spaces to result >> lt_sed_strip_trailing_spaces="s/[ ]*\$//" >> func_to_host_path_tmp1=`( cmd //c echo "$1" |\ > > It's wrong to assume the system is MSYS, and it is wrong to call > cmd--mostly, because this doesn't actually work on both old model and > late model systems. > All I can say is that libtool has usually sucked in regards to MinGW. I've had to many time manipulate the generated script after the fact to do the right thing. Basing decision on a bad tool isn't a good thing to do for us though. -- Earnie |
From: Charles W. <cwi...@us...> - 2009-06-28 05:42:35
|
Aaron W. LaFramboise wrote: > My only input to this is that any resolution needs to be respectful of > the fact that non-MSYS tools can be used with MinGW. In particular, > Cygwin tools and ad-hoc Unix-like tool collections (such as unxutils and > GnuWin32) should be supported as first-order MinGW configuration. > Anything that assumes that MSYS is the only tool configuration for MinGW > is incorrect, and the package structure needs to be set up to > communicate this effectively. > > Unfortunately there are goofy and completely wrong things like the > following that crop up if we don't keep this distinction clear. This > particular instance I still need to look into and have corrected. > > From a recent libtool: >> *mingw* ) >> lt_sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g' >> case $build in >> *mingw* ) # actually, msys >> # awkward: cmd appends spaces to result >> lt_sed_strip_trailing_spaces="s/[ ]*\$//" >> func_to_host_path_tmp1=`( cmd //c echo "$1" |\ > > It's wrong to assume the system is MSYS, No, it is not wrong. If you tell configure (and thus, libtool) that --build=mingw32, what is it supposed to think? Obviously you're not running on "naked" windows, because libtool itself is a shell script, not a .bat file. So SOME assumptions are in order. But this: "I should guess that some unspecified collection of unix utilities may or may not be available, and they may or may not accept dos-style and/or unix-style paths with some automatic or manual translation mechanism. But regardless of what IS or IS NOT available, I should always figure it out, and do the right thing, with no surprises ever." No, thanks. I'm just not smart enough to write and maintain that code in a shell script. > and it is wrong to call > cmd--mostly, because this doesn't actually work on both old model and > late model systems. Sorry. Libtool never did specifically support w9x, and it's not about to start now, seven years after microsoft EOLed it. Anyway, these complaints are all libtool things, and not specifically a mingw things (I should know; I wrote that bit). And it has nothing to do with the naming convention mingw will use to package upstream products, so I've changed the title of this subthread. If there's a problem in the code for those upstream products like libtool, the correct place to report bugs is bug...@gn..., and patches are always appreciated (if not quickly reviewed. Sigh.) at lib...@gn.... The code you are looking at is still a work in progress. It's been stalled now for almost six months, as I have had patches pending on the libtool-patches list waiting review. The current cygwin release has the latest though. Here's my thinking, for libtool, going forward: 1) "native" mingw ($host=mingw, $build=mingw) == mingw.org's MinGW compiler on msys (and in that case, cmd IS available. See above WRT win9x. I could see a well-tested patch to use $COMSPEC instead of hardcoding cmd.exe, perhaps.) 2) mingw on cygwin: a true cross compiler. That is, a cygwin-hosted mingw compiler, either supplied by the cygwin project or built on cygwin using mingw.org's xscript. You'd configure the thing you're trying to build using --build=cygwin --host=mingw. Note that this scenario is ***NOT*** mingw.org's native gcc accessed from cygwin. For that... 3) "Lie To Me". Running on cygwin, but using the mingw.org gcc. You'd configure using --build=mingw --host=mingw (that's the "lie", because --build is really cygwin) --- BUT, specifically related to the code fragment above, you'd set a libtool cache variable before running configure so it would DTRT, and not the (cmd ...) thing libtool would normally do on "native" (that is, mingw/msys) builds. export lt_cv_to_host_path_cmd=func_cygwin_to_mingw_path_convert Normally, for "native" [mingw/msys] builds, that variable is autodetected to be func_msys_to_mingw_path_convert. this is obviously not right when build is actually cygwin. AND, normally you'd simply be told "don't lie to your tools". But, because this particular lie currently works fairly well for a lot of people, I want to ensure that it continues to work in the future. 4) wine. a linux-hosted mingw cross compiler. Works like a normal cross compiler, but detects WINE and DTRT so that uninstalled executables -- including test programs -- can be run from WINE via the linux binfmt kernel extension. I have most of this working fairly well now, if not extensively tested yet. My primary goals with my ongoing libtool mods have been: 1) get libtool on mingw/msys working properly again, without the need for /etc/config.site 2) get wine-hosted mingw and cygwin target cross compiles working in lt-2.2 at least as well, and hopefully better than, they did in lt-1.5 3) *DO NOT BREAK* the gcc developer-favored approach for windows-hosted development: Danny Smith and Aaron both seem to use mingw (native) gcc from within cygwin. This MUST continue to work properly -- although it may require an extra environment setting or two. I figure those guys aren't babes in the woods; they can handle it. Now, as far a using gnuwin32 tools or unxutils to "host" libtool? Sorry, I don't have NEAR enough cycles to make that work out of the box. I won't go out of my way to break it, but most Gnuwin32 "installations" are too haphazard about what is or is not present to make any kind of functionality assumptions. If it works for you, great. Otherwise...you can keep all the pieces. -- Chuck |