From: Chris S. <ir0...@gm...> - 2009-04-13 16:51:43
|
Hey Aaron, Reading through the bug reports I saw that you mentioned that you are working on a GCC 4.4.0 test release (targeting a full 4.4.0 release to coincide with the official 4.4.0 release). Does there need to be an updated mingwrt or binutils required? Danny has posted a few fixes to mingwrt that I've committed to address failing test cases as a result of mingwrt. On the Cygwin lists I've read emails regarding a CVS of binutils required to address some issues as well. Please let me know if they are required and what kind of schedule you are looking at so that I can release any necessary updates. Thanx! Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Aaron W. L. <aar...@aa...> - 2009-04-14 20:00:28
|
Hi Chris, Thanks for bringing this up. See below. Chris Sutcliffe wrote: > Reading through the bug reports I saw that you mentioned that you are > working on a GCC 4.4.0 test release (targeting a full 4.4.0 release to > coincide with the official 4.4.0 release). Does there need to be an > updated mingwrt or binutils required? I don't think so. I've been using your current mingw.org releases, and they seem to work. I think the Cygwin stuff is due to some of the recent auto-import-related stuff that Dave Korn and others have been trying to use, but that shouldn't affect us yet, as I've tried to avoid it for our build. > Please let me know if they are required and what kind of schedule you > are looking at so that I can release any necessary updates. I will comprehensively update the status page on the wiki later so people can see exactly what's going on. In short, a lot of technical nonsense keeps dragging this out. I've allocated all of my time this week to getting the release cleaned up and out. If I get to Friday, and things are still messed up, I'm going to build and upload a final release anyway, which is probably something I should have done a long time ago. So you should expect the 'beta' release Saturday at the latest. Most likely, 4.4.0 will be released by the FSF within one or two weeks. |
From: Keith M. <kei...@us...> - 2009-04-15 17:03:12
|
On Tuesday 14 April 2009 20:41:22 Aaron W. LaFramboise wrote: > > Reading through the bug reports I saw that you mentioned that > > you are working on a GCC 4.4.0 test release (targeting a full > > 4.4.0 release to coincide with the official 4.4.0 release). > > Does there need to be an updated mingwrt or binutils required? > > I don't think so. I've been using your current mingw.org > releases, and they seem to work. What about other prerequisites? IIRC, you needed GMP, MPFR and pthreads-win32; any others? These are separate packages, and we should distribute as such, (just as we do binutils); they should not be embedded in an excessively bloated GCC tarball. > I will comprehensively update the status page on the wiki later > so people can see exactly what's going on. Look forward to seeing it; you should probably consider migrating your old wiki page to the new Drupal system. > I've allocated all of my time this week to getting the release > cleaned up and out. If I get to Friday, and things are still > messed up, I'm going to build and upload a final release anyway, > which is probably something I should have done a long time ago. > So you should expect the 'beta' release Saturday at the latest. That's good news; there are many eagerly awaiting movement in this direction; (some have become quite offensive, over its lack). > Most likely, 4.4.0 will be released by the FSF within one or two > weeks. Do you still plan to offer a stable release candidate, to coincide with that? -- Regards, Keith. |
From: Aaron W. L. <aar...@aa...> - 2009-04-15 21:49:28
|
Keith Marshall wrote: > What about other prerequisites? IIRC, you needed GMP, MPFR and > pthreads-win32; any others? These are separate packages, and we > should distribute as such, (just as we do binutils); they should > not be embedded in an excessively bloated GCC tarball. Yes, I'm planning on separating it as we had mentioned privately. Let me get back to you on exactly what the packages will be named etc to make sure its in line with the current thinking. I have DLLified all of these btw, as suggested by Charles Wilson, and I'm only planning on uploading the DLLs and source--that is, not complete 'bin' or development distributions. > Do you still plan to offer a stable release candidate, to coincide > with that? Yes. |
From: Keith M. <kei...@us...> - 2009-04-17 17:57:49
|
On Wednesday 15 April 2009 22:49:12 Aaron W. LaFramboise wrote: > > What about other prerequisites? IIRC, you needed GMP, MPFR and > > pthreads-win32; any others? These are separate packages, and > > we should distribute as such, (just as we do binutils); they > > should not be embedded in an excessively bloated GCC tarball. > > Yes, I'm planning on separating it as we had mentioned privately. > Let me get back to you on exactly what the packages will be > named etc to make sure its in line with the current thinking. Ok. > I have DLLified all of these btw, as suggested by Charles Wilson, > and I'm only planning on uploading the DLLs and source--that is, > not complete 'bin' or development distributions. That's fine. If just the DLL packages are sufficient to your needs, and if you don't want, or cannot afford, to invest time to maintain a full binary package set, then DLL + source only it shall be; your focus on GCC itself is much more valuable. Obviously, if anyone else is willing to invest the additional time and effort, to maintain full binary and development package sets, then that contribution would be welcomed. Otherwise, users seeking these additional components can look to the upstream projects. -- Regards, Keith. |
From: Aaron W. L. <aar...@aa...> - 2009-04-18 06:43:17
|
Keith Marshall wrote: > On Wednesday 15 April 2009 22:49:12 Aaron W. LaFramboise wrote: >> I have DLLified all of these btw, as suggested by Charles Wilson, >> and I'm only planning on uploading the DLLs and source--that is, >> not complete 'bin' or development distributions. > > That's fine. If just the DLL packages are sufficient to your needs, > and if you don't want, or cannot afford, to invest time to maintain > a full binary package set, then DLL + source only it shall be; your > focus on GCC itself is much more valuable. I can release complete packages if we determine this is best. However, there's a few issues. 1) Binaries that are good for GCC use may not be good for general-purpose use. For example, anyone who wants to use PPL will almost certainly want to get the most current sources and compile it for themselves. 2) This will produce a large amount of packages. Without a package manager, its going to become very confusing what is necessary to use GCC, and what is just lagniappe. Is it a goal of MinGW to produce mingw-32-targeted packages for all popular libraries, in a similar manner to what Cygwin does? If so, providing GMP development headers might be useful. If not, this is probably unnecessary clutter. |
From: Aaron W. L. <aar...@aa...> - 2009-04-18 06:35:40
Attachments:
names.txt
|
Keith, and anyone else interested in naming conventions, These are the naming conventions I intend to use for the upcoming beta release, based on previous discussions here and off-list. The names for the final 4.4.0 release will be similar, but of the form gcc-core-4.4.0-mingw32-bin.tar.gz. Please let me know if you'd like to see any changes. There's a lot of extra package splitting that could be done, but this could yield even more packages. As more advanced optimization passes are added to GCC, we can expect more outside libraries to be required in GCC 4.5, and ending up in 'package hell' is a very serious issue. Some possible changes: 1) Runtime DLLs could be split out of the gcc-xxx-bin packages into a gcc-xxx-dll package. This doubles the number of packages, as each language has one or more DLLs. 2) My copy of pkginfo.l is confused by gcc-4.4.0-20090413-mingw32-beta-notes.txt for some reason. Maybe release notes should be merged into one of the packages. 3) Maybe all of the compiler prerequisite DLLs (GMP, libiconv, PPL, etc) could be merged into gcc-core. This would probably save a ton of confusion, as no previous MinGW.org release has required download of extra packages to make gcc-core work. Note that executables generated by GCC do not use any of these DLLs. Please let me know what you think about this. |
From: Keith M. <kei...@us...> - 2009-04-18 14:40:15
Attachments:
pkginfo.tar.gz
|
Aaron, I'll have some further comments later, but for now... On Saturday 18 April 2009 07:35:28 Aaron W. LaFramboise wrote: > 2) My copy of pkginfo.l is confused by > gcc-4.4.0-20090413-mingw32-beta-notes.txt for some reason. Maybe > release notes should be merged into one of the packages. Mine says... $ ./pkginfo gcc-4.4.0-20090413-mingw32-beta-notes.txt Package Name: gcc Package Version: 4.4.0 Package Build: 20090413 Subsystem Name: mingw32 Subsystem Version: <unspecified> Subsystem Build: <unspecified> Release Status: beta Release Reference: <unspecified> Component Type: notes Component Version: <unspecified> Archive Format: txt Compression Type <unspecified> which seems reasonable. I have been tinkering with the scanner over the past few days, to wrap it into a C++ class for eventual use in the package manager, but I didn't think I'd actually changed any of the rules since I added the release status field detection. I have found a problem, if there's no component type field, (as is the case with our existing gcc-3.4.5 tarballs), and I still need to write a copy constructor and assignment operator implementation for my class, but I guess I could push the interim state into CVS, so we can all keep up to date, without me posting each change here. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-04-18 15:28:30
|
Aaron W. LaFramboise wrote: > These are the naming conventions I intend to use for the upcoming beta > release, based on previous discussions here and off-list. The names for > the final 4.4.0 release will be similar, but of the form > gcc-core-4.4.0-mingw32-bin.tar.gz. Please let me know if you'd like to > see any changes. > Some possible changes: > 1) Runtime DLLs could be split out of the gcc-xxx-bin packages into a > gcc-xxx-dll package. This doubles the number of packages, as each > language has one or more DLLs. Yes, but it should be done. That way our users can distribute a pre-compiled program that requires (e.g.) libgcc_s_1.dll without also having to tell /their/ users to download and install all of gcc; just gcc-runtime-*-dll (or whatever). Obviously there is no need for a libgcc_s_1.dll-specific -src package, thanks to the GPL runtime exception. > 2) My copy of pkginfo.l is confused by > gcc-4.4.0-20090413-mingw32-beta-notes.txt for some reason. Maybe > release notes should be merged into one of the packages. probably pkginfo.1 should be modified to ignore anything that is not an archive (whitelist .tar.[bz2|gz|lzma|xz]? blacklist .txt?) > 3) Maybe all of the compiler prerequisite DLLs (GMP, libiconv, PPL, etc) > could be merged into gcc-core. This would probably save a ton of > confusion, as no previous MinGW.org release has required download of > extra packages to make gcc-core work. Note that executables generated > by GCC do not use any of these DLLs. I'd prefer that libiconv be provided separately, because it IS (or can be) used by other compiled packages -- and, in fact, is a necessary prerequisite of the mingw32-targeted gettext autotool. So, if we are to provide a full mingw32-autotool chain as part of the MSYS-hosted development environment, then we must provide mingw-libiconv with all of its headers and import libraries. But...if we provide ONE separate -- and necessarily required -- dll package, what is the rationale for shortcutting the others? ("Aaron doesn't have time" is a FINE reason. A-OK.) I've no objections to doing so, *provided* that we can revisit the decision later and perhaps slipstream a more complete packageset for (e.g.) GMP at a later date if we decide it is worth it. However, if those DLLs are bundled into gcc-core then we can't "slipstream" a revised (expanded) release without also updating gcc-core AND adding what would then be a new and surprising additional download requirement. Better to get all of the surprises out of the way up front. Alternatively, suppose that the front-end drivers do NOT themselves link against any of the DLLs, but that instead just the back-end applications in /mingw/lib/gcc/*/* do. I don't know if that is true, but if it were: In THAT case (and only in that case) we could have gcc-specific DLLs installed into /mingw/lib/gcc/*/*/ that would be independent of any versions in /mingw/bin as supplied by "add-on" packages. Then, it would probably make sense to ship the gcc-specific versions in gcc-core. But this still would have the disadvantages outlined in Note #1, below. Note #1: if we want to have gcc-core be a monolithic download with no other requirements, then we should have all gcc executables link statically against their dependencies. The advantage of linking dynamically to those dependencies is it allows independent updates without relinking -- compared to static which would force the upstream gcc packager to do the work, and would force all users to download and update all of gcc just to get the updated (e.g.) gmp behavior). If you link dynamically but bundle the DLLs into gcc-core, you lose all of those advantages: the gcc maintainer STILL has to make a new gcc-core package, and all users have to download and install that giant pkg. The ONLY benefit of DLLs in that case would be that the gcc maintainer wouldn't actually have to relink before creating the updated gcc-core package. Note #2: Why did you need to roll your own libiconv DLL? Was there something wrong with the existing libiconv-1.11-1-bin.tar.bz2 libiconv-1.11-1-dll.tar.bz2 packages? I realize the 1.11 releases are old; if you really need 1.12 I can respin those (and repackage according to the new conventions) for you soonest... Actually, 1.13 was released last month so I could roll that one for you instead, if you like. (There's one wrinkle here; contact me offlist, Aaron). HOWEVER: I still have a question about the appropriate path for pre-compiled "native" (e.g. not MSYS) packages. Obviously, for gcc we'd want: /mingw/bin/*.dll /mingw/bin/*.exe so the tarballs contain bin/*.dll bin/*.exe If "add-on" packages (and, in this case, libiconv-*-dll would "look like" an add-on, even though it is required by MinGW itself) are installed "elsewhere", then users would need to ensure that PATH was properly set in order for gcc to work. However, I *believe* Earnie was in favor of pre-compiled add-on packages ALSO being packaged as: bin/*.dll bin/*.exe So that end-users COULD, if desired, install them directly into C:/MinGW/[bin|lib]/ right along with MinGW itself, if they chose. That's fine, but...not all packages are truly relocatable, and must be compiled up-front with the "correct" installation path. (e.g. prefix=`cd /mingw && pwd -W` -- and $prefix gets compiled-in to the target exe). What should be our "default" assumption about add-on packages -- and where would an automated installed unpack them? Should we assume that they WILL be installed into $same-prefix-as-gcc.exe, or instead into /mingw/local/ (in Windows form) or /usr/local/mingw/ or /mingw-local or what? (/usr/local is JUST WRONG: the msys-gcc compiler will search those headers and libs by default, and Bad Things(tm) will happen). The advantage of /mingw is obvious: no need for -L or -I when compiling against pre-compiled libs -- and no need for $PATH manipulations if gcc.exe requires one of the "add-on" DLLs. It's also simpler for the automated installer. The disadvantage is: you need to put a copy of the addons you wish to use into every C:/MinGW-4.3.2, C:/MinGW-3.4.5, etc parallel installation. I used to prefer a single, separate location (e.g. /mingw/local) for add-ons, but now I think it's actually better to put them into /mingw. That way, you're allowed -- if necessary -- to have different versions for different compilers; and it MAY actually BE necessary. Especially if (e.g.) you have C++ libs with gcc-4-dw2 or gcc-4-sjlj. Obviously, official pre-compiled native addons will be supplied ONLY in the EH mode supported by the official MinGW gcc package (which is what, again? I forgot?) So, I lean towards repackaging autoconf-4-1-bin.tar.bz2 autoconf2.1-2.13-3-bin.tar.bz2 autoconf2.5-2.61-1-bin.tar.bz2 automake-3-1-bin.tar.bz2 automake1.10-1.10-1-bin.tar.bz2 automake1.9-1.9.6-2-bin.tar.bz2 gettext-0.16.1-1-bin.tar.bz2 gettext-0.16.1-1-dll.tar.bz2 libiconv-1.11-1-bin.tar.bz2 libiconv-1.11-1-dll.tar.bz2 libtool1.5-1.5.25a-1-bin.tar.bz2 libtool1.5-1.5.25a-1-dll.tar.bz2 to install into /mingw (and use the new naming scheme, and updating to latest in each case, including libtool-2.2.x). FYI, I also plan to provide fairly soon a mingw-native version of liblzma (aka xz), libarchive, and bsdtar. This will allow direct support of .lzma and .xz compression from a native "tar". An MSYS version will take longer (there's a first!) because liblzma is adamantly C99 while msys-gcc-2.95.3 is C89 only. I was kinda waiting for the official xz-5.0 release before doing that, but there's been no indication of ETA so...now that the .xz format itself is finalized, I may have to stop waiting for xz-5.0 and just go with xz-4.999.8beta which works very well on cygwin. Depending on Aaron's needs, I may do this FIRST, so that all of the other packages can be .lzma. (We're not ready for .xz because none of the installer backends in consideration support it yet; but they do all seem to support .lzma IIRC). -- Chuck |
From: Earnie B. <ea...@us...> - 2009-04-19 10:15:41
|
Quoting Charles Wilson <cwi...@us...>: > Aaron W. LaFramboise wrote: >> These are the naming conventions I intend to use for the upcoming beta >> release, based on previous discussions here and off-list. The names for >> the final 4.4.0 release will be similar, but of the form >> gcc-core-4.4.0-mingw32-bin.tar.gz. Please let me know if you'd like to >> see any changes. > >> Some possible changes: >> 1) Runtime DLLs could be split out of the gcc-xxx-bin packages into a >> gcc-xxx-dll package. This doubles the number of packages, as each >> language has one or more DLLs. > > Yes, but it should be done. That way our users can distribute a > pre-compiled program that requires (e.g.) libgcc_s_1.dll without also > having to tell /their/ users to download and install all of gcc; just > gcc-runtime-*-dll (or whatever). Obviously there is no need for a > libgcc_s_1.dll-specific -src package, thanks to the GPL runtime exception. > I would make should be done a stronger must be done. -- Earnie |
From: Keith M. <kei...@us...> - 2009-04-20 18:11:00
|
On Saturday 18 April 2009 16:28:03 Charles Wilson wrote: > > 2) My copy of pkginfo.l is confused by > > gcc-4.4.0-20090413-mingw32-beta-notes.txt for some reason. > > Maybe release notes should be merged into one of the packages. > > probably pkginfo.1 should be modified to ignore anything that is > not an archive (whitelist .tar.[bz2|gz|lzma|xz]? blacklist .txt?) I don't see why that should be necessary. As I showed the other day, the output from my pkginfo.l was reasonable. OTOH, an *installer* would probably have no reason to do anything with the *-notes.txt file, but *it* could simply ignore it. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2009-04-20 18:11:37
|
On Saturday 18 April 2009 16:28:03 Charles Wilson wrote: > I'd prefer that libiconv be provided separately, So would I. > But...if we provide ONE separate -- and necessarily required -- > dll package, what is the rationale for shortcutting the others? > ("Aaron doesn't have time" is a FINE reason. A-OK.) I've no > objections to doing so, *provided* that we can revisit the > decision later and perhaps slipstream a more complete packageset > for (e.g.) GMP at a later date if we decide it is worth it. Yes, we need to retain that future flexibility. > However, if those DLLs are bundled into gcc-core then we can't > "slipstream" a revised (expanded) release without also updating > gcc-core AND adding what would then be a new and surprising > additional download requirement. Better to get all of the > surprises out of the way up front. Agreed. -- Regards, Keith. |
From: Luke K. C. L. <lk...@lk...> - 2009-04-19 09:49:49
|
>> The only reason I have is reduction in the number of packages and >> overall confusion of the manual installation process. Look at >> <http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Suite>, >> with relatively simple manual install instructions. With all of these >> prerequisites, the procedure will become harder to explain and harder to >> understand. > > I know. We *really* need a flexible automated installer. Sigh. whatever you do don't reinvent one. please also don't pick rpm, it was always crap. that leaves portage and dpkg as the sensible alternatives. portage is _very_ source-code-orientated, forcing the installation of header files as well as binaries. debian policy (and therefore its developer toolset) subdivides everything into two groups: the apps/libraries themselves, and the source/headers/libraries (known as build dependencies) required solely and exclusively by developers to _build_ the app/libraries. just like the mingw distribution does [separates developer files from source from binaries] prerequisites and procedures are taken care of with dependencies, pre_install and post_install scripts. great care has been taken to avoid circular dependencies. the use of a package manager would also help people avoid dll hell (as long as they don't interfere with the installed / managed packages). overall, dpkg is a good match. l. |
From: Keith M. <kei...@us...> - 2009-04-20 18:10:56
|
Moot point, really, since you've already accepted this: On Saturday 18 April 2009 07:35:28 Aaron W. LaFramboise wrote: > 3) Maybe all of the compiler prerequisite DLLs (GMP, libiconv, > PPL, etc) could be merged into gcc-core. Only if you can guarantee that no user application will ever elect to link against those libraries itself. Since this is unlikely to be the case, I must add my sanction to Chuck's "you should", and Earnie's "you must" separate them. -- Regards, Keith. |
From: Danny S. <dan...@cl...> - 2009-04-18 07:42:07
|
> what is just lagniappe. Aaron W. LaFramboise, I send you (virtual) flowers from New Zealand, the seed come from Tipitanas -- do you know? |
From: Danny S. <dan...@cl...> - 2009-04-18 08:11:15
|
----- Original Message ----- From: "Danny Smith" <dan...@cl...> To: "MinGW Devlopers Discussion List" <min...@li...> Sent: Saturday, April 18, 2009 7:39 PM Subject: Re: [MinGW-dvlpr] GCC 4.4.0 >> what is just lagniappe. > > Aaron W. LaFramboise, I send you (virtual) flowers from New Zealand, > the > seed come from Tipitanas -- do you know? just to explain, quoting Mark Twain, in "Life on the Mississippi" " We picked up one excellent word - a word worth travelling to New Orleans to get; a nice limber, expressive, handy word - "lagniappe." They pronounce it lanny-yap. It is Spanish - so they said. We discovered it at the head of a column of odds and ends in the Picayune, the first day; heard twenty people use it the second; inquired what it meant the third; adopted it and got facility in swinging it the fourth. It has a restricted meaning, but I think the people spread it out a little when they choose. It is the equivalent of the thirteenth roll in a "baker's dozen." It is something thrown in, gratis, for good measure. The custom originated in the Spanish quarter of the city. When a child or a servant buys something in a shop - or even the mayor or the governor, for aught I know - he finishes the operation by saying - "Give me something for lagniappe." The shopman always responds; gives the child a bit of licorice-root, gives the servant a cheap cigar or a spool of thread, gives the governor - I don't know what he gives the governor; support, likely. When you are invited to drink, and this does occur now and then in New Orleans - and you say, "What, again? - no, I've had enough;" the other party says, "But just this one time more - this is for lagniappe." When the beau perceives that he is stacking his compliments a trifle too high, and sees by the young lady's countenance that the edifice would have been better with the top compliment left off, he puts his "I beg pardon - no harm intended," into the briefer form of "Oh, that's for lagniappe." |
From: Luke K. C. L. <lk...@lk...> - 2009-04-18 15:15:49
|
> 2) This will produce a large amount of packages. Without a package > manager, its going to become very confusing what is necessary to use i looked at doing a mingw port of dpkg some months back, as the number of packages i was compiling were numerous and quite large, and it was getting out of hand. i stopped work on it because it was getting a little messy. i can try again if people believe it would be worthwhile. l. |
From: Earnie B. <ea...@us...> - 2009-04-19 10:20:01
|
Quoting Luke Kenneth Casson Leighton <lk...@lk...>: >> 2) This will produce a large amount of packages. Without a package >> manager, its going to become very confusing what is necessary to use > > i looked at doing a mingw port of dpkg some months back, as the > number of packages i was compiling were numerous and quite large, and > it was getting out of hand. i stopped work on it because it was > getting a little messy. i can try again if people believe it would be > worthwhile. > I've thought about doing apt recently. I know that Laura Michaels has the SlackWare package manager running paired with MSYS. I'm not familiar with it but she's thinking it is similar to our mingwPORTS scripts. -- Earnie |
From: Luke K. C. L. <lk...@lk...> - 2009-04-19 11:19:57
|
On Sun, Apr 19, 2009 at 10:19 AM, Earnie Boyd <ea...@us...> wrote: > Quoting Luke Kenneth Casson Leighton <lk...@lk...>: > >>> 2) This will produce a large amount of packages. Without a package >>> manager, its going to become very confusing what is necessary to use >> >> i looked at doing a mingw port of dpkg some months back, as the >> number of packages i was compiling were numerous and quite large, and >> it was getting out of hand. i stopped work on it because it was >> getting a little messy. i can try again if people believe it would be >> worthwhile. >> > > I've thought about doing apt recently. I know that Laura Michaels has > the SlackWare package manager running paired with MSYS. I'm not > familiar with it but she's thinking it is similar to our mingwPORTS > scripts. someone called balint reczey has apparently done a win32 port of apt - debian has of course moved on to aptitude, a slightly different beast, but hey it's good enough. dpkg is _very_ unix-centric. flock, fork, pipe, waitpid, the usual. *sigh*. i will knock dr ian jackson on the top of his 'ed - nicely - when i next see him :) l. |
From: Aaron W. L. <aar...@aa...> - 2009-04-18 21:49:30
|
I would like the project administrators to be involved in this discussion. We need to reach a consensus on a philosophical and policy issue. The most important issue here is about what MinGW should be, going forward: a) remain minimal, with only a small set of packages for the toolchain and make b) expand to include many general-purpose packages and a system of prerequisites, in a similar manner to what Cygwin does. Note that I am not talking about MSYS here. MSYS is separate and its use is optional, and I think we would like it to remain that way. See below. Charles Wilson wrote: > Aaron W. LaFramboise wrote: >> Some possible changes: >> 1) Runtime DLLs could be split out of the gcc-xxx-bin packages into a >> gcc-xxx-dll package. This doubles the number of packages, as each >> language has one or more DLLs. > > Yes, but it should be done. That way our users can distribute a > pre-compiled program that requires (e.g.) libgcc_s_1.dll without also > having to tell /their/ users to download and install all of gcc; just > gcc-runtime-*-dll (or whatever). OK, but I will also need some broad consensus from others on mingw-dvlpr that this is the right thing to do. That is, that is, that getting an installation with all of the languages should require downloading 17 packages, not including binutils or libraries. > But...if we provide ONE separate -- and necessarily required -- dll > package, what is the rationale for shortcutting the others? The only reason I have is reduction in the number of packages and overall confusion of the manual installation process. Look at <http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Suite>, with relatively simple manual install instructions. With all of these prerequisites, the procedure will become harder to explain and harder to understand. Please understand I'm not trying to avoid work. I'm only trying to keep this package from being difficult to install, and follow MinGW precedent and policy as I understand it. > Better to get all of the > surprises out of the way up front. I agree. Whatever arrangement we're going to come up with, I think it is best we decide on it now, at least as a matter of philosophy and policy. > Note #1: if we want to have gcc-core be a monolithic download with no > other requirements, then we should have all gcc executables link > statically against their dependencies. The advantage of linking > dynamically to those dependencies is it allows independent updates > without relinking It will be a very rare case that a bug in a GCC prerequisite will also cause a bug in the bundled version of GCC. > Note #2: Why did you need to roll your own libiconv DLL? Was there > something wrong with the existing > libiconv-1.11-1-bin.tar.bz2 > libiconv-1.11-1-dll.tar.bz2 > packages? As you mentioned elsewhere in your email, these are part of MSYS, which requires that MSYS is installed and being used to run GCC for GCC to work. One of these very few opinions that I have on any of this packaging stuff is that the MinGW tool chain should not depend on MSYS. I realize the 1.11 releases are old; if you really need 1.12 I > can respin those (and repackage according to the new conventions) for > you soonest... Actually, 1.13 was released last month so I could roll > that one for you instead, if you like. (There's one wrinkle here; > contact me offlist, Aaron). > > > HOWEVER: I still have a question about the appropriate path for > pre-compiled "native" (e.g. not MSYS) packages. Exactly. We've always had all native MinGW packages (non-MSYS) based in /mingw, with no dependencies outside of /mingw, and I think we should have a very good reason to change this. > So, I lean towards repackaging > > autoconf-4-1-bin.tar.bz2 > autoconf2.1-2.13-3-bin.tar.bz2 > autoconf2.5-2.61-1-bin.tar.bz2 > automake-3-1-bin.tar.bz2 > automake1.10-1.10-1-bin.tar.bz2 > automake1.9-1.9.6-2-bin.tar.bz2 > gettext-0.16.1-1-bin.tar.bz2 > gettext-0.16.1-1-dll.tar.bz2 > libiconv-1.11-1-bin.tar.bz2 > libiconv-1.11-1-dll.tar.bz2 > libtool1.5-1.5.25a-1-bin.tar.bz2 > libtool1.5-1.5.25a-1-dll.tar.bz2 > > to install into /mingw (and use the new naming scheme, and updating to > latest in each case, including libtool-2.2.x). My understanding is that you're proposing moving the autotools from MSYS to MinGW. A problem here is that these packages are dependent on MSYS, since they require a Bourne shell. |
From: Charles W. <cwi...@us...> - 2009-04-18 23:19:35
|
Aaron W. LaFramboise wrote: > I would like the project administrators to be involved in this > discussion. We need to reach a consensus on a philosophical and policy > issue. Sure. > The most important issue here is about what MinGW should be, going forward: > a) remain minimal, with only a small set of packages for the toolchain > and make > b) expand to include many general-purpose packages and a system of > prerequisites, in a similar manner to what Cygwin does. > > Note that I am not talking about MSYS here. MSYS is separate and its > use is optional, and I think we would like it to remain that way. Agreed. But we also should not deliberately create conflicts between the "MinGW" parts and the "MSys" parts (e.g. the libiconv-* packages: "you get the DLL from the MinGW side of the fence, but you need to replace it with the one from the MSys side if you're going to use the autotool chain, because the MSYS-host/mingw-target-libiconv maintainer and the gcc-libiconv maintainer use slightly different compilation settings when building the DLL...blah blah blah..." That way lies madness. [separate DLL packages] > OK, but I will also need some broad consensus from others on mingw-dvlpr > that this is the right thing to do. That is, that is, that getting an > installation with all of the languages should require downloading 17 > packages, not including binutils or libraries. Agreed. I'm not in charge. I'm just expressing my opinion. >> But...if we provide ONE separate -- and necessarily required -- dll >> package, what is the rationale for shortcutting the others? > > The only reason I have is reduction in the number of packages and > overall confusion of the manual installation process. Look at > <http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Suite>, > with relatively simple manual install instructions. With all of these > prerequisites, the procedure will become harder to explain and harder to > understand. I know. We *really* need a flexible automated installer. Sigh. > Please understand I'm not trying to avoid work. I'm only trying to keep > this package from being difficult to install, and follow MinGW precedent > and policy as I understand it. There's nothing wrong with avoiding (extra, unnecessary) work. And, if you become overloaded by explicit maintainance needs for a half-dozen supporting packages, that reduces the time you can spend supporting gcc. So there's nothing wrong with "Aaron does bare minimum now; someone else can elaborate as needed/desired later". We just need to plan ahead. >> Better to get all of the >> surprises out of the way up front. > > I agree. Whatever arrangement we're going to come up with, I think it > is best we decide on it now, at least as a matter of philosophy and policy. Ack. >> Note #1: if we want to have gcc-core be a monolithic download with no >> other requirements, then we should have all gcc executables link >> statically against their dependencies. The advantage of linking >> dynamically to those dependencies is it allows independent updates >> without relinking > > It will be a very rare case that a bug in a GCC prerequisite will also > cause a bug in the bundled version of GCC. Yeah, but it also allows to offload maintainance needs from the gcc maintainer to some other volunteer. (e.g. David Billinghurst maintains gmp, mpfr. mpc, and PPL for cygwin, I maintain libiconv and gettext, cgf maintains binutils, leaving Dave Korn free to focus (mostly) on gcc itself. I think gcc alone is plenty for one human.) E.g. do you really want to be "the guy" that answers questions about why iconv.exe "doesn't work right in mingw", just because you (may) supply it as a "side effect" of libiconv? Static (especially static build-in-src/-tree) doesn't give that kind of flexibility to offload. >> Note #2: Why did you need to roll your own libiconv DLL? Was there >> something wrong with the existing >> libiconv-1.11-1-bin.tar.bz2 >> libiconv-1.11-1-dll.tar.bz2 >> packages? > > As you mentioned elsewhere in your email, these are part of MSYS, which > requires that MSYS is installed and being used to run GCC for GCC to work. Uhm, no. These are the one that depend on MSYS: libiconv-1.11-MSYS-1.0.11-1-src.tar.bz2 libiconv-1.11-MSYS-1.0.11-1.tar.bz2 The ones I mentioned before are plain, native, mingw ports (well, not "MinGWPorts" exactly). They were *built* from within an MSYS environment -- but that's no different than building from a cygwin- or linux- hosted cross environment, as you did when building your version. > One of these very few opinions that I have on any of this packaging > stuff is that the MinGW tool chain should not depend on MSYS. Absolutely. >> HOWEVER: I still have a question about the appropriate path for >> pre-compiled "native" (e.g. not MSYS) packages. > > Exactly. We've always had all native MinGW packages (non-MSYS) based in > /mingw, with no dependencies outside of /mingw, and I think we should > have a very good reason to change this. Right. That's not at issue. I'm only talking about mingw ports (not "MinGWPorts" necessarily) -- but native, win32, no-MSYS-required builds of various libraries. Naturally, just the barest minimum (in keeping with the minimal nature of the whole beast) of libraries needed for runtime support of gcc itself. Now, libiconv and gettext are a little odd: on the one hand, they (their DLLs, that is) are needed *at runtime* by the gcc executables themselves [*]. That means these mingw-native DLLs are on the "MinGW" distribution side of the fence. On the other hand, they (their utilities, import libs, static libs, header files, data files, and m4/ stuff) are also part of an MSYS-hosted, mingw-native-target autotool development environment. That makes them (the native, win32 versions) also part of the "MSYS" distribution. [*] well, not gettext/libintl.dll exactly. You're building gcc with no i18n support, so you don't actually need libintl.dll. But in the future, theoretically we could do so. (I'm ignoring the versions of libiconv/gettext compiled explicitly to link against MSYS itself; those are part of the "MSYS-dvlpr" environment. Their tarballs will include "MSYS-1.0.11" in the name, and are not under discussion here). So, the native, win32, mingw-only, no-msys-in-sight version of the libiconv DLL...is needed by both "regular" msys-less gcc by itself, but also by an msys-hosted mingw-target development environment elaborated with the associated utilities, import libraries, static libs, headers, etc. Those two uses should be complementary, not conflicting. >> So, I lean towards repackaging >> >> autoconf-4-1-bin.tar.bz2 >> autoconf2.1-2.13-3-bin.tar.bz2 >> autoconf2.5-2.61-1-bin.tar.bz2 >> automake-3-1-bin.tar.bz2 >> automake1.10-1.10-1-bin.tar.bz2 >> automake1.9-1.9.6-2-bin.tar.bz2 >> gettext-0.16.1-1-bin.tar.bz2 >> gettext-0.16.1-1-dll.tar.bz2 >> libiconv-1.11-1-bin.tar.bz2 >> libiconv-1.11-1-dll.tar.bz2 >> libtool1.5-1.5.25a-1-bin.tar.bz2 >> libtool1.5-1.5.25a-1-dll.tar.bz2 >> >> to install into /mingw (and use the new naming scheme, and updating to >> latest in each case, including libtool-2.2.x). > > My understanding is that you're proposing moving the autotools from MSYS > to MinGW. No, that's not my proposal. The existing autotools are already present in two flavors: an MSYS-dvlpr flavor: autoconf-2.61-MSYS-1.0.11-1-src.tar.bz2 autoconf-2.61-MSYS-1.0.11-1.tar.bz2 automake-1.10-MSYS-1.0.11-1-src.tar.bz2 automake-1.10-MSYS-1.0.11-1.tar.bz2 libtool1.5-1.5.25a-20070701-MSYS-1.0.11-1-src.tar.bz2 libtool1.5-1.5.25a-20070701-MSYS-1.0.11-1.tar.bz2 libiconv-1.11-MSYS-1.0.11-1-src.tar.bz2 libiconv-1.11-MSYS-1.0.11-1.tar.bz2 gettext-0.16.1-MSYS-1.0.11-1-src.tar.bz2 gettext-0.16.1-MSYS-1.0.11-1.tar.bz2 gettext-devel-0.16.1-MSYS-1.0.11-1.tar.bz2 Those are installed into (msys-path) /usr/[bin|lib|include], and are linked with msys dll, and are needed only by people working on msys-linked tools themselves. We also already have mingw-target versions of the autotools. These are the ones listed in my previous email. They are part of the MSYS (-host, mingw-target) environment and I am not proposing to change that. However, none of those binaries (EXEs or DLLs) link against or need in any way the msys.dll. All I'm proposing is that these (mingw-native, win32-only, no-msys-dll-in-sight) tools be *installed* into /mingw by default -- even if (with exactly one exception) they are not "part of" the default "MinGW" distribution. They are part of the MSYS supplement. The exception is the (currently not present) package: libiconv-*-dll.tar.bz2 which would show up -- with exactly the same name and build ID -- in the sourceforge download area under BOTH "MSYS Supplementary Tools" and "MinGW". Because that DLL -- alone -- is truly a member of both categories: it's part of the msys-hosted mingw-target autotool chain, but is also a prerequisite of the MinGW gcc binaries. The same *might* be true also of gettext (that is, libintl.dll), IF you choose at some point to build gcc with i18n turned on. I *ALSO* think it's possible that the libiconv and gettext packages targeted for mingw should be built with Bruno Haible's "relocation" support turned on, but that's another issue, and one that will require more thought than I've yet put into it. > A problem here is that these packages are dependent on MSYS, > since they require a Bourne shell. Yes, the *utilities* do. But you wouldn't install *those* as part of "MinGW" anyway. You'd only install *the utilities* as part of an MSYS supplemental installation. It's just that those scripts (and exe's, which are after all native, non-msys-dependent binaries) would go in /mingw/bin. However, the DLLs and EXEs (like gettext.exe or iconv.exe) are just plain old win32 ports; nothing about them requires msys dll. So, suppose somebody is USING mingw + msys to build -- oh, I dunno, say i18n-enabled ogg encoder tools -- that links against libintl and libiconv. Now, since these are already provided (with implibs) as part of the msys-supplement as a side effect of the msys-host/mingw-target autotool chain, AND since the DLL "lives" in /mingw/bin because gcc.exe needs it -- it sure would be nice if the rest of those import libs and headers "lived" under /mingw/[lib|include] so that the user doesn't need to use -L/-I for MinGW "system" [**] libraries like that. It'd also be weird to have the DLL in /mingw/bin, but the related files NOT in /mingw/bin/../[lib|include] because then the .la files would need futzing. It's be even weirder to provide TWO official versions of libiconv.dll -- one in /mingw/bin/ and another in /somewhere/bin with associated files in /somewhere/[lib|include]. [**] They are MinGW "system" libraries because the *MinGW* system (that is, gcc.exe) needs and provides them. I guess I'm thinking of "MSYS Supplement" and "MinGW" as two different metapackages of an overarching set of "stuff we provide" -- so *where* individual components get installed on the user's hard drive is not necessarily a discriminator between the "MinGW" metapackage and the "MSYS Supplement" metapacakge. Some "MSYS Supplement" stuff goes in C:/msys/1.0/*, and some goes into C:/MinGW. Yes, that means that the *msys* installer needs to allow the end-user to select (or autodetect) two different installation paths. One for the "MinGW" stuff (and the "MSYS Supplement" stuff that is not directly msys-related), and one for the real MSYS-required stuff like perl.exe, sh.exe, etc. -- Chuck |
From: Keith M. <kei...@us...> - 2009-04-20 18:29:13
|
On Sunday 19 April 2009 00:19:11 Charles Wilson wrote: > >> Note #2: Why did you need to roll your own libiconv DLL? Was > >> there something wrong with the existing > >> libiconv-1.11-1-bin.tar.bz2 > >> libiconv-1.11-1-dll.tar.bz2 > >> packages? > > > > As you mentioned elsewhere in your email, these are part of > > MSYS, which requires that MSYS is installed and being used to > > run GCC for GCC to work. > > Uhm, no. These are the one that depend on MSYS: > > libiconv-1.11-MSYS-1.0.11-1-src.tar.bz2 > libiconv-1.11-MSYS-1.0.11-1.tar.bz2 > > The ones I mentioned before are plain, native, mingw ports (well, > not "MinGWPorts" exactly). They were *built* from within an MSYS > environment -- but that's no different than building from a > cygwin- or linux- hosted cross environment, as you did when > building your version. Yeah. We've mentioned this before: listing this pair libiconv-1.11-1-bin.tar.bz2 libiconv-1.11-1-dll.tar.bz2 within the "MSYS Supplementary Tools" package set is just plain wrong. While they may have been needed initially to support tools which do belong there, the DLL package is *already* a prerequisite for the gencat tool from mingw-catgets-1.0-dev.tar.gz, which is listed among the "User Contributed" package collections. > >> HOWEVER: I still have a question about the appropriate path > >> for pre-compiled "native" (e.g. not MSYS) packages. > > > > Exactly. We've always had all native MinGW packages (non-MSYS) > > based in /mingw, with no dependencies outside of /mingw, and I > > think we should have a very good reason to change this. > > Right. That's not at issue. It isn't an issue, at all; it is *convenient*, (for mass production of binary releases), to distribute for installation into the /mingw tree, and I see no reason to change that. > I'm only talking about mingw ports (not "MinGWPorts" necessarily) > -- but native, win32, no-MSYS-required builds of various > libraries. Naturally, just the barest minimum (in keeping with > the minimal nature of the whole beast) of libraries needed for > runtime support of gcc itself. Now, libiconv and gettext are a > little odd: on the one hand, they (their DLLs, that is) are > needed *at runtime* by the gcc executables themselves [*]. That > means these mingw-native DLLs are on the "MinGW" distribution > side of the fence. On the other hand, they (their utilities, > import libs, static libs, header files, data files, and m4/ > stuff) are also part of an MSYS-hosted, mingw-native-target > autotool development environment. That makes them (the native, > win32 versions) also part of the "MSYS" distribution. Again, this is largely a matter of convenience; it is convenient to run these tools in a MSYS hosted environment, (in particular, those which do require support from MSYS programs). However, there is no reason why the native DLLs, and even the native tools shouldn't be installed into the MinGW tree, rather than an MSYS specific path. > So, the native, win32, mingw-only, no-msys-in-sight version of > the libiconv DLL...is needed by both "regular" msys-less gcc by > itself, but also by an msys-hosted mingw-target development > environment elaborated with the associated utilities, import > libraries, static libs, headers, etc. Those two uses should be > complementary, not conflicting. Agreed. > We also already have mingw-target versions of the autotools. > These are the ones listed in my previous email. They are part of > the MSYS (-host, mingw-target) environment and I am not proposing > to change that. However, none of those binaries (EXEs or DLLs) > link against or need in any way the msys.dll. All I'm proposing > is that these (mingw-native, win32-only, no-msys-dll-in-sight) > tools be *installed* into /mingw by default -- even if (with > exactly one exception) they are not "part of" the default "MinGW" > distribution. They are part of the MSYS supplement. Seems to me that that would already be achievable, if the distribution tarballs had "usr/local/" removed from their package root; then the choice can be made at installation time, by making the appropriate "cd" choice, prior to extracting the tarball. > I *ALSO* think it's possible that the libiconv and gettext > packages targeted for mingw should be built with Bruno Haible's > "relocation" support turned on, but that's another issue, and one > that will require more thought than I've yet put into it. I don't know exactly what effect that might have; I just built libiconv-1.13 with "--enable-relocatable --disable-nls", and with prefix set to `cd /mingw; pwd -W`, then installed into a completely different staging directory; iconv.exe seems, with very limited testing, to behave as expected. (The only issue I encountered was that "install-strip" failed, (but bare "install" was ok); likely a missing "$(EXEEXT)" in some Makefile.in). -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-04-20 18:55:43
|
Keith Marshall wrote: > Seems to me that that would already be achievable, if the > distribution tarballs had "usr/local/" removed from their package > root; then the choice can be made at installation time, by making > the appropriate "cd" choice, prior to extracting the tarball. That's exactly what I'm proposing, BUT ALSO: to explicitly compile the libraries with --prefix=`cd /mingw && pwd -W`. This is because, as I mentioned in another message, libintl (and maybe libiconv, but possible not) hardcodes $PREFIX into the binary. So, "C:\Msys\1.0\local\" would be a bad thing, if you install that binary into "C:\MinGW-4.3\". Unless... >> I *ALSO* think it's possible that the libiconv and gettext >> packages targeted for mingw should be built with Bruno Haible's >> "relocation" support turned on, but that's another issue, and one >> that will require more thought than I've yet put into it. > > I don't know exactly what effect that might have; I just built > libiconv-1.13 with "--enable-relocatable --disable-nls", and with > prefix set to `cd /mingw; pwd -W`, then installed into a completely > different staging directory; iconv.exe seems, with very limited > testing, to behave as expected. Yes, I went several rounds with Bruno getting that stuff to work properly on cygwin and mingw. I just wasn't sure if it had bitrotted since -- good to hear that it apparently has not. (Unfortunately, it can't work at all in the msys-dependent versions; gcc-2.95.3 doesn't support the necessary constructs. I don't think that's an issue we need concern ourselves with, but that's a topic for another thread.) > (The only issue I encountered > was that "install-strip" failed, (but bare "install" was ok); > likely a missing "$(EXEEXT)" in some Makefile.in). IIRC my cygwin patches include some fix along those lines. I'll double check later. -- Chuck |
From: Luke K. C. L. <lk...@lk...> - 2009-04-19 09:56:51
|
> Exactly. We've always had all native MinGW packages (non-MSYS) based in > /mingw, with no dependencies outside of /mingw, and I think we should > have a very good reason to change this. libgcc_s.dll, mentioned earlier, is about the only thing that would break the rules, and its creation is outside of mingw-dev's control. http://gcc.gnu.org/ml/gcc/2002-06/msg00591.html ok - so you _could_ create a gcc 4.4 compiler with a default spec that forced static linking with libgcc_s... |
From: Luke K. C. L. <lk...@lk...> - 2009-04-19 11:29:28
|
> I've thought about doing apt recently. I know that Laura Michaels has > the SlackWare package manager running paired with MSYS. I'm not from what i gather from richard lightman who looked at it before starting with the "linux from scratch" project instead, the ethos behind slackware is that if it don't work unmodified, it don't go in. no patches, no fancy options to ./configure - nothing. with dpkg, you get to put your own patches *outside* of the tarball, and you get support from dpkg's build process to perform patches in specific orders (001.xxxx.patch, 002.yyyy.patch etc.). debian has 30,000 packages and climbing, and approx 1,000 maintainers. once you start down the dpkg road, users have the serious option of being able to hook in to the source tarballs of all those packages, and, at some point down the road, serious consideration could be given to having "win32" as a supported debian architecture, alongside the other 13 or so including gnu-hurd-i386 of all things. btw - mingw32 is like the "ground zero" to get started - the bootstrap - so is never going to go away, even if a package manager (whatever it may be) is deployed. l. |