Re: Patch: Setup.exe - search for package
Andrew Punch wrote: > So would you like me to do the tooltip, alignment and label - or would > you prefer to do it? Sorry if that wasn't clear; I already added it in the reformatted version of your patch attached to my last message! cheers, DaveK
Re: [RFC] ready for cygport to default to gcc4?
Charles Wilson wrote: > Yaakov (Cygwin/X) wrote: >> Are maintainers ready for cygport-0.9 (for 1.7 only) to default to gcc4? > > No. > > gcc4 is still an *experimental* release: > > "[ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2" > http://cygwin.com/ml/cygwin/2009-03/msg00378.html > > We shouldn't default to using it until the gcc maintainer is confident > enough in it to promote it officially. I know it's a bit of a > chicken/egg problem, but there you go. > > (Besides, IIRC there is still an existing problem with g++, and > overriding operator new/delete. This would be a problem for xerces.) Mm. On the one hand, I think GCC4 is in very good and reliable shape. On the other there's this C++ issue, which is still anything up to a couple of weeks' work and a binutils update away from properly resolving. I considered suggesting GCC-4 with everything statically linked, but that would give us exceptions-out-of-dlls problems owing to the sjlj/dw2 switch, and you can't have static libstdc++ (which would resolve the overriding problem) with shared libgcc. I wonder exactly how many packages there are in the distro that would actually suffer from this problem. It would be an option to switch the default and tell maintainers they'll have to test their packages and special-case the ones that need the overriding behaviour to work right, or perhaps continue with gcc-3 (sjlj and all static linking) for now, but I don't have a good feel for just how much or little grief that might cause. Hmm, I feel a third option coming on. I could do a special case hack, that works just for libstdc++, by putting the objects for the overrideable functions into the import library archive instead of the DLL. But then we'd still have problems if a library built as a DLL overrides operator new (that bit will work), and then the application does so too; we'll just have moved the interposing problem 'out one layer' from libstdc++ to the client dll. Not sure if I like that either. I think I'd better just pull a bunch of all nighters and get this weak symbol support working ASAP :-) cheers, DaveK
Re: [RFC] ready for cygport to default to gcc4?
On Apr 3 08:44, Dave Korn wrote: > Hmm, I feel a third option coming on. > > I could do a special case hack, that works just for libstdc++, by putting > the objects for the overrideable functions into the import library archive > instead of the DLL. But then we'd still have problems if a library built as a > DLL overrides operator new (that bit will work), and then the application does > so too; we'll just have moved the interposing problem 'out one layer' from > libstdc++ to the client dll. Not sure if I like that either. > > I think I'd better just pull a bunch of all nighters and get this weak > symbol support working ASAP :-) Btw., did the pe-coff flags option already make it into binutils? We should make sure that newly built applications (including Cygwin's utils itself) have the TS-aware bit set by default. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA][1.7] GraphicsMagick-1.3.5-2
On Mar 22 10:23, Marco Atzeri wrote: > to download > wget -r -np http://matzeri.altervista.org/cygwin-1.7/GraphicsMagick/ > > > ./GraphicsMagick-1.3.5-2-src.tar.bz2 > ./GraphicsMagick-1.3.5-2.tar.bz2 > ./index.html > ./libGraphicsMagick-devel > ./libGraphicsMagick-devel/index.html > ./libGraphicsMagick-devel/libGraphicsMagick-devel-1.3.5-2.tar.bz2 > ./libGraphicsMagick-devel/setup.hint > ./libGraphicsMagick3 > ./libGraphicsMagick3/index.html > ./libGraphicsMagick3/libGraphicsMagick3-1.3.5-2.tar.bz2 > ./libGraphicsMagick3/setup.hint > ./perl-Graphics-Magick > ./perl-Graphics-Magick/index.html > ./perl-Graphics-Magick/perl-Graphics-Magick-1.3.5-2.tar.bz2 > ./perl-Graphics-Magick/setup.hint > ./setup.hint Uploaded. Thanks for taking over maintainership! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFC] ready for cygport to default to gcc4?
Corinna Vinschen wrote: > On Apr 3 08:44, Dave Korn wrote: >> Hmm, I feel a third option coming on. >> >> I could do a special case hack, that works just for libstdc++, by putting >> the objects for the overrideable functions into the import library archive >> instead of the DLL. But then we'd still have problems if a library built as >> a >> DLL overrides operator new (that bit will work), and then the application >> does >> so too; we'll just have moved the interposing problem 'out one layer' from >> libstdc++ to the client dll. Not sure if I like that either. >> >> I think I'd better just pull a bunch of all nighters and get this weak >> symbol support working ASAP :-) > > Btw., did the pe-coff flags option already make it into binutils? We > should make sure that newly built applications (including Cygwin's utils > itself) have the TS-aware bit set by default. Yeh, it did. Once the weak symbols fix is working and there's a new binutils package, I'll extend the gcc linker spec to add the right option. cheers, DaveK
Re: [RFC] ready for cygport to default to gcc4?
Yaakov (Cygwin/X) wrote: >Charles Wilson wrote: >> gcc4 is still an *experimental* release: >> >> We shouldn't default to using it until the gcc maintainer is confident >> enough in it to promote it officially. I know it's a bit of a >> chicken/egg problem, but there you go. > > 1) A few maintainers have already started using gcc4 for their packages. > While I thought that doing so with 4.3.2-1 on 1.5 was a bit premature, > not so now. Well, we disagree. Big surprise, I know. I believe it is premature to use any test or experimental release when building an official package [*], until the maintainer of that package removes the experimental designation (or, when using setup's test:/curr: facilities, promotes it to curr:). [*] short of some overriding reason, such as: (a) two dependent packages with different maintainers must coordinate their release -- so SOMEBODY has to go to curr: first, or (b) a new package just plain won't work unless the test:/experimental dependency is used. Like octave vs. gcc4, IIRC. > 2) How should Dave be able to stabilize gcc4 if nobody is testing it? > Same goes for cygwin-1.7 for that matter, and I think I've been doing my > part testing both. Yes, you have. This is what I meant when I said "chicken/egg problem". I believe you have been doing The Right Thing: (semi-)private builds of your packages using the experimental gcc4 -- not cygwin-mirror-system public releases of your packages using that compiler. At this point, if you're happy with the way your packages are behaving with respect to the new compiler, it's perfectly legitimate for you to lobby Dave to remove the experimental designation from gcc4. But, IMO, it is not legitimate to try to de-facto override Dave's decision as the gcc maintainer, and MAKE gcc4 the default compiler via your privileged position as the maintainer of cygport, if gcc's own maintainer still believes gcc4 is experimental. > Bottom line, we need to look at what the distro should like when > cygwin-1.7 goes stable, and set a direction. Yes, and we're (slowly) getting there. BTW, I do not believe the following thread "[RFC] ABI bump for building with gcc4 ?" http://cygwin.com/ml/cygwin-apps/2009-03/msg00033.html ever reached a resolution. Only you, Dave, and I participated...any other maintainers have an opinion? FWIW, I'm starting to lean in your direction (towards a flag day release) on that regard, but I'd really like to hear from Corinna and/or cgf on that issue. Also, a flag day release requires the participation of ALL maintainers, so it's not a decision that just a few of us can make on our own. -- Chuck
Re: [RFC] ready for cygport to default to gcc4?
Charles Wilson wrote: > But, IMO, it is not legitimate to try to de-facto override Dave's > decision as the gcc maintainer, and MAKE gcc4 the default compiler via Slow down there; Yaakov was not doing anything other than making a reasonable proposal. Note the [RFC] in the subject! cheers, DaveK
Re: [RFC] ready for cygport to default to gcc4?
On Apr 3 10:23, Charles Wilson wrote: > Yes, and we're (slowly) getting there. BTW, I do not believe the > following thread > "[RFC] ABI bump for building with gcc4 ?" > http://cygwin.com/ml/cygwin-apps/2009-03/msg00033.html > ever reached a resolution. Only you, Dave, and I participated...any > other maintainers have an opinion? Not me. I'm just going with the flow. > FWIW, I'm starting to lean in your direction (towards a flag day > release) on that regard, but I'd really like to hear from Corinna and/or > cgf on that issue. Also, a flag day release requires the participation > of ALL maintainers, so it's not a decision that just a few of us can > make on our own. Many packages have no requirement for a flag day at all. What about packages like sed, which basically consist of a single application? What sense does it make to re-build it with gcc4? Not all maintainers are very active. That's no criticism, it's just the fact of life and, even when not being as active as the core pack, they are helping the Cygwin distro a lot. Having said that, I think that a flag day is sort of impracticable. We can require that new packages and new versions of new packages will be built using gcc-4. But I don't see a reason to rebuild already existing package versions. Time (new upstream release) or necessity (spurious crashes) will take care of that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFC] ready for cygport to default to gcc4?
On Fri, Apr 03, 2009 at 05:02:24PM +0200, Corinna Vinschen wrote: >On Apr 3 10:23, Charles Wilson wrote: >> Yes, and we're (slowly) getting there. BTW, I do not believe the >> following thread >> "[RFC] ABI bump for building with gcc4 ?" >> http://cygwin.com/ml/cygwin-apps/2009-03/msg00033.html >> ever reached a resolution. Only you, Dave, and I participated...any >> other maintainers have an opinion? > >Not me. I'm just going with the flow. > >> FWIW, I'm starting to lean in your direction (towards a flag day >> release) on that regard, but I'd really like to hear from Corinna and/or >> cgf on that issue. Also, a flag day release requires the participation >> of ALL maintainers, so it's not a decision that just a few of us can >> make on our own. > >Many packages have no requirement for a flag day at all. What about >packages like sed, which basically consist of a single application? >What sense does it make to re-build it with gcc4? > >Not all maintainers are very active. That's no criticism, it's just the >fact of life and, even when not being as active as the core pack, they >are helping the Cygwin distro a lot. As one of the maintainers who falls in the sporadically active category I really don't relish the thought of a flag day version bump. I wasn't paying really close attention but I seem to recall Yaakov mentioning that other distros didn't require a version bump when moving to gcc4 so I would rather not do this. And, as Corinna mentions, it would be very difficult to pull off anyway. cgf
Re: [RFC] ready for cygport to default to gcc4?
Corinna Vinschen wrote: > Many packages have no requirement for a flag day at all. What about > packages like sed, which basically consist of a single application? > What sense does it make to re-build it with gcc4? See below. > Not all maintainers are very active. That's no criticism, it's just the > fact of life and, even when not being as active as the core pack, they > are helping the Cygwin distro a lot. Yes, they are. And that's the biggest argument against requiring a flag day. > Having said that, I think that a flag day is sort of impracticable. > We can require that new packages and new versions of new packages > will be built using gcc-4. But I don't see a reason to rebuild > already existing package versions. Time (new upstream release) or > necessity (spurious crashes) will take care of that. Well, the problem is this: There are 55 packages that rely on libintl8 (and 50 that still use libintl3 or libintl2, but that doesn't matter here). If I rebuild gettext using gcc4 AND if the switch to gcc4 + shared libgcc means that there is some sort of breakage (e.g. between a client that uses the old, static runtime, and this DLL that uses the new, dynamic runtime) -- then EVERY package that relies on libintl8 just broke. Unless I bump the ABI number to libintl9. But that's exactly what Yaakov was complaining about -- many large package suites (like the gnome family, or the kde family) that dlopen modules, explicitly hardcode the ABI numbers of the targets. If we force an ABI bump -- to protect existing clients without a rebuild -- then we force LOTS of patching, in perpetuity, for those large package suites. If we don't do an ABI bump, then we break all client packages until they are rebuilt == flag day. The only clean way out of this mess is "exe's that use static libgcc from gcc3 can always and without fail interoperate with DLLs that use shared libgcc from gcc4". Is that true? ALWAYS and WITHOUT FAIL? (And don't get me started on C++...) -- Chuck
Re: [RFC] ready for cygport to default to gcc4?
cgf wrote: > As one of the maintainers who falls in the sporadically active category > I really don't relish the thought of a flag day version bump. Me neither. I'm STILL struggling to work my way through recompiling "my" packages for cygwin-1.7 *without* any attempts towards gcc4. But the alternatives are also bad, as I mentioned in my reply to Corinna. > I wasn't > paying really close attention but I seem to recall Yaakov mentioning > that other distros didn't require a version bump when moving to gcc4 so > I would rather not do this. And I think I showed that Linux != cygwin in this regard: http://cygwin.com/ml/cygwin-apps/2009-03/msg00038.html Short version: 1) The Linuxes were already all using -shared-libgcc by default. We're transitioning. 2) The Linuxes were already all using DW2 EH (which affects libgcc); We're transitioning. 3) cygwin-gcc3 uses an internal hack to the ABI of libgcc (not libstdc++ or libsupc++) to handle the C++ exceptions-across-DLL-boundaries issue. cygwin-gcc4 does not -- this changes libgcc. So that's another ABI difference, which is going to affect every DLL and EXE compiled with gcc4. 4) C++ only: even though the official gcc C++ ABI did not change between 3.4.x and 4.x (I think), cygwin's absolutely did: cygwin-g++-3 used a patch to address the PR24196 empty-string issue. cygwin-g++-4 uses --enable-fully-dynamic-string. That's a C++ ABI change. Than, of course, there's the dw2/sjlj eh thing, which obviously affects the C++ ABI even more than it does the C ABI. Basically, I believe -- but do not absolutely *know* for sure -- that there are enough ABI-breaking changes in the transition from gcc-3/static-libgcc/sjlj-eh to gcc-4/shared-libgcc/dw2-eh (not to mention a few C++-specific bugaboos) that we *will* discover, somewhere along the way, that some (or many, or all) DLLs built with gcc4 will break old EXEs built with gcc3, unless (a) the DLLs are ABI-bumped, or (b) the EXEs are recompiled. Unfortunately, you can't discover this before the fact. If you don't bump the ABI -- to accommodate Yaakov's concerns about large package suites -- then by the time you discover a problem it's too late. If you revert that DLL edition, and rebuild a ABI-bumped release for it, then you break OTHER apps that WERE rebuilt against the non-version-bumped but now-withdrawn edition of that DLL. > And, as Corinna mentions, it would be very difficult to pull off anyway. Yes, it would be. But we have done it before: when 1.5.0/1/2 was released, and we were moving toward 64bit/largefile support. Granted, the cygwin distribution and # of maintainers is much larger now... -- Chuck
Re: [RFC] ready for cygport to default to gcc4?
On Apr 3 11:30, Charles Wilson wrote: > If I rebuild gettext using gcc4 AND if the switch to gcc4 + shared > libgcc means that there is some sort of breakage (e.g. between a client > that uses the old, static runtime, and this DLL that uses the new, > dynamic runtime) -- then EVERY package that relies on libintl8 just > broke. I'm not sure there is really such a interdependency. Shouldn't the static libgcc3 functions and the new shared gcc4 libgcc functions co-exist and not notice each other? > Unless I bump the ABI number to libintl9. > > But that's exactly what Yaakov was complaining about -- many large > package suites (like the gnome family, or the kde family) that dlopen > modules, explicitly hardcode the ABI numbers of the targets. If we > force an ABI bump -- to protect existing clients without a rebuild -- > then we force LOTS of patching, in perpetuity, for those large package > suites. If we don't do an ABI bump, then we break all client packages > until they are rebuilt == flag day. libintl8-1? > The only clean way out of this mess is "exe's that use static libgcc > from gcc3 can always and without fail interoperate with DLLs that use > shared libgcc from gcc4". > > Is that true? ALWAYS and WITHOUT FAIL? (And don't get me started on > C++...) I understand that there is trouble along the way, but, actually, do we really have a choice? As you write in your other mail, we're in a transition period. We're transitioning in at least two ways, a very new Cygwin and a very new gcc. We will have to drag it along and we can't force other maintainers to do a JIT job. At the very least, if some packages break, the maintainer will probably notice (or be noticed) and provide a new package within a couple of days. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFC] ready for cygport to default to gcc4?
Corinna Vinschen wrote: > I'm not sure there is really such a interdependency. Shouldn't the > static libgcc3 functions and the new shared gcc4 libgcc functions > co-exist and not notice each other? Unless they are supposed to both update the same data structure (e.g. unwinding code) but have different ideas about the contents of that structure. For instance, the exceptions-across-dll-boundaries hack in gcc3 modifies some structure used by libgcc, by adding a field which gcc4's libgcc doesn't know about, IIRC. >>If we don't do an ABI bump, then we break all client packages >> until they are rebuilt == flag day. > > libintl8-1? I'm not sure what you mean by this. libintl8 was my shorthand for the DLL named "cygintl-8.dll". That name is hardcoded in all clients that use the DLL, regardless of the name of the tarball in which the DLL is delivered by the cygwin packaging system. If by libintl8-1 you mean "cygintl-8-1.dll" that's a name change if not, precisely, a version number "bump" -- but it is a DLL name change that requires HEAVY patching to make that happen, esp. with libtool. It's only slightly different than a "typical" ABI bump to e.g. cygintl-9.dll in that it "saves" the cygintl-9.dll "slot" for the next real upstream ABI change. Thus, the "maintain patches in perpetuity" problem goes away...eventually (a year? two?). Not sure if the pain is worth it, though, because now "libintl.dll.a" (basename "intl") and "libintl.a" (basename "intl") are NOT mapped to cygintl-N.dll (basename "intl" + vernum) but instead to "cygintl-8-N.dll" (basename "intl-8" + vernuum). That's a fairly icky "temporary" (a year? two?) patch. Not so bad for gettext/libintl, but unweildy for, say, gtk+. > I understand that there is trouble along the way, but, actually, do we > really have a choice? As you write in your other mail, we're in a > transition period. We're transitioning in at least two ways, a very > new Cygwin and a very new gcc. We will have to drag it along and > we can't force other maintainers to do a JIT job. At the very least, > if some packages break, the maintainer will probably notice (or be > noticed) and provide a new package within a couple of days. So, if I understand correctly, you're (gently) advocating #1) don't bump the ABI number of DLLs just because of cygwin-1.7/gcc4 (of course, if there is some OTHER reason that the ABI changes, then the DLL number SHOULD be bumped). #2) hope that nothing breaks #3) if some app does break, it's up to that app's maintainer to rebuild as needed, NOT the DLL maintainer to ensure backwards compatibility, even though per #1 he has re-used the existing DLL number. #4) BUT no need to coordinate all of these rebuilds -- if any are required -- on some sort of official flag day I could go along with that, with the understanding that this means the official cygwin-1.7 rollout /may/ be a bit more bumpy that we had previously expected. #a) While the more active maintainers are in the process of rebuilding packages (esp. DLL packages) with gcc4 -- whether before the official cygwin-1.7 release or after -- we /may/ see client app breakages. Hopefully, if they occur at all, they will be brief -- and even the less active maintainers will be able to react quickly /enough/ to minimize the disruption per #3. #b) For privately compiled clients of official DLLs whose ABI (may) change due to these transition issues but whose cyg*-N.dll name has not been bumped per #1 above, those private clients /may/ break. And people will complain, and we'll tell 'em to recompile. WJM, after all. -- Chuck
Re: [RFC] ready for cygport to default to gcc4?
On Apr 3 13:54, Charles Wilson wrote: > So, if I understand correctly, you're (gently) advocating > > #1) don't bump the ABI number of DLLs just because of cygwin-1.7/gcc4 > (of course, if there is some OTHER reason that the ABI changes, then the > DLL number SHOULD be bumped). > #2) hope that nothing breaks > #3) if some app does break, it's up to that app's maintainer to rebuild > as needed, NOT the DLL maintainer to ensure backwards compatibility, > even though per #1 he has re-used the existing DLL number. > #4) BUT no need to coordinate all of these rebuilds -- if any are > required -- on some sort of official flag day > > I could go along with that, with the understanding that this means the > official cygwin-1.7 rollout /may/ be a bit more bumpy that we had > previously expected. Yes, the transition to Cygwin 1.7 + gcc-4 might be somewhat rough. But I'm confident that, apart from the usual bugs, we have then done all the really heavy lifting in one single major version bump. > #a) While the more active maintainers are in the process of rebuilding > packages (esp. DLL packages) with gcc4 -- whether before the official > cygwin-1.7 release or after -- we /may/ see client app breakages. > Hopefully, if they occur at all, they will be brief -- and even the less > active maintainers will be able to react quickly /enough/ to minimize > the disruption per #3. > > #b) For privately compiled clients of official DLLs whose ABI (may) > change due to these transition issues but whose cyg*-N.dll name has not > been bumped per #1 above, those private clients /may/ break. And people > will complain, and we'll tell 'em to recompile. WJM, after all. This is a nice summary. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFC] ready for cygport to default to gcc4?
Corinna Vinschen wrote: > On Apr 3 11:30, Charles Wilson wrote: >> If I rebuild gettext using gcc4 AND if the switch to gcc4 + shared >> libgcc means that there is some sort of breakage (e.g. between a client >> that uses the old, static runtime, and this DLL that uses the new, >> dynamic runtime) -- then EVERY package that relies on libintl8 just >> broke. > > I'm not sure there is really such a interdependency. Shouldn't the > static libgcc3 functions and the new shared gcc4 libgcc functions > co-exist and not notice each other? Can't throw and catch exceptions between the two types of code. > I understand that there is trouble along the way, but, actually, do we > really have a choice? As you write in your other mail, we're in a > transition period. We're transitioning in at least two ways, a very > new Cygwin and a very new gcc. We will have to drag it along and > we can't force other maintainers to do a JIT job. At the very least, > if some packages break, the maintainer will probably notice (or be > noticed) and provide a new package within a couple of days. I was wondering what percentage of the repository is sufficiently g-b-s-tastic or cygport-ified to be able to more-or-less automatedly rebuild. cheers, DaveK
Re: [RFC] ready for cygport to default to gcc4?
On Sat, Apr 04, 2009 at 12:49:05AM +0100, Dave Korn wrote: >I was wondering what percentage of the repository is sufficiently >g-b-s-tastic or cygport-ified to be able to more-or-less automatedly >rebuild. What does "automatically rebuilt" mean? Are you saying that one person would rebuild everything? I can't imagine a package maintainer being comfortable with that. I know I wouldn't be. And, I can't imagine anyone volunteering to rebuild scores of packages. cgf
Re: [RFC] ready for cygport to default to gcc4?
Christopher Faylor wrote: > On Sat, Apr 04, 2009 at 12:49:05AM +0100, Dave Korn wrote: >> I was wondering what percentage of the repository is sufficiently >> g-b-s-tastic or cygport-ified to be able to more-or-less automatedly >> rebuild. > > What does "automatically rebuilt" mean? Are you saying that one person > would rebuild everything? No, a _script_ would rebuild everything, or as much of it can be rebuilt by grepping a list of source tarballs out of setup.ini and programatically downloading and unpacking them followed by running either "cygport <.cygport name> all" or ".sh all". (Modulo whatever minor adjustments e.g. build 'almostall' rather than 'all' so that we can run the check target as well). I can't imagine a package maintainer being > comfortable with that. I know I wouldn't be. Well, it's your right to object. I just noticed that one of the links that came up during the previous do-we-don't-we-flag-day thread was to an article describing how one of the big distros handled a similar flag day, and it sounded very much to me like they were running an auto-build server for the whole distro that maintainers just uploaded source package files to. A bit like the cygwin-ports repository. Ah, here it is: "Debian library renaming due to changed libstdc++ configuration" http://lwn.net/Articles/160330/ and that leads me to this article about the Debian "Autobuilder Network": http://www.debian.org/devel/buildd/ Would you be any more comfortable if the suggestion was that we only autorebuilt packages for which the maintainers were seriously AWOL? > And, I can't imagine anyone volunteering to rebuild scores of packages. No; if we decide to try this, it's a machine's work, not a human's! cheers, DaveK
