Re: GCC-4.7.2-2: Go/No-go?
On 17/04/2013 19:59, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:32, Dave Korn wrote: On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote: Your boehm-gc patch can replace my java-libgc-win32.patch, provided it works properly. It appears to, libjava testsuite results are as good as they've ever been, although I don't know whether or not the testsuite checks the invocation API. It's certainly the more complete approach to take than just not supporting the register/unregister methods, as confirmed by the fact that upstream boehm-gc has implemented it for Cygwin. There is a mistake in that patch. The DEBUG_CYGWIN_THREADS conditionals need to be if, not ifdef, as elsewhere in the same source file. Oops, that was a cut'n'paste error when I copied the skeleton of those functions from pthread_support.c, where #ifdef DEBUG_THREADS is the form to use. Thanks for spotting it; fixed in my repo ready for next release. cheers, DaveK
Re: 64bit: cygstdc++-6.dll
On 13/04/2013 11:07, Corinna Vinschen wrote: On Apr 12 21:31, Dave Korn wrote: Nope, just vague about input and output sections. Enabling auto imports selects a linker script that causes all the .rdata in the input object files Out of curiosity, which linker script is that? What's the difference to the normal one? Well, since auto import became the default, it is the normal one, but that aside, they're both built-in scripts. Compare the output from ld --disable-auto-import --verbose and ld --verbose to see the difference. Or you can look at the copies that ld installs into /usr/i686-pc-cygwin/lib/ldscripts/; the .x file is the plain one, the .xa is the auto-import one. to be placed in the plain old .data section of the output executable, so that it will be RW-mapped when loaded. Apparently the Windows runtime loader can't deal with updating import references into RO-mapped pages. The consequence of that is that all the pages with import references get modified and COWed on load and so it reduces the amount of the mapped memory that can be shared between instances of the same executable. I'm a bit puzzled in terms of the additional R/W space this amounts to. When loading an executable, there is the entire IAT which has to be modified by the loader, anyway. That includes all functions and data imported from other DLLs. To what extent do the auto-import entries add to that? If it's just another indirection, that would add 5 bytes (absolute jmp) on i686, and 8 bytes (an absolute address in a pseudo-GOT table) on x86_64 per auto-imported symbol. That's not a lot, probably not even a 4K page per executable. How significant is that? But it's not a separate contiguous list of pointers. What's happening is that there are various structures in the .rdata that contain imported pointers. They'll be scattered throughout the .rdata, along with all the other const data that /doesn't/ have pointers that have to be auto-imported. So depending on the percentages and how it happens to end up in the link order, it could be any or all of the .rdata pages that get COWed on startup. I'm not sure how significant this is in general usage, and I'm generally in agreement that removing auto-import would be a significant hassle. That, too. Yeah. So I guess we have to live with it. However it's probably still worth having the markers in libstdc headers, because that at least makes it possible for people to write applications and disable auto imports if they're only using libstdc (and/or other shared libs that also have markers in their headers). That would be desirable for something that you're going to want to spawn many instances of (either consecutively or concurrently). cheers, DaveK
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 13/04/2013 15:49, Corinna Vinschen wrote: On Apr 13 12:39, Andy Koppe wrote: On 13 April 2013 10:03, Corinna Vinschen wrote: On Apr 13 06:55, Andy Koppe wrote: I'm struggling to get setup.hint generation to work. Is it supported with cygport 0.11.3 as currently in the distros? Below is the mintty.cygport I've got. Do I need to do anything else to trigger it? Cygport prints mintty requires: at the end, which is correct as it doesn't require anything beyond the Cygwin DLL, but there's no setup.hint. Sure? Did you look into the dist subdir in your builddir after the install stage? It should contain a complete mintty dir for upload. You're right, there is, inside the working directory created by cygport, and it looks correct. I'd expected the setup.hint to appear next to the .cygport and the packaged .tar.bz2 files. IIU Yaakov C, the dist dir is the way to go in future. The toplevel files is the old style, supposed to go away at one point. I like the dist dir approach a lot. Glad to hear that. I also much prefer the dist dir to plonking all the files in the toplevel with no directory structure. It's much simpler for uploading. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 11/04/2013 21:42, Thomas Wolff wrote: Am 11.04.2013 14:34, schrieb Dave Korn: Also, I don't plan on doing it unless there's significant demand. I would appreciate to keep it as gcc-3. Fancy being the maintainer for it then? ;-) The reason is quite peculiar; gcc-4 changed the order of variables in the stack frame of a function call, which led to one very specific interworking malfunction (between mintty and mined) which in turn unveiled a very subtle bug. This is material for very interesting debugging exercises for students... Not sure whether it's significant but the changed variable order might in fact affect other software as well. -- Thomas Only seriously buggy software. Anything in a C program that attempts to make inferences about the layout of the stack frame is invoking undefined behaviour. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 12/04/2013 11:44, Yaakov (Cygwin/X) wrote: On 2013-04-11 23:24, Dave Korn wrote: Most of the discussed features are already in the latest release. Right now, the major difference between the release and git master is full support for x86_64-pc-cygwin, but there are a number of other bugfixes and enhancements. I hope to cut a release from master as early as next week. (Also, what is the unversioned file format?) Where the file is named foo.cygport and NAME/VERSION/RELEASE are defined inside of the cygport(5) instead of deriving these from the filename as before. My gcc.cygport is an example of this, as well as the use of setup.hint generation. Great, then I'll take full advantage of the new stuff. Huh? Cygport doesn't own CC any more than autotools if it's not being used. CC is a user variable. It belongs to make, and the make info page in the section on Makefile Conventions says that the user can substitute alternatives. Maintainers aren't the only people who use the compiler! *Within the scope of cygport*, cygport(1) is the user and it controls CC based on a number of factors. [ ... ] Saying CC=gcc-4 obviously doesn't work in all those scenarios. Well, yes, but we're talking here about whether I should leave a symlink called gcc-4.exe in /usr/bin for the benefit of any end users who might have makefiles (or other scripts) that aren't in any way related to cygport at all, so none of that is relevant. You still haven't explained exactly what the problem is. You don't need libgcj on the system in order to build a native gcc with java. Why would the presence or lack of libgcj*.la make a difference? Ah, that's where our misunderstanding is. It's the presence of libstdc++.la that is required for libjava to build, not libgcj.la. [ ... ] Oh, now I get it. What *really* happened is that last time you tried this, you still had GNOME .la files on your system, some of which contained references to libstdc++.la because of the then-embedded copy of harfbuzz in the Pango libraries. So when you installed an .la-less gcc then rebuilt gcc, the link failed because of the remaining libstdc++.la references in libgtkpeer's many (sub)deps; the same would have happened building *any* GTK+/GNOME package with libtool. This would have worked even then if you had run the fix-libtool-scripts-for-latest-gcc-runtimes.sh script with my modifications thereto (Ports gcc commit 00c6f36) immediately after installing the .la-less gcc. In any case, the current versions of the GNOME libraries do not include .la files, so you won't have this problem with rebuilding gcc. (You should still run the modified script in any case.) Ah, thanks for the explanation. That makes sense to me. Don't get me wrong, libtool is still the best option for building libraries portably, but it does not need .la files on the system to do so with shared libraries. Now that we've figured out what the problem really was, and that it doesn't exist anymore, could we drop them from the next release? Absolutely, assuming nothing goes wrong when I test it. I should still package the updated version of fix-libtool-scripts-for-latest-gcc-runtimes.sh and invoke it postinstall for the benefit of any other .la files that are still on the system, right? cheers, DaveK
Re: 64bit: cygstdc++-6.dll
On 12/04/2013 16:57, Corinna Vinschen wrote: Dave? Ping? Heh, don't panic, I'm still here! Just needed some sleep :) On Apr 11 15:37, Corinna Vinschen wrote: On Apr 11 12:16, Corinna Vinschen wrote: On Apr 10 18:16, Corinna Vinschen wrote: On Apr 10 16:49, Dave Korn wrote: On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote: Could you explain the necessity of the dllimport's in the same patch? The idea is to one day be able to move away from having auto-import enabled by default in binutils, so that .rdata can go back into the read-only-mapped .rdata section and be shared between processes as it ought. Doesn't that affect applications which use something like extern int optind; in their code? Kai did quite a job to get this working on x86_64 by implementing the medium/large code models for x86_64, and Cygwin's x86_64 gcc uses the medium code model by default. Disabling this again would be rather counterproductive. What about this issue? If the idea is to revert all automatism which allows to declare external variables in DLL s without dllimport, then I don't think that's a good idea for Cygwin. If I misunderstand the issue, please say so. Oh, and, btw., I don't quite understand so that .rdata can go back into the read-only-mapped .rdata section Typo? Nope, just vague about input and output sections. Enabling auto imports selects a linker script that causes all the .rdata in the input object files to be placed in the plain old .data section of the output executable, so that it will be RW-mapped when loaded. Apparently the Windows runtime loader can't deal with updating import references into RO-mapped pages. The consequence of that is that all the pages with import references get modified and COWed on load and so it reduces the amount of the mapped memory that can be shared between instances of the same executable. I'm not sure how significant this is in general usage, and I'm generally in agreement that removing auto-import would be a significant hassle. I think it might explain why, when I'm running the GCC testsuite and have been through a few tens of thousands of compiles, I frequently see a whole bunch of gcc.exe instances just sitting there, doing nothing and using almost no CPU for 20 to 30 seconds while their stack traces indicate they're stuck in kernel paging-and-caching-related code. But overall, I guess we have to live with it. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 11/04/2013 03:23, Yaakov (Cygwin/X) wrote: On 2013-04-10 11:56, Dave Korn wrote: It takes 11 hours on a triple-core machine at -j6 to build and package GCC. In order to guarantee consistent reproduction I always respin the built package from -src package through two generations. It then takes three to five days to run enough of the testsuite to be confident that the packaged compiler works well. So it'd be next week at the earliest. While your diligence is admirable, I think some common sense review can be used here, as only one of my patches actually affects the compiler itself, and even then only the specs. I'm not exactly messing around with code generation here. Yes, I've looked at most of your patches already, I'm not saying there's any complication in adding them, it's just that I didn't want to wait another howevermany days before getting 4.7.2-2 out there. I'll put them all into the next release, which I'll get on with pronto. BTW, in your absence, it was agreed that gcc3 should go away and that gcc4 should be *the* gcc in the distro. This will simplify the build and drop the dep on 'alternatives'. Can this get into the next release? Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was using it and wants to know where it's gone. (I suppose if that happens I could always consider rolling a gcc3 package with all -3 suffixed executables.) I'll need to make sure not to lose the cc.exe - gcc.exe symlink, and it might be useful for backward-compatibility to provide a bunch of -4 suffixed links to the other executables for people who've written CC=gcc-4 in their Makefiles, but that can be done with just ln rather than using alternatives. I don't understand why there's a libquadmath0-devel; like the other C libraries, this should just be part of gcc-core. Hmm. I got the impression that libquadmath could stand alone, i.e. be useful in a non-GCC context, but I guess not or it would be installing its include files into /usr/include rather than the GCC private include dir. I'll merge it into gcc-core in the next release as you suggest. This was only necessary for libstdc++, and only so long as .la files were included. IIRC we agreed to remove them, but your reason for not doing so in the .cygport isn't clear to me. Without the .la files, libjava doesn't build. And in general I don't want to second-guess the compiler: since the upstream makefiles think it's important to install them, so do I. Also, could you please explain the reasons for the ehdebug, execstack, and shared-libgcc patches? ehdebug: When we first switched from sjlj to dw2 exceptions, there were so many corner case bugs that kept cropping up across multiple releases that I wanted to hang onto the debugging code. During development the debugging output was under control of a variable that I replaced by a #define 0 just before the release. It's obsolete now, I'll drop it, but it was incredibly useful for the first few gcc4 releases. execstack: Trampolines need an executable stack. DEP on recent Windows OSs marks the stack non-executable; this option allows the stack to be set executable during the runtime startup, without having to disable DEP for the entire process. Think I may have inherited it from Danny Smith. Mingw has it upstream, I'll get it committed there for Cygwin too. shared-libgcc: Makes linking against shared libgcc the default for all executables; previously it was only on by default for DLLs. Vital for importing TLS variables from DLLs, upstream since 4.8.0. cheers, DaveK
Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj
On 11/04/2013 05:47, Christopher Faylor wrote: On Thu, Apr 11, 2013 at 02:21:00AM +0100, Dave Korn wrote: On 11/04/2013 02:05, Dave Korn wrote: On 11/04/2013 01:18, Christopher Faylor wrote: gcc won't be available until this is fixed. Oops. I'll just edit it on the server. Sorry for the inconvenience. Should be ok now I trust. Apologies once more, I've updated my local hint file in svn to prevent it happening again. No problem. Your fix is confirmed. Thanks for the quick response. cgf Being a confirmed cynic^W^Wexperienced programmer, I always like to stay online for a while after committing or releasing something, in case of any aftermath. cheers, DaveK
Re: [ITP] libffi (attn: Dave Korn)
On 11/04/2013 03:44, Yaakov (Cygwin/X) wrote: On 2013-04-10 20:40, Dave Korn wrote: Surely there'll be a problem if the curr: version of everything else goes to 4.7.3-1 but there's no matching version of libffi4? Not as long as 4.5.3-3-src remains. Well, there have been some bugfixes in gcc/libffi upstream, so as long as anyone out there might conceivably have some homebrew app that they've linked against libffi4, I'd like to do them the favour of giving them a final updated version to live with until they get round to rebuilding against libffi6. It's no skin off my (or anyone else's) nose as far as I can see. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 11/04/2013 11:13, Corinna Vinschen wrote: On Apr 11 01:58, Yaakov (Cygwin/X) wrote: On 2013-04-11 01:02, Dave Korn wrote: Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was using it and wants to know where it's gone. (I suppose if that happens I could always consider rolling a gcc3 package with all -3 suffixed executables.) 3.4 is EOL and should have been dropped long ago; we simply don't have the resources to support it ourselves. Just about any software that people are building today either works with recent 4.x or the distros have a patch for it. FWIW, I agree. AOL-Corinna I said I could consider it, I didn't say I was necessarily going to do it :) Still, you'd be surprised the number of questions I see on random websites (stackoverflow, linuxquestions and similar) where someone's asking how to install an old GCC to build some old software. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 11/04/2013 13:22, NightStrike wrote: Speaking of which.. 4.8 is out... Point. Anyone got any particular preference whether I go for a 4.7.3 or 4.8.0 release next? Maybe do a 4.7.3 curr: and then a 4.8.0 test: package? cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 12/04/2013 00:36, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:35, Dave Korn wrote: On 11/04/2013 13:22, NightStrike wrote: Speaking of which.. 4.8 is out... So is GNOME 3.8.0, but I tend to let others deal with the early bugs and catch up by .1 or even .2. Point. Anyone got any particular preference whether I go for a 4.7.3 or 4.8.0 release next? Maybe do a 4.7.3 curr: and then a 4.8.0 test: package? For the same reason, I'd go with 4.7.3 first. But let's not wait until 4.9 to update GCC again this time, okay? :-) Yeh, promise! cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 12/04/2013 00:28, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:32, Dave Korn wrote: On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote: Also in the 4.8 branch is a patch to unversion the LTO plugin; it applies to 4.7 as well. I'll take a look for that. Does it really matter? I don't suppose we need support swapping LTO plugins between different versions of the compiler, it's totally a for-internal-use-only thing. Does it really, *really* matter? Perhaps not, but IMO it's the proper thing to do for all arches, since the LTO plugin is just that, a plugin. (If Apple were to still use GCC, it *would* matter, as there are fundamental differences between Mach-O dylibs and bundles.) Well, maybe I'll just wait until I get to a 4.8 release naturally and let it happen then. Or maybe I'll backport the patch for 4.7.3. I'll see how I feel at the time, since it's not /critical/ and I'd like to prioritise. Something else you missed: cygport supports a new, unversioned file format, and creates setup.hint files, including dependency detection. I suggest using git master right now. Wouldn't that mean that the -src package I ship won't rebuild with the version from the standard distribution? I usually recommend using cygport git master, and a number of maintainers track it. I want to ship packages that the general public can rebuild using the standard distro really. Do you have any idea of a schedule for releasing these features? (Also, what is the unversioned file format?) That was never right, CC isn't supposed to be (ab)used like that. I don't mind not supporting that going forward. Well it's not exactly any trouble so I may as well do it. If you're not using autotools, CC is yours to do what you like with isn't it? No, it's not. In the cygport manual, [Definitions] should be treated as readonly, and [Variables] can be altered. Huh? Cygport doesn't own CC any more than autotools if it's not being used. CC is a user variable. It belongs to make, and the make info page in the section on Makefile Conventions says that the user can substitute alternatives. Maintainers aren't the only people who use the compiler! How could removing the .la files during postinstall affect building libjava beforehand? Heh, of course not, I'm not suggesting time travel! I should have said *re*build: without the .la files installed on the user's system, the -src package fails to rebuild. I imagine (but didn't test) that applies to building plain upstream SVN/tarball as well. You still haven't explained exactly what the problem is. You don't need libgcj on the system in order to build a native gcc with java. Why would the presence or lack of libgcj*.la make a difference? Ah, that's where our misunderstanding is. It's the presence of libstdc++.la that is required for libjava to build, not libgcj.la. That's because of a failure during linking (the awt peer IIRC) when libtool can't locate libstdc to link against. That in turn happens because it uses gcc.exe to link, not g++.exe, and that in turn happens because libtool is invoked with the CC tag, not CXX, and that in turn happens because the module is composed entirely of .c files and does not have any .cc files to trigger libtool's language detection to know that C++ is required. As for the makefiles installing the .la files, upstream isn't choosing to do so, that's just how libtool works. Some Linux distros, including Fedora, have been removing them from all binary packages (except when they are needed by lt_dlopen() and friends), and for very good reason. What's the very good reason? Because they cause more trouble than they're worth, e.g. necessitating hacks such as fix-libtool-scripts-for-latest-gcc-runtimes.sh. This is a good summary of some of the issues: https://lists.fedoraproject.org/pipermail/mingw/2012-January/004421.html Hmm. I need to digest that some more. I'm not entirely certain that it applies to the compiler runtime libs, because people often do use static linking against them when they want to make standalone executables. shared-libgcc: Makes linking against shared libgcc the default for all executables; previously it was only on by default for DLLs. Vital for importing TLS variables from DLLs, upstream since 4.8.0. Here we go again... Huh? We started with 4.3 using the static libgcc by default, then switched to linking everything with -lgcc_s, then with 4.5 switched to doing so by default only for DLLs (to minimize rebase errors iirc), and now we're going back to shared across-the-board. I'm not complaining, and it seems like the right thing to do, but it does evoke a sense of deja vu. Ah, I didn't remember that we'd taken a step back at one point during the process, I thought it had been a linear progression but that does ring a bell. Well, I'm sure now that it was the wrong way to try and solve the rebase problems, it's seriously
Re: 64bit: cygstdc++-6.dll
On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote: Could you explain the necessity of the dllimport's in the same patch? The idea is to one day be able to move away from having auto-import enabled by default in binutils, so that .rdata can go back into the read-only-mapped .rdata section and be shared between processes as it ought. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 10/04/2013 16:47, Christopher Faylor wrote: It isn't clear to me why we'd be spending days discussing this when presumably the patches apply without too much effort. Some of the patches here: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc look worthwhile to me. If we're talking about only gcc 4.7 fixes then it looks like we're only talking about five patches, none of them are to source files, and none of them are very big. It takes 11 hours on a triple-core machine at -j6 to build and package GCC. In order to guarantee consistent reproduction I always respin the built package from -src package through two generations. It then takes three to five days to run enough of the testsuite to be confident that the packaged compiler works well. So it'd be next week at the earliest. Hence I'm uploading 4.7.2-2 now. cheers, DaveK
Re: [ITP] libffi (attn: Dave Korn)
On 10/04/2013 10:50, Yaakov (Cygwin/X) wrote: On 2013-04-10 04:29, Corinna Vinschen wrote: On Apr 10 04:06, Yaakov (Cygwin/X) wrote: libffi development moved out of GCC into a separate project a long time ago; the copy included in GCC is used for libgcj, but only as a convenience (static) library, and it is usually a few point releases behind the standalone version. Finally, last month, GCC was patched upstream to stop installing its copy (a similar patch for 4.7.2 and 4.8.0 is in Ports git). Therefore I think the time has arrived to join Fedora and Debian and switch i686 to the standalone version. (We are already using this for x86_64.) This will also simplify building many of the ~20 packages which use libffi and expect the .pc file provided only by the standalone version. http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libffi ftp://ftp.cygwinports.org/pub/cygwinports/temp/libffi/ Isn't that independent from what gcc itself does? If so, feel free to upload. Only the man3 pages collide with gcc4-core. But gcc's libffi.dll.a will take priority over the one in /usr/lib (see gcc -print-search-dirs), so manual intervention will be necessary until our gcc stops shipping libffi. Okeydokey. Upstream libffi generates cygffi-6.dll, so what I'll do is incorporate the patch (along with your others) into 4.7.3-1 (which will be a full curr: version release), and ship one last version of libffi4 (marked obsolete) with that but make sure the man pages, static import lib etc (-devel stuff basically) is not packaged. That'll probably be in ten days or so, at which point you can upload the standalone libffi. Makes sense? cheers, DaveK
Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj
On 11/04/2013 01:18, Christopher Faylor wrote: gcc won't be available until this is fixed. Oops. I'll just edit it on the server. Sorry for the inconvenience. cheers, DaveK
Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj
On 11/04/2013 02:05, Dave Korn wrote: On 11/04/2013 01:18, Christopher Faylor wrote: gcc won't be available until this is fixed. Oops. I'll just edit it on the server. Sorry for the inconvenience. Should be ok now I trust. Apologies once more, I've updated my local hint file in svn to prevent it happening again. cheers, DaveK
Re: [ITP] libffi (attn: Dave Korn)
On 11/04/2013 02:33, Yaakov (Cygwin/X) wrote: After applying my libffi-noinst.patch, all you really need to do is remove the libffi4-4.7.* test releases and leave 4.5.3-3 in the distro until all libffi-dependent packages are rebuilt (most of which are mine). Surely there'll be a problem if the curr: version of everything else goes to 4.7.3-1 but there's no matching version of libffi4? cheers, DaveK
Re: 64bit: cygstdc++-6.dll
On 25/03/2013 08:52, Corinna Vinschen wrote: On Mar 24 03:33, Yaakov (Cygwin/X) wrote: In any case, the error is a result of adding one of Dave Korn's patches: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=blob;f=4.7-libstdc-dllimport.patch;hb=refs/heads/4.8#l29 I have omitted that patch in the new 4.8.0-1. Hopefully Dave can explain the purpose and necessity of that patch, since it would seem that using (at least that hunk of) it would require rebuilding most C++ packages in 64bit/release; if it's really necessary, then we will want to do that sooner rather than later. I believe the patch is no longer necessary. I added it originally after a discussion about the implications of exporting typeinfo from DLLs with Danny Smith in the GCC bugzilla; he was of opinion that there might be incomplete typeinfos that could not be fully resolved until final link-time of an application, so the purpose of this patch was to place typeinfo objects into the cygstdc++.dll.a rather than in the DLL itself. The idea being that every app that linked against the DLL would get a copy of the still-relocatable typeinfo object files from the import library during its own final link. I'm now convinced that Danny was needlessly worried. The cxx-abi does refer to this situation, in section 2.9.1: bNOTE/b: Note that the full structure described by an RTTI descriptor may include incomplete types not required by the Standard to be completed, although not in contexts where it would cause ambiguity. Therefore, any cross-references within the RTTI to types not known to be complete must be weak symbol references. But I don't think this applies to any of the built-in types in libstdc, so I think it's safe to include their typeinfo in the DLL and export it. That I don't quite understand either. If this is only about missing exported symbols and not about the name, how are the already built C++ packages affected? They could be built, so they didn't use this symbols, apparently. Removing the patch should generate a backwardly-compatible DLL. Existing applications already linked against the DLLs will have their own copies of the typeinfo objects pulled in from the import library, so it won't matter that the newer DLL also exports such a name (note that we compare typeinfos by name string under Cygwin, rather than by pointer equivalence.) New applications linking against the new DLL will simply pull in an import table reference rather than the entire typeinfo object file. The backward incompatibility came from adding the patch after previously having released a version of the DLL without the patch which therefore had all the typeinfos exported, as the applications linked against the previous version of the DLL would still expect the typeinfo imports to be available, but now the typeinfos would only be available as objects in the import library. In short: it was a precautionary measure, it's now superfluous. I'll remove it from the next full release of 32-bit GCC as well. cheers, DaveK
Re: 64bit: cygstdc++-6.dll
On 09/04/2013 11:30, Yaakov (Cygwin/X) wrote: On 2013-04-09 02:08, Dave Korn wrote: On 25/03/2013 08:52, Corinna Vinschen wrote: On Mar 24 03:33, Yaakov (Cygwin/X) wrote: In any case, the error is a result of adding one of Dave Korn's patches: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=blob;f=4.7-libstdc-dllimport.patch;hb=refs/heads/4.8#l29 I have omitted that patch in the new 4.8.0-1. Hopefully Dave can explain the purpose and necessity of that patch, since it would seem that using (at least that hunk of) it would require rebuilding most C++ packages in 64bit/release; if it's really necessary, then we will want to do that sooner rather than later. I believe the patch is no longer necessary. Does that apply to the entire dllimport patch or just that hunk? Just the hunk with the --exclude-modules-for-implib. cheers, DaveK
GCC-4.7.2-2: Go/No-go?
Hi all, I have a release of 4.7.2-2 ready to upload. It fixes the dependencies back to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs work and restores java and libffi. I've also been running the testsuite over the last few days and the results look quite reasonable. Yaakov thinks (http://cygwin.com/ml/cygwin-apps/2013-04/msg00032.html) that I shouldn't release it until I've integrated all his patches. I think (http://cygwin.com/ml/cygwin-apps/2013-04/msg00057.html) that it's worth uploading as a stop-gap to address the mentioned problems and integrating Yaakov's patches for the next release. Could the list please help us make a decision? cheers, DaveK
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 04/04/2013 10:13, Yaakov (Cygwin/X) wrote: On Sun, 31 Mar 2013 19:57:09 +0100, Dave Korn wrote: And the reroll failed to build because of the problem JonY ran into with java. Turns out that libjava keys off the presence of pthread_getattr_np (added to the DLL a few versions ago) to decide whether to invoke a couple of boehm-gc functions that only existed in pthread versions, so weren't implemented for win32 threads as used by the Cygwin port. I've added a patch that implements them and am starting again. As mentioned previously, I already fixed that in Ports: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc PLEASE use this as the basis for your packages; there are a number of important fixes in that patchset. Well, I was just going to do a quick update to 4.7.1-1, still as a test: version, in order to a) fix the dependencies and b) get exported TLS vars working, and then integrate all your extra patches before doing the first full curr: release. Is that not a good idea? b) in particular was important for getting new versions of mpfr to work without having to disable thread support. cheers, DaveK
Re: [ITA] mpfr (libmpfr-devel / libmpfr4)
On 02/04/2013 16:27, Achim Gratz wrote: I've added test packages compiled with gcc-4.7.2-1 (to be installed by manually selecting them, like the test version of gcc itself): wget=wget -xnH --cut-dirs=1 http://cygwin.stromeko.net/release; Is there some access permission I would need to take a look at those? $ wget -xnH --cut-dirs=1 http://cygwin.stromeko.net/release --2013-04-05 18:16:13-- http://cygwin.stromeko.net/release Resolving cygwin.stromeko.net (cygwin.stromeko.net)... 212.90.148.102 Connecting to cygwin.stromeko.net (cygwin.stromeko.net)|212.90.148.102|:80... co nnected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://cygwin.stromeko.net/release/ [following] --2013-04-05 18:16:15-- http://cygwin.stromeko.net/release/ Connecting to cygwin.stromeko.net (cygwin.stromeko.net)|212.90.148.102|:80... co nnected. HTTP request sent, awaiting response... 403 Forbidden 2013-04-05 18:16:16 ERROR 403: Forbidden. cheers, DaveK
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 05/04/2013 18:07, Dave Korn wrote: On 04/04/2013 10:13, Yaakov (Cygwin/X) wrote: On Sun, 31 Mar 2013 19:57:09 +0100, Dave Korn wrote: And the reroll failed to build because of the problem JonY ran into with java. Turns out that libjava keys off the presence of pthread_getattr_np (added to the DLL a few versions ago) to decide whether to invoke a couple of boehm-gc functions that only existed in pthread versions, so weren't implemented for win32 threads as used by the Cygwin port. I've added a patch that implements them and am starting again. As mentioned previously, I already fixed that in Ports: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc PLEASE use this as the basis for your packages; there are a number of important fixes in that patchset. Well, I was just going to do a quick update to 4.7.1-1, still as a test: version, in order to a) fix the dependencies and b) get exported TLS vars working, and then integrate all your extra patches before doing the first full curr: release. Is that not a good idea? b) in particular was important for getting new versions of mpfr to work without having to disable thread support. Also, c) I have a fixed libffi package to go with it, which would resolve the problems mentioned by Angelo G. in http://cygwin.com/ml/cygwin/2013-04/threads.html#00081 I really think it's worth uploading as a stop-gap. cheers, DaveK
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 28/03/2013 15:18, Dave Korn wrote: On 28/03/2013 14:05, Dave Korn wrote: Righto. Will upload as soon as I've finished running setup ;) Argh. Gotta re-roll the packaging step as I forgot to commit some of the setup.hint reversions to my local svn. D'oh, but at least I spotted it before uploading. And the reroll failed to build because of the problem JonY ran into with java. Turns out that libjava keys off the presence of pthread_getattr_np (added to the DLL a few versions ago) to decide whether to invoke a couple of boehm-gc functions that only existed in pthread versions, so weren't implemented for win32 threads as used by the Cygwin port. I've added a patch that implements them and am starting again. cheers, DaveK
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 26/03/2013 11:20, Corinna Vinschen wrote: Hi Dave, On Mar 12 23:50, Dave Korn wrote: On 12/03/2013 22:15, Achim Gratz wrote: Achim Gratz writes: Yaakov (Cygwin/X) writes: OK. I won't be able to run the tests for some packages this way, but it sounds like this should provide a workable solution for bootstrapping. I guess we will anyway have to re-compile all packages with gcc47 when it is ready for release, right? Fascinatingly the tests for libmpc do run, although ldd gets confused about what libraries it depends on and stops midway after outputting a dependence on ?. If the second gcc47 test release is made within this week I'd prefer that to roll the packages, otherwise I'll set up a second installation with the current release. I'll put all packages for the gcc47 branch into [test], like gcc itself, is that correct? I haven't yet had an explicit go-ahead for that -2 release, but I've been rerolling it with the mpfr (shared libgcc) fix in order to be ready. Gonna check the same fix into upstream trunk tonight as well. How's the state of affairs? I've realised that I should re-roll the release after updating to the latest cygport, as I don't yet have the version with the debuginfo changes, which I assume are desirable? If that's not so important, I could upload the existing build today and then re-roll a -3 with debuginfo, does anyone prefer it one way or the other? cheers, DaveK
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 28/03/2013 13:39, Corinna Vinschen wrote: On Mar 28 13:25, Dave Korn wrote: I've realised that I should re-roll the release after updating to the latest cygport, as I don't yet have the version with the debuginfo changes, which I assume are desirable? Just run setup ;) If that's not so important, I could upload the existing build today and then re-roll a -3 with debuginfo, does anyone prefer it one way or the other? I'd be fine with a -2 without debuginfo for now. Righto. Will upload as soon as I've finished running setup ;) cheers, DaveK
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 28/03/2013 14:05, Dave Korn wrote: Righto. Will upload as soon as I've finished running setup ;) Argh. Gotta re-roll the packaging step as I forgot to commit some of the setup.hint reversions to my local svn. D'oh, but at least I spotted it before uploading. cheers, DaveK
Re: [PATCH] setup: port to 64-bit, part 1
On 04/03/2013 06:31, Christopher Faylor wrote: On Sun, Mar 03, 2013 at 09:54:58PM -0600, Yaakov wrote: Based on your recent commit to cygwin-64bit-branch, are we dropping support for Win2K as well? Yes. :-( Gonna have to set up a new dev environment on a new pc cheers, DaveK
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 12/03/2013 22:15, Achim Gratz wrote: Achim Gratz writes: Yaakov (Cygwin/X) writes: OK. I won't be able to run the tests for some packages this way, but it sounds like this should provide a workable solution for bootstrapping. I guess we will anyway have to re-compile all packages with gcc47 when it is ready for release, right? Fascinatingly the tests for libmpc do run, although ldd gets confused about what libraries it depends on and stops midway after outputting a dependence on ?. If the second gcc47 test release is made within this week I'd prefer that to roll the packages, otherwise I'll set up a second installation with the current release. I'll put all packages for the gcc47 branch into [test], like gcc itself, is that correct? I haven't yet had an explicit go-ahead for that -2 release, but I've been rerolling it with the mpfr (shared libgcc) fix in order to be ready. Gonna check the same fix into upstream trunk tonight as well. cheers, DaveK
Re: GCC 4.7 and dependencies
On 11/03/2013 23:40, Yaakov (Cygwin/X) wrote: JonY, Achim, and others, I have updated .cygport and patch files for GCC and its dependencies: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc I'm trying to look at this, but all I get is errors: $ git clone git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/gcc4 Cloning into gcc4... fatal: The remote end hung up unexpectedly $ Is there something wrong with the format of the git: URL I'm using? cheers, DaveK
Re: [ITA] mpfr (libmpfr-devel / libmpfr4)
On 10/03/2013 15:43, Achim Gratz wrote: - TLS disabled since it doesn't work with current gcc I just debugged that over on the mpfr list. It can be made to work by adding LDFLAGS=-shared-libgcc to your configure line. (I'm going to patch upstream GCC to make that the default, and I'm also rolling a 4.7.2-2 with that patch included.) cheers, DaveK
Changing dependent library version numbers vs. test packages vs. requires: lines.
Hi all, I've got a gcc-4.7.2 package almost ready to upload, but there's one issue I'm not sure what's best to do about. Several of the runtime libs have changed version numbers, i.e. libgnat4.5-libgnat4.7, libgcj11-libgcj13, libobjc2-libobjc4. I'd like to release a test: version of the new compiler, but I don't know what's best to do for the requires: lines in the setup hint files. If I add the new library versions, those dependencies will also be pulled in by people installing the curr: version of the compiler, but the new libraries won't exist in curr: versions. If I don't, people installing the test: version will have to ensure they manually select the new runtime libraries, which might be the least worst option. Is there any better way to handle this situation? cheers, DaveK
Re: Mingw64 and Cygwin: header and libs layout
On 13/03/2012 10:10, Corinna Vinschen wrote:
For the time being, I'm using the -idirafter flag to include the Mingw64
headers into the search path, but that's IMHO not a generic solution for
a (yet to create) Cygwin 64 bit GCC.
The generic solution for the future cygwin64-targeted GCC will of course be
to not refer to the mingw64 headers at all!
On 13/03/2012 13:51, Christopher Faylor wrote:
On Tue, Mar 13, 2012 at 02:36:21PM +0100, Corinna Vinschen wrote:
On Mar 13 14:25, Kai Tietz wrote:
I suggest the approach to install for cygwin the platform-headers to a
shared place. I suggest that mingw-w64 adds to configure for headers
and crt an option, which installs platform-headers/libraries to
'/usr/shared/psdk_windows' location. Means under this path are the
folders lib/lib64/include containing only the platform-parts.
That sounds like an excellent idea to me!
For the cygwin-based mingw-w64 cross-compiler we need to add here by
spec (for headers in gcc and for libs in binutils or gcc). IMHO this
should be a special configuration option for gcc (and binutils), which
adds the required parts to spec-files.
IMHO we should keep the w32api scheme. The reason is that this
requires no changes at all to the gcc specs file. Rather, the Cygwin
gcc package would simply create matching symlinks:
ln -s /usr/share/windows_psdk/include /usr/include/w32api
ln -s /usr/share/windows_psdk/lib /usr/lib/w32api
ln -s /usr/share/windows_psdk/lib64 /usr/lib64/w32api
I think it's pretty unusual to install libraries and headers in
/usr/share, particularly in the case of libraries. gcc/linux has
conventions for this type of thing. I broke them when I installed
headers and libraries in /usr/include/w32api. I don't think we should
stray further by putting things in /usr/share.
Could Dave Korn weigh in on this?
I'd find it a bit odd as well, but can't really think of an actual problem,
it just gives me a mild bit of cognitive dissonance. It's an unusual
situation to want to share a set of headers but not the corresponding libs,
and doesn't work well with the standard $prefix/{lib,include} pattern. The
headers for w32api aren't huge in terms of disk space (5.5M), so just having
duplicates in the appropriate places wouldn't be that bad. It's what happens
every time you build libwhatever for both your native system and a
cross-target anyway.
Is there ever any likelihood that the w32api team might want to implement
autoconfigury-based customisations to the installed headers based on the
detected properties of the host platform (n.b. using 'host' in the library
sense, i.e. the same as 'target' for the compiler)? Sharing them between the
two compilers would lock that out.
(BTW, I noticed that gcc 4.7.0 was released, so I'll try and get a test
package up over the next fortnight or so).
cheers,
DaveK
Re: Mingw64 and Cygwin: header and libs layout
On 24/03/2012 19:19, Corinna Vinschen wrote:
On Mar 24 18:12, Dave Korn wrote:
On 13/03/2012 10:10, Corinna Vinschen wrote:
For the time being, I'm using the -idirafter flag to include the Mingw64
headers into the search path, but that's IMHO not a generic solution for
a (yet to create) Cygwin 64 bit GCC.
The generic solution for the future cygwin64-targeted GCC will of course be
to not refer to the mingw64 headers at all!
Huh?
Just like the current i686-pc-cygwin-gcc does not refer to mingw32 headers,
a future theoretical x86_86-pc-cygwin64-gcc will not refer to mingw64 headers,
because we'll have a proper native compiler rather than having to rely on a
cross-compiler that is almost - but not quite - correct.
Sorry, but I don't understand what you mean. Of course we would like
to share headers *and* libs. See above.
OK, then I clearly don't understand what you mean. Didn't this thread start
with you pointing out that, although the same headers were valid for cygwin or
mingw, the startup crt .o files and libs weren't right? How can the cygwin .o
files possibly be compatible with the mingw ones?
The include files are the
same for 32 and 64 bit, while the libs are obviously different.
So why do you want to share the libs, since they are different?
Therefore
it makes sense to create a shared directory which contains the shared include
files as well as the different libs for the different platforms.
Ah, well, not to me it doesn't. To me, what makes sense is
(headers+libs)*different.platforms, not (headers)*different.platforms +
(libs)*different.platforms, and this is what the entire GNU/Linux/Unix $prefix
structure assumes. I think this is a little bit like big-endian vs.
little-endian arguments: should the library itself be the most significant
part, or the target? Regardless the arguments one way or another, the GNU
system has already adopted the decision that $target is the most-significant
part of a $prefix layout.
My idea is to keep the w32api subdirs under /usr/include and /usr/lib,
and add a new one under /usr/lib64. These could be implemented as real
subdirs, or as symlinks to, for instance,
/usr/share/windows_psdk/{include,lib,lib64}, as outlined above.
The question is just where to keep the actual include and lib files in
this scenario, and Kai's suggestion was to keep them under
/usr/share/windows_psdk.
What you're implying there, is that from now forever onward, the cygwin
w32api and cross-mingw-w32api packages always have to be kept in perfect
lock-step, if there's only going to be one set of headers for two sets of
libs. That seems like a potential source of incompatibilities to me; as I was
trying to suggest in my comment about autoconfig-customised variants of the
headers, it may one day be the case that the headers for one set of libs have
to actually say something different from the headers for the other set of
libs, and we're tying our own hands in advance if we decide that one common
set of headers has to serve the same lib for two separate targets.
headers for w32api aren't huge in terms of disk space (5.5M), so just having
duplicates in the appropriate places wouldn't be that bad. It's what happens
every time you build libwhatever for both your native system and a
cross-target anyway.
So you opt for the current layout with duplicated include and lib files,
just with Mingw64 instead of Mingw32 files?
Yes, I think it's a perfectly acceptable compromise.
Is there ever any likelihood that the w32api team might want to implement
autoconfigury-based customisations to the installed headers based on the
detected properties of the host platform (n.b. using 'host' in the library
sense, i.e. the same as 'target' for the compiler)? Sharing them between the
two compilers would lock that out.
This is about using the Mingw64 headers, not the w32api headers from
Mingw32. And the 32 and 64 bit headers are the same. Platform
differences are handled via target macros.
Well, as long as we can *guarantee* for ever that that will always be the
case, we could indeed make some complicated scheme to share the headers work,
but really, for the sake of five meg of disk space, I don't see why it's worth
the risk or effort.
Let me summarise what I think: I think we should treat the x-cygwin
(==native) and x-mingw targets as if they were utterly entirely separate, just
like any two other random hosts/targets in the entire gnu infrastructure, and
simply not worry about one tiny disk-space optimisation that we could perhaps
make, at the expense of a good deal of other complications, some actual, some
potential. We should treat w32api as an external lib, and mingw should treat
it as their native C lib, and everything else should flow from that.
cheers,
DaveK
Re: upset errors: package gcc4-java requires non-existent package java-ecj
On 26/10/2011 09:12, Yaakov (Cygwin/X) wrote: On Wed, 2011-10-26 at 09:37 +0200, Corinna Vinschen wrote: Hi Dave, something's not quite correct: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj For now I just removed the dependency to java-ecj since there's no such package on sourceware. What's missing here? http://www.cygwin.com/ml/cygwin-apps/2011-09/msg7.html Oops, sorry, guess my testing still missed that one. *kicks self* I'll try not to forget next time. cheers, DaveK
Re: ATTENTION: Tcl/Tk transition
On 26/10/2011 22:02, Yaakov (Cygwin/X) wrote: cgf has asked me to take over tcl/tk/expect maintainership and transition the distro from our Win32/GDI hybrid 8.4 to the *NIX/X11 8.5 currently in Ports. To anyone feeling apprehensive, I've been using the 'ports versions of tcl and expect for a long time now to test GCC and binutils, and they seem to work pretty well to me. cheers, DaveK
Re: gcc4: Time to drop gcc3 from the distro?
On 03/09/2011 09:42, Corinna Vinschen wrote: On Sep 2 22:15, Dave Korn wrote: On 02/09/2011 19:40, Corinna Vinschen wrote: As the subject says, shouldn't we remove gcc3 from the distro finally? We have 3 mingw compilers and gcc4 for Cygwin. What reason is left to stick to gcc 3? Well, it's the only support we have for Pascal and D. Hmm. And I don't see a Modula-2 compiler in gcc4 either. All of them exist as gcc frontends. I guess it's just lack of maintainers for these packages which keeps them from being in the distro? No, it's lack of upstream development. GM2 and GPC appear to have been utterly dormant projects for quite some years now and won't build against recent GCC versions (GM2 works up to GCC-4.1.2, GPC up to some random date in early 2006). It takes a good deal of effort to keep a front-end up-to-date against mainline GCC development and they clearly just haven't had the manpower. That's why I had to stop packaging them in gcc4 releases. We've got the 3.4 releases, it didn't seem worthwhile making a special separate release just for the 3.4-4.1 change in the only one of the three languages that could be updated at all at the time. On the other hand I just found that D development has been resumed and it's been brought up to date with everything including gcc 4.6 series, so I plan to bring that back in the next gcc4 release :) cheers, DaveK
Re: gcc4: Time to drop gcc3 from the distro?
On 02/09/2011 19:40, Corinna Vinschen wrote: As the subject says, shouldn't we remove gcc3 from the distro finally? We have 3 mingw compilers and gcc4 for Cygwin. What reason is left to stick to gcc 3? Well, it's the only support we have for Pascal and D. Someone might still be using them. cheers, DaveK
Re: gcc4: upset errors + libmpfr vs mpclib version problems (ping David Billinghurst)
On 02/09/2011 05:09, Yaakov (Cygwin/X) wrote: On Fri, 2011-09-02 at 04:00 +, upset lived up to its name and complained: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj That's an artifact from my Ports gcc4 package, as I ship ECJ as part of a GNU Classpath-based Java environment. Since its not in the distro (yet), I removed that dep from sourceware for now; please fix your local copy, etc. Oops, sorry for the breakage and thanks for the headsup. I see I also have an out-of-date libmpfr dependency just like the mingw-x64 compiler, groan. Actually, it's slightly worse than that: $ cygcheck /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe F:\cygwin-1.7\lib\gcc\i686-pc-cygwin\4.5.3\cc1.exe F:\cygwin-1.7\bin\cygcloog-0.dll F:\cygwin-1.7\bin\cyggcc_s-1.dll F:\cygwin-1.7\bin\cygwin1.dll C:\WINNT\system32\ADVAPI32.DLL C:\WINNT\system32\KERNEL32.dll C:\WINNT\system32\ntdll.dll C:\WINNT\system32\RPCRT4.dll F:\cygwin-1.7\bin\cyggmp-3.dll F:\cygwin-1.7\bin\cygppl_c-2.dll F:\cygwin-1.7\bin\cygppl-7.dll F:\cygwin-1.7\bin\cygstdc++-6.dll F:\cygwin-1.7\bin\cyggmpxx-4.dll F:\cygwin-1.7\bin\cygiconv-2.dll F:\cygwin-1.7\bin\cygintl-8.dll F:\cygwin-1.7\bin\cygmpc-1.dll F:\cygwin-1.7\bin\cygmpfr-1.dll F:\cygwin-1.7\bin\cygmpfr-4.dll F:\cygwin-1.7\bin\cygz.dll Note how the compiler executable depends on libmpfr4, but also indirectly via mpclib on libmpfr1 at the same time. That's probably not good; David, can you respin mpclib against the latest libmpfr? cheers, DaveK
Re: gcc4: upset errors + libmpfr vs mpclib version problems (ping David Billinghurst)
On 02/09/2011 05:34, Dave Korn wrote: On 02/09/2011 05:09, Yaakov (Cygwin/X) wrote: On Fri, 2011-09-02 at 04:00 +, upset lived up to its name and complained: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj That's an artifact from my Ports gcc4 package, as I ship ECJ as part of a GNU Classpath-based Java environment. Since its not in the distro (yet), I removed that dep from sourceware for now; please fix your local copy, etc. Oops, sorry for the breakage and thanks for the headsup. I see I also have an out-of-date libmpfr dependency just like the mingw-x64 compiler, groan. Note how the compiler executable depends on libmpfr4, but also indirectly via mpclib on libmpfr1 at the same time. That's probably not good; David, can you respin mpclib against the latest libmpfr? In the meantime, however, I updated the setup.hints to require both libmpfr1 and libmpfr4, just so that nobody gets any missing library problems when they update. cheers, DaveK
Re: GCC dependencies (attn David Billinghurst)
On 14/08/2011 20:29, Yaakov (Cygwin/X) wrote: Looking at the code, the .exe handling is added in gcc/gcc.c. There are two macros: HOST_EXECUTABLE_SUFFIX (which adds .exe to the commands it calls (cc1/as/collect2/ld), and TARGET_EXECUTABLE_SUFFIX, which is used only for and in convert_filename() to change the output filename. But the latter is only used if: /* By default there is no special suffix for target executables. */ /* FIXME: when autoconf is fixed, remove the host check - dj */ #if defined(TARGET_EXECUTABLE_SUFFIX) defined(HOST_EXECUTABLE_SUFFIX) #define HAVE_TARGET_EXECUTABLE_SUFFIX #endif I may be new to the GCC code, but that just looks bogus. On Linux, HOST_EXECUTABLE_SUFFIX is obviously empty, but why should that control HAVE_TARGET_EXECUTABLE_SUFFIX? I've made a patch to change that, and am rebuilding cygwin-gcc with that now. If it works (and I don't see why it won't), I'll go ahead and respin releases with the patch. Dave, anything to add here? Perhaps ping DJ over on the GCC list to ask him if he remembers the context behind that comment; maybe whatever was the autoconf problem is indeed now fixed. cheers, DaveK
Re: GCC dependencies (attn David Billinghurst)
On 12/08/2011 13:09, Yaakov (Cygwin/X) wrote: Besides the version update to 4.5.3, there are several changes over the distro 4.5.0, including: * Linked against shared (instead of static) libintl. * Fix shared libgnat installation. * Fix Java NIO (patch may not be required with recent snapshots). * Pass --large-address-aware when, and --tsaware only when, linking EXEs. * libtool fixup script actually changes .la files. * Don't install GCC .la files so that the libtool fixup script will be less needed in the future. * Revise gcc4-java alternatives usage. Thanks. I'm not too sure about not installing the .la files; won't that potentially lead to problems for libtool-using projects at link time? Also, did you run any testsuites yet? We'll all be glad -- myself included -- for you to resume gcc development; I have only taken a cursory glance at 4.6.1 (and not even a glance at gccgo), and I have no idea where trunk is holding. If you've got time to package stable branches on top of that, fine, otherwise I could still handle the packaging side while you focus on development. Either way, I think we really need a 4.5.3-2 with at least that patchset out as soon as David can finish updating the deps. Let me know how you'd like to proceed. I just started a build and test cycle using your updated patches+cygport script; since you have about a million packages to maintain, I may as well take care of releasing this and free you up for other stuff. cheers, DaveK
Re: Shall setup.exe call rebaseall in postinstall?
On 12/08/2011 16:26, Corinna Vinschen wrote: The next rebase application stores rebase data in a database in /etc. The corresponding rebaseall will use this feature. The effect is that the existing DLLs are compared with the database, and only the DLLs which are new or result in collisions with other DLLs wil be rebased. In the end, all DLLs in the distro will be collision free. The entire process only takes a couple of seconds, so I'm wondering if setup should call rebaseall explicitely at the end of the postinstall, or if we should add a postinstall script which does that all the time, kind of like the enforced _update_info_dir. I always like having a get-out-of-jail-free card up my sleeve, so how about having it as a third checkbox on the installation complete page alongside the desktop/startmenu create icon checkboxes? cheers, DaveK
Re: Shall setup.exe call rebaseall in postinstall?
On 12/08/2011 17:01, Corinna Vinschen wrote: On Aug 12 16:51, Dave Korn wrote: On 12/08/2011 16:26, Corinna Vinschen wrote: The next rebase application stores rebase data in a database in /etc. The corresponding rebaseall will use this feature. The effect is that the existing DLLs are compared with the database, and only the DLLs which are new or result in collisions with other DLLs wil be rebased. In the end, all DLLs in the distro will be collision free. The entire process only takes a couple of seconds, so I'm wondering if setup should call rebaseall explicitely at the end of the postinstall, or if we should add a postinstall script which does that all the time, kind of like the enforced _update_info_dir. I always like having a get-out-of-jail-free card up my sleeve, so how about having it as a third checkbox on the installation complete page alongside the desktop/startmenu create icon checkboxes? How do you decide if the box should be cheched automatically or not? Having a database file? That's not exactly the right thing to do. How else? Or should that be an always checked by default option? I'd just suggest on by default and remembers its state between runs. cheers, DaveK
Re: GCC dependencies (attn David Billinghurst)
On 27/07/2011 04:11, Yaakov (Cygwin/X) wrote: David, As mentioned recently on the list, due to Dave Korn's extended absence, I'll be maintaining our gcc packages. Since you maintain several GCC dependencies, we'll need to coordinate. Yaakov, how is this going? I see you haven't uploaded anything yet. I'm back and able to resume maintainership duties if everyone would like. cheers, DaveK
Re: Ooops, minor setup.hint glitch - and announce list bouncing my posts
On 22/03/2011 21:45, Christopher Faylor wrote: On Tue, Mar 22, 2011 at 09:16:58PM +, Dave Korn wrote: Also, I can't post the release announcement, because the spam filter complains that I have things that look like raw email addresses in the body. Mailing the global allow address didn't help - can anyone get it through manually? Looking at the blocked message, I don't see any mystery. Just remove the cygwin at cygwin dot com email address. Ah, there we go. I also had to obfuscate my own email address in the pgp key. I see it has an exception for the template unsubscribe-you=yourdomain address though! cheers, DaveK
Ooops, minor setup.hint glitch - and announce list bouncing my posts
Hi folks, I just uploaded gcc4-4.3.4-4, and realised the setup.hint requires: lines don't reflect the extra dependencies that 4.5.0-1 requires. There will be a brief window while I fix this when anyone installing 4.5.0 might not get all the libs like MPC GMP etc. that they need. Also, I can't post the release announcement, because the spam filter complains that I have things that look like raw email addresses in the body. Mailing the global allow address didn't help - can anyone get it through manually? cheers, DaveK
Re: Ooops, minor setup.hint glitch - and announce list bouncing my posts
On 22/03/2011 21:16, Dave Korn wrote: I just uploaded gcc4-4.3.4-4, and realised the setup.hint requires: lines don't reflect the extra dependencies that 4.5.0-1 requires. There will be a brief window while I fix this when anyone installing 4.5.0 might not get all the libs like MPC GMP etc. that they need. Guess I forgot to actually ask: Do we prefer the situation where all users of curr: packages get a few extra libs that they don't need, or would we prefer not to make them download extra libs and rely on users of test: packages to manually download anything they find themselves missing? On the whole I guess loading a few extra libs on normal users is probably not a serious burden but wondered if others had thought about it. cheers, DaveK
Re: Ooops, minor setup.hint glitch - and announce list bouncing my posts
On 22/03/2011 21:44, Charles Wilson wrote: On 3/22/2011 5:19 PM, Dave Korn wrote: Guess I forgot to actually ask: Do we prefer the situation where all users of curr: packages get a few extra libs that they don't need, or would we prefer not to make them download extra libs and rely on users of test: packages to manually download anything they find themselves missing? On the whole I guess loading a few extra libs on normal users is probably not a serious burden but wondered if others had thought about it. I usually go ahead and add the new libs to the global requires. This is similar to the situation when a dependent library gets version bumped; I'll typically include BOTH the libs in my app's requires spec: requires: libncurses7 libncurses8 Yeah, and come to think of it, since it's generally expected that test: packages will one day become stable, everyone's going to need those libs sooner or later anyway. So I restored the requires: lines. (There appeared to be something of a spam bomb going on at sourceware when I was logged in, so I imagine that's why the filters have been turned up to full-sensitivity on the -announce list.) cheers, DaveK
Re: [PATCH 2/2] Add a self-update mechanism for setup.exe
On 02/02/2011 23:24, Jon TURNEY wrote:
+ /*
+XXX: do we need a mechanism for source of setup.exe to be overriden in
.ini file
+for the benefit of people who use a patched version? Or can they just
patch this
+as well? :-)
+ */
+#define SETUP_URL http://cygwin.com/setup.exe;
Why not make that a string resource, like the mirror list is?
+ for (int i = 1; _argv[i]; i++)
+{
+ newArgs += ;
+ newArgs += _argv[i];
+}
Quoting would be needed if any of those are paths containing spaces.
cheers,
DaveK
Re: bug tracker discussion
On 20/08/2010 19:01, Christopher Faylor wrote: Can I get a show of hands? How many package maintainers would like to have a bug tracker? I would definitely use it, the same way I currently use the GCC bug tracker: I'd set up a whine email reminder, so that I didn't have to exert any extra effort or feel that any extra burden was imposed on me, I'd just hear about the new bug reports that I was interested in anyway. I'd also want to be the default Cc for bugs in my area, but given that, I'm not persuaded by the this is extra effort on the recipient's part argument; it's just more emails, that you can equally easily filter into the same email folder as the rest of your mails from the main cygwin list if that's how you want to handle it. (Also, I'd be utterly brutal about RESO INVALID anything that I reckoned was a support request rather than an actual bug.) cheers, DaveK
Re: setup: CVS HEAD does not install test: releases
On 16/08/2010 04:25, Yaakov (Cygwin/X) wrote: setup CVS HEAD (2.717) does not download test: releases in either Install from Internet and Download Without Installing modes. I found this out by trying to install gcc4-*-4.5.0-1; after selecting the 4.5.0-1 versions of gcc4-*, they did not show up in the Pending view, nor were they downloaded or installed. However, setup did uninstall my 4.3.4-3, leaving me without *any* gcc. :-( Arg. And you'll get trouble trying to reinstall it, because your old previously downloaded 4.3.4-3 packages now won't match the md5sum of the silently-upgraded-in-place packages listed in the current version of setup.ini. Also, it seems that it's no longer possible to select the Retrieve (meaning re-download) option for those packages. You may have to blow away that part of your package dir; doing so allowed me to redownload 4.3.4-3 and reinstall it successfully, at any rate. cheers, DaveK
Re: setup: CVS HEAD does not install test: releases
On 16/08/2010 05:40, Andy Koppe wrote: On 16 August 2010 04:25, Yaakov (Cygwin/X) yselkow...@users.sourceforge.net wrote: setup CVS HEAD (2.717) does not download test: releases in either Install from Internet and Download Without Installing modes. I found this out by trying to install gcc4-*-4.5.0-1; after selecting the 4.5.0-1 versions of gcc4-*, they did not show up in the Pending view, nor were they downloaded or installed. However, setup did uninstall my 4.3.4-3, leaving me without *any* gcc. :-( You need to manually tick the 'Bin?' box when selecting the experimental version. It's a longer-standing issue: http://www.cygwin.com/ml/cygwin/2010-06/msg00145.html Another annoyance in this area is that once you do have an experimental package installed, setup.exe always tries to downgrade you back to the current one. Another problem is that the dependencies don't work: if you select the test versions of a bunch of the language compilers, they don't cause the test versions of the related runtime libs to get automatically selected. On the other hand, setup is no longer trying to automatically downgrade the test packages any more. But on the down side, it won't let me manually downgrade them either. I had to uninstall all the 4.5.0 version packages in one step and then reinstall 4.3.4 in a second run through setup.exe. cheers, DaveK
Re: gcc4-core PACKAGE BUG
On 13/08/2010 20:29, Corinna Vinschen wrote: On Aug 13 20:31, Dave Korn wrote: On 08/08/2010 17:26, Corinna Vinschen wrote: Hi Dave, testing with the latest setup.exe I came across an error message in postinstall: gcc4-core.sh, exit code 126 Manuall testing turned up that the script /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh is not executable. Yep, I was aware of that, and have explained it on the list whenever it's come up, but now we've got a requester I'll have to fix it properly. I'll do a respin 4.3.4-4 over the weekend or so. Cool, thank you. Come to think of it, wouldn't it be better to just update 4.3.4-3 in place (i.e. without a version bump)? It seems a bit much to force everyone who's already got it installed to redownload that many megabytes just for the sake of a couple of 'x' bits. cheers, DaveK
Re: gcc4-core PACKAGE BUG
On 14/08/2010 19:19, Eric Blake wrote: On 08/14/2010 12:17 PM, Dave Korn wrote: Come to think of it, wouldn't it be better to just update 4.3.4-3 in place (i.e. without a version bump)? It seems a bit much to force everyone who's already got it installed to redownload that many megabytes just for the sake of a couple of 'x' bits. No, that would only work for people who haven't downloaded it yet, or who explicitly reinstall. Yes, that's the point. The main motivation for the update at all is to stop setup.exe reporting an error in the postinstall script stage. Anyone who's already got it installed isn't going to be bothered by that and would be inconvenienced by being forced to redownload the whole thing just in order to run a script. A version bump seems like the best way to ensure it gets picked up without any effort on the user's part. Too bad we don't have anything comparable to yum's presto mode that makes delta downloading easier for simple things like adding an x bit. I don't think actually fixing the x bit is that important, it's just the scary-and-offputting-to-noobs setup.exe error that needs fixing. As for the actual script itself, I think that anyone who's already got GCC installed and has been running it probably isn't bothered by the problem. I've had to mention it maybe half a dozen times on the list, but haven't had any new reports in ages. It's simple enough to tell folks to chmod or source it manually. So I really don't think it's worth the end-user's while in this instance, but I'd like to hear what Corinna and cgf think before I proceed. cheers, DaveK
Re: gcc4-core PACKAGE BUG
On 08/08/2010 17:26, Corinna Vinschen wrote: Hi Dave, testing with the latest setup.exe I came across an error message in postinstall: gcc4-core.sh, exit code 126 Manuall testing turned up that the script /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh is not executable. Yep, I was aware of that, and have explained it on the list whenever it's come up, but now we've got a requester I'll have to fix it properly. I'll do a respin 4.3.4-4 over the weekend or so. cheers, DaveK
Re: [PATCH] inform user if any postinstall script failed to run
On 30/07/2010 15:37, Christopher Faylor wrote:
errors page. The only two packages that should have been installed
were
gcc: C compiler upgrade helper
glib: Gnome C function library (1.2 sources)
(both of which are selected due to a setup.exe bug)
I finally got bored of this one. Turned out to be trivially easy to fix
once I looked at it, it's simply an early exit from the install routine when
there's nothing to do for a dummy tarball (zero or 46-byte size) that misses
out on marking the package as installed.
setup/ChangeLog:
* install.cc (Installer::installOne): Also record zero-sized
tarballs as successfully installed.
OK?
cheers,
DaveK
Index: install.cc
===
RCS file: /cvs/cygwin-apps/setup/install.cc,v
retrieving revision 2.95
diff -p -u -r2.95 install.cc
--- install.cc 7 Apr 2010 11:40:02 - 2.95
+++ install.cc 30 Jul 2010 18:48:19 -
@@ -301,7 +301,10 @@ Installer::installOne (packagemeta pkgm
error condition.
Same goes for tar archives consisting of a big block of
all zero bytes (the famous 46 bytes tar archives). */
-;
+ {
+ if (ver.Type () == package_binary)
+ pkgm.installed = ver;
+ }
else
{
note (NULL, IDS_ERR_OPEN_READ, source.Cached (),
Re: [PATCH] inform user if any postinstall script failed to run
On 30/07/2010 20:19, Dave Korn wrote: I finally got bored of this one. Turned out to be trivially easy to fix once I looked at it, it's simply an early exit from the install routine when there's nothing to do for a dummy tarball (zero or 46-byte size) that misses out on marking the package as installed. BTW, as well as testing that after this patch the zero-length packages get listed in installed.db and so not reinstalled every time, I also verified that the absence of a lst.gz file doesn't impede uninstalling these empty packages later. cheers, DaveK
Re: cygport cross-compiling beta1
On 23/07/2010 01:47, Yaakov (Cygwin/X) wrote: Thinking about this further, I think the problem is that we're talking about two entirely different use cases: 1) cross-compiling a package to install into the sysroot, to be used solely on Cygwin for cross-compile other software, which would follow Cygwin packaging guidelines and use the system-default prefix; 2) cross-compiling software for use on another system (along the lines of canadian-cross.cygclass), which would follow the *host*'s packaging guidelines, or that of the user (at least wrt prefix). These are two completely different scenarios I must be missing something. Shouldn't what's under the sysroot be basically an exact copy with the same layout as what would be on the host's own native filesystem? That's what I get from the description of --with-sysroot at http://gcc.gnu.org/install/configure.html#TOC3. cheers, DaveK
Re: cygport cross-compiling beta1
On 20/07/2010 06:26, Charles Wilson wrote: On 7/19/2010 9:55 PM, JonY wrote: With NLS you will still have at least partial translations, which is better than nothing, no? How about setting up --with-localedir to somewhere version or target specific? There isn't a '--with-localedir' option. But...there IS a --localedir one. How did I miss that? There's still one issue that Yaakov brought up; it's not clear that libintl will actually USE the correct version of the locale files...but some experimentation should answer that question. libintl looks in whatever localedir arg you pass to the bindtextdomain function at startup. In GCC, that's LOCALEDIR which is correctly passed in from $(localedir) in the Makefile. So, it ought to work just fine. (also, --disable-werror, and language Ada) Just hadn't bothered with Ada, that's all. Cygwin gcc needs to be bumped to around 4.5.0 to build it. Its stated somewhere in the GCC docs that you'll need the same version of gcc to build cross ADA. Yep, that's why it's on DaveK's plate. He'll probably keep the cygwin native compiler and the mingw.org-based cross compiler in sync. I just couldn't get frankenAda to build any more at 4.5.0, so I'm aiming at fully cygwinising the language port. However in 4.5.0-1 Ada will be regressed, it'll take me until 4.5.0-2 to get it fixed up. crash. (If you link with shared libgcc/libstdc++, you're ok). Hence why I don't use that option in the Cygwin C++ ABI. For us shared linking is the default. cheers, DaveK
Re: cygport cross-compiling beta1
On 20/07/2010 05:53, Charles Wilson wrote: But at SOME point, SOME part of what you've built on $host is supposed to be used, eventually, by somebody, on $target, right? Where should THAT live? On the target? Then package an /etc/profile.d script that appends or prepends to MANPATH and INFOPATH. Or assume some modicum of intelligence on the part of people with the gumption to actually install a *cross compiler*, and allow them to manually set INFOPATH/MANPATH as appropriate when they are using a given cross tool. Either of these work for me, but each compiler should definitely have its own docs in its own prefix IMO. Also, this packaging oddity: mingw64-x86_64: usr/x86_64-w64-mingw32/lib64/libiberty.a x86_64-w64-mingw32 is potentially a multilib arch, hence the lib64. If the gcc were actually built multilib, you'd see a lib32 and lib64. mingw64-i686: usr/i686-w64-mingw32/lib/lib32/libiberty.a You mean /usr/i686-w64-mingw32/lib/libiberty.a? The only way you would get lib32/libiberty.a (not lib/lib32) is with multilib, which I disabled in my builds. Re: libiberty.a, I have no idea why we even install that. We don't install the headers, and it has no fixed defined API or versioning, so it's basically useless. I wouldn't worry too much about where it ends up! However, given the dependency structure of the gcc3 packages, this means you pretty much have to also remove, using setup, gcc-core gcc-g++ gcc-java gcc-objc Note that this conflict means that the current gcc-mingw* packages (and, thus, the gcc 3.x packages) conflict with the new mingw-gcc-* and mingw-binutils-* packages. Also, this may have implications for the upgrade process, when the real mingw32-gcc cross toolchain is released. Even if we mark the gcc (3) packages obsolete, we probably have to repackage them and their gcc-mingw* friends to fix this upgrade problem, and perhaps relieve the conflict. Somehow? We can just remove the gcc-mingw* deps from gcc3*. But the bigger question is, do we still *need* gcc3 in the distro? Yes, we get mails every now and again where someone's relying on it to build a legacy app, I don't want to pull it. Once we can build setup.exe with gcc4, then I don't believe we *need* it. And we can *definitely* get rid of mingw-gcc*; at that point, gcc -mno-cygwin breaks badly, and we get to say it's been deprecated for over a year, and now it is no longer supported. Use this spiffy new cross compiler. But...somebody out there might have (cygwin) code that doesn't compile with gcc4. They ought to fix their code, but...this is not an ideal world. Yeah, this is tricky. I don't mind if we end up telling people they can have *either* gcc-3 *or* x-mingw-gcc4 but not both at the same time. I guess it's worth testing if gcc-3 -mno-cygwin still works with up-to-date mingw cross-binutils and libs installed in place of the /usr/i686-pc-mingw32 symlinks. cheers, DaveK
Re: gcc4: next release
On 07/07/2010 02:47, JonY wrote: Hello, Can I ask what will be the next version of GCC be in Cygwin? 4.5.0-1 if I'm snappy. 4.5.1-1 if I'm not. I plan to get back to it at the start of next week. This makes GCC look in /usr/mingw regardless of what the toolchain target is (anything matching mingw*), bad idea if we want a gcc 4 mingw.org cross toolchain later. It can be fixed, but I'm not too sure how yet. Locale data is also conflicting. Yaakov suggested that I sync up with Cygwin GCC so the clash won't be so problematic, eg 4.5.0 Cygwin with 4.5.1 branch snapshot for mingw-w64. GCC 4.5.x branch and the 4.6.x branch ABI changed for win64, I'm trying to avoid breaking user's self-built packages, so 4.5.0 and earlier is out of the question. The current 4.3.4 is too old for mingw-w64. Going with 4.5.1 seems the simplest solution. I'm slightly astonished though! How on earth did you manage to swing permission to put an ABI-breaking backwardly-incompatible change on a release branch? cheers, DaveK (still catching up with the backlog - I haven't finished reading this thread yet...)
Re: [ITP] mingw-w64
On 05/07/2010 18:38, Charles Wilson wrote: However, the DLLs don't appear to be in the correct locations. opt/mingw64/bin/libobjc-2.dll opt/mingw64/bin32/libgcc_s_sjlj-1.dll opt/mingw64/bin64/libgcc_s_sjlj-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgfortran-3.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgomp-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libssp-0.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libstdc++-6.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgfortran-3.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgomp-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libssp-0.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libstdc++-6.dll Now, the DLLs buried down in the 4.6.0/ directory I can see (it appears to be a mistake, but that IS where they normally go...even if we choose to put them in toplevel bin32 and bin64 dirs instead.) It looks like the cygport is missing some 'mv' commands. Should be handled by passing -bindir=$bindir to libtool rather than mv'ing them after make install. But how the heck did libobjc-2.dll get into the regular bin/ dir? And why is there only one version of it? I forgot about libobjc when adding -bindir support to GCC(*, didn't make it in time for 4.5 branch. Guess I should see about backporting that for 4.5.1. cheers, DaveK -- (*) - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30445#c3
Re: [ITP] mingw-w64
On 06/07/2010 16:59, JonY wrote:
On 7/6/2010 23:36, Charles Wilson wrote:
I found the problem: configure.ac is patched, but there's no mechanism
to ensure that the corresponding change to configure is included in the
patch (by default, cygport *assumes* you will run autoreconf, and so
explicitly excludes configure, Makefile.in (for automake projects), etc
from the diff.)
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
I haven't really checked, but I think that may no longer be true since the
upgrade to 2.64/1.11.1.
I did this too with the libstdc++-v3, libgomp and etc, but only
libobjc-2 is having trouble?
So, there are a couple of ways around this. All are pretty ugly.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc autoconf)
to just force the end user to fixup THAT configure script only,
without mucking with any other auto* generated files.
If you look at the distro gcc4 cygport, you'll see it carefully does just
the necessary amount of autoconfing and automakeing. (But that may no longer
be necessary, as I mentioned above.)
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you do,
is you just don't HAVE a .src.patch. Instead, you make your OWN patch,
ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI=the-name-of-my-custom-patch
I'm switching to this approach for gcc-4.5.0-1, anyway.
cheers,
DaveK
Re: gcc4: next release
On 07/07/2010 02:47, JonY wrote: I'm working on the mingw-w64 GCC package on Cygwin. Normally, anything cygwin gets installed to /usr, however, with gcc 4.6, the locales data clashes. Yaakov suggested installing to /usr, but there are some problems with it. This makes GCC look in /usr/mingw regardless of what the toolchain target is (anything matching mingw*), bad idea if we want a gcc 4 mingw.org cross toolchain later. It can be fixed, but I'm not too sure how yet. Hmm, does this even happen when it is being built as a cross- rather than native- compiler? That would be a GCC bug if so; cross-compilers are meant not to look in the standard system directories as if they were native, see the docs for LOCAL_INCLUDE_DIR, SYSTEM_INCLUDE_DIR, STANDARD_INCLUDE_DIR and INCLUDE_DEFAULTS(*) for full details. Locale data is also conflicting. So can't it just go in $prefix/$target/share instead of $prefix/share after a bit of fiddling with configure options? cheers, DaveK -- (*) - http://gcc.gnu.org/onlinedocs/gccint/Driver.html
Re: default terminal
On 01/06/2010 19:19, Andy Koppe wrote: On 1 June 2010 00:14, Charles Wilson wrote: Perhaps, instead, setup could create two shortcuts instead of just one. The first would be the same link to cygwin.bat we currently have Cygwin; the other Cygwin MinTTY would be similar to the one mintty's current postinstall creates. Or switch 'em around, with Cygwin going to MinTTY, and Cygwin DOSBOX going to cygwin.bat. Not a bad idea. Cygwin Console and Cygwin Terminal perhaps? Of course people still wouldn't know the difference, but at least they could try them and find out, and delete as appropriate. +1. Then again, we might get lots of questions about why setup.exe felt the need to create two shortcuts and what the difference between them is. Hmm. We already get plenty of questions about the difference between a console and a terminal. Don't think it'll be any different really. Let's call the shortcuts Cygwin Console and Cygwin GUI Terminal, and then people will think it's obvious why there's two of them. cheers, DaveK
Libelf respin coming [was Re: [ITP-again] Re: [ITP] libelf]
On 31/05/2010 07:23, Yaakov (Cygwin/X) wrote: On 2010-05-29 17:28, Dave Korn wrote: So, since you asked, would you care to give it a once over and check that I got all the cygport stuff right this time? Looks like that works. I got a bug report off-list, about a couple of functions that were still missing from the .def file. I've done a trivial respin and will just go ahead and upload it in a couple of hours time, unless anyone wants me to send it here for review first, in which case please say so. cheers, DaveK
Re: [ITP-again] Re: [ITP] libelf
On 31/05/2010 07:23, Yaakov (Cygwin/X) wrote: On 2010-05-29 17:28, Dave Korn wrote: So, since you asked, would you care to give it a once over and check that I got all the cygport stuff right this time? Looks like that works. Thanks for double checking, I'll upload it and send an -announce. cheers, DaveK
Re: [ITP-again] Re: [ITP] libelf
On 31/05/2010 16:54, Corinna Vinschen wrote: On May 31 15:34, Dave Korn wrote: On 31/05/2010 07:23, Yaakov (Cygwin/X) wrote: On 2010-05-29 17:28, Dave Korn wrote: So, since you asked, would you care to give it a once over and check that I got all the cygport stuff right this time? Looks like that works. Thanks for double checking, I'll upload it and send an -announce. Care to update the cygwin-pkg-maint file as well? Done. While I was doing that, I noticed a few minor ordering errors appear to have crept in with time; shall we run 'sort' on it? cheers, DaveK --- cygwin-pkg-maint 2010-06-01 02:55:54.703125000 +0100 +++ .p 2010-06-01 02:57:46.296875000 +0100 @@ -39,8 +39,8 @@ atk-devel OBSOLETE atk-doc OBSOLETE (Yaakov S) atk-runtime OBSOLETE (Yaakov S) atk1.0 Yaakov S -attrCorinna Vinschen atool Andrew Schulman +attrCorinna Vinschen audiofile Yaakov S autoconfCharles Wilson autoconf-devel OBSOLETE (Charles Wilson) @@ -83,9 +83,9 @@ boost-devel ORPHANED botan Lapo Luchini boxes Jari Aalto brltty Samuel Thibault +bsdcpio Charles Wilson bsdiff Lapo Luchini bsdtar Charles Wilson -bsdcpio Charles Wilson bsfilterJari Aalto bsflite Jonathan C. Allen build-docbook-catalog Yaakov S @@ -327,8 +327,8 @@ gconf2-doc OBSOLETE gd Dr. Volker Zell gdb Christopher Faylor gdbmCharles Wilson -gdk-pixbuf2.0-svg Yaakov S gdk-pixbuf2-wmf Dr. Volker Zell +gdk-pixbuf2.0-svg Yaakov S genisoimage Christian Franke geoip Jari Aalto getmail Jari Aalto @@ -463,8 +463,8 @@ libAfterImage Charles libAfterImage-devel Charles Wilson libAfterImage0 Charles Wilson libXpm-noX Charles Wilson -libXpm-noX_4Charles Wilson libXpm-noX-develCharles Wilson +libXpm-noX_4Charles Wilson libaa1 Dr. Volker Zell libao David Rothenberger libao-devel David Rothenberger @@ -488,8 +488,8 @@ libassuan Charles libassuan-devel Charles Wilson libatk1.0-devel Yaakov S libatk1.0_0 Yaakov S -libattr1Corinna Vinschen libattr-devel Corinna Vinschen +libattr1Corinna Vinschen libaudiofile-devel Yaakov S libaudiofile0 Yaakov S libautotrace-devel Dr. Volker Zell @@ -537,8 +537,8 @@ libdb4.5Dr. Volk libdb4.5-devel Dr. Volker Zell libdbus-glib_1-develYaakov S libdbus-glib_1_2Yaakov S -libdbus1_2 Yaakov S libdbus1-devel Yaakov S +libdbus1_2 Yaakov S libdmx Yaakov S libdmx-develYaakov S libdmx1 Yaakov S @@ -585,8 +585,8 @@ libfpx Dr. Volk libfpx-develDr. Volker Zell libfpx1 Dr. Volker Zell libfreetype-devel Yaakov S -libfreetype26 OBSOLETE (Yaakov S) libfreetype2-devel OBSOLETE (Yaakov S) +libfreetype26 OBSOLETE (Yaakov S) libfreetype6Yaakov S libgailutil-devel Yaakov S libgailutil18 Yaakov S @@ -608,10 +608,10 @@ libgdbm3Charles libgdbm4Charles Wilson libgdk_imlib-devel Yaakov S libgdk_imlib1 Yaakov S -libgdk_pixbuf_xlib2.0-devel Yaakov S -libgdk_pixbuf_xlib2.0_0 Yaakov S libgdk_pixbuf2.0-devel Yaakov S libgdk_pixbuf2.0_0 Yaakov S +libgdk_pixbuf_xlib2.0-devel Yaakov S +libgdk_pixbuf_xlib2.0_0 Yaakov S libgeotiff Charles Wilson libgeotiff-develCharles Wilson libgeotiff1 Charles Wilson @@ -681,9 +681,9 @@ libgnomeprintui2.2-develYaakov S libgnomeprintui2.2_0Yaakov S libgnomeprintui22 OBSOLETE (Yaakov S) libgnomeui2 Yaakov S -libgnomeui2_0 Yaakov S libgnomeui2-devel Yaakov S
[ITP-again] Re: [ITP] libelf
On 18/05/2010 22:00, Yaakov (Cygwin/X) wrote: On 2009-12-20 13:56, Dave Korn wrote: libelf(*) is a requirement for supporting LTO in the upcoming GCC 4.5.0 (and beyond), and I needed to build myself a local copy so I could test that, so I figured I might as well package it properly while I was at it. http://packages.debian.org/search?keywords=libelf It's shipped in all versions of Debian so I don't (aiui) need a vote, just a second pair of eyeballs to verify I got the packaging and setup hints correct. Dave, are you planning to upload this? So, since you asked, would you care to give it a once over and check that I got all the cygport stuff right this time? test package download script cd /tmp rm -rf libelf0/ mkdir libelf0 cd libelf0 wget \ http://tinyurl.com/yaw5dnu/libelf0-0.8.13-1-src.tar.bz2 \ http://tinyurl.com/yaw5dnu/libelf0-0.8.13-1.tar.bz2 \ http://tinyurl.com/yaw5dnu/setup.hint mkdir libelf0-devel cd libelf0-devel wget \ http://tinyurl.com/yaw5dnu/libelf0-devel/libelf0-devel-0.8.13-1.tar.bz2 \ http://tinyurl.com/yaw5dnu/libelf0-devel/setup.hint cheers, DaveK
Re: setup.exe packagedb cache refresh bug
On 28/05/2010 19:51, Brendan Conoboy wrote: On 05/27/2010 02:04 PM, Dave Korn wrote: I can't find any way that can happen; can you describe the steps you used to trigger the problem? OTOH I _can_ see a problem if you get as far as the chooser screen and then go all the way back to the root dir page, so I figure we do need some kind of reset mechanism anyway. I don't think we want to call it from way down in mount.cc though, so I'll look for a higher level to put it at, and I'll fix it to free up the existing data while I do that. Now I'm having trouble reproducing it on vanilla sources. I'm guessing it's some other local patch causing the problem- I'll track that down and post back if I can reproduce it on the pristine sources. Sorry for the false alarm. Thanks; as far as I can see, what you're describing is the same as the original bug that me and Corinna discussed back when I applied the patch, and I thought I had taken care to avoid re-introducing it. That said, however, there is definitely a problem with going back from the chooser page to the start of setup.exe, and it probably is worth fixing with some kind of reset. At the moment I'm trying to figure out why de-allocating all the allocated things doesn't work right; when implemented naively, it results in the chooser page always saying that there is nothing to install. cheers, DaveK
Re: Attn: Dave Korn - Re: setup.exe packagedb cache refresh bug
On 26/05/2010 15:16, Christopher Faylor wrote: On Sat, May 22, 2010 at 12:57:25PM -0400, Christopher Faylor wrote: On Sat, May 22, 2010 at 08:52:29AM -0700, Brendan Conoboy wrote: On 05/21/2010 11:18 PM, Christopher Faylor wrote: This comment in RootPage::OnNext would suggest that this was already supposed to have been handled. /* Deferred initialization of packagedb *after* the root dir has been chosen. */ It appears you're looking at rev 2.25 of root.cc, while I'm looking at the latest, 2.26 which doesn't have that. Dave Korn's changelog entry: 2010-04-17 Dave Korn dave.korn.cyg...@gmail.com * root.cc (RootPage::OnNext): Don't construct a packagedb here nor do deferred initialisation of static packagedb::task. * source.cc (save_dialog): Don't construct a packagedb here, and set static packagedb::task directly instead of chosen_db_task. * package_meta.cc (packagemeta::action_caption): Don't bother to construct a packagedb here, just access packagedb::task directly. * package_db.cc: Move 'static members' comment near static members. (chosen_db_task): Delete. * package_db.h (chosen_db_task): Don't declare extern. (packagedb): Extend comments on class. Presumably this has caused the problem. Dave, what was the goal of this patch? The archives are your friend. http://cygwin.com/ml/cygwin-apps/2010-04/threads.html#00037 Dave, it looks like your recent change broke this. Do you have any suggestions for fixing it? Sorry, haven't been following the -apps list closely for a couple of days; I'll figure out a fix for this tonight. cheers, DaveK
Re: setup.exe packagedb cache refresh bug
On 22/05/2010 16:52, Brendan Conoboy wrote: On 05/21/2010 11:18 PM, Christopher Faylor wrote: This comment in RootPage::OnNext would suggest that this was already supposed to have been handled. /* Deferred initialization of packagedb *after* the root dir has been chosen. */ It appears you're looking at rev 2.25 of root.cc, while I'm looking at the latest, 2.26 which doesn't have that. Dave Korn's changelog entry: 2010-04-17 Dave Korn * root.cc (RootPage::OnNext): Don't construct a packagedb here nor do deferred initialisation of static packagedb::task. * source.cc (save_dialog): Don't construct a packagedb here, and set static packagedb::task directly instead of chosen_db_task. * package_meta.cc (packagemeta::action_caption): Don't bother to construct a packagedb here, just access packagedb::task directly. * package_db.cc: Move 'static members' comment near static members. (chosen_db_task): Delete. * package_db.h (chosen_db_task): Don't declare extern. (packagedb): Extend comments on class. Presumably this has caused the problem. Dave, what was the goal of this patch? The goal of that patch was to defer initialisation of packagedb not merely until after the root dir had been chosen, but even later than that: it should not now be populated until the setup.ini parsing stage runs. So, I think that regardless of that comment, the bug should have present in the earlier version of the code anyway. You wrote: The problem occurs because packagedb is populated before the user has a chance to specify what directory to use for the installation. I can't find any way that can happen; can you describe the steps you used to trigger the problem? OTOH I _can_ see a problem if you get as far as the chooser screen and then go all the way back to the root dir page, so I figure we do need some kind of reset mechanism anyway. I don't think we want to call it from way down in mount.cc though, so I'll look for a higher level to put it at, and I'll fix it to free up the existing data while I do that. cheers, DaveK
Re: [PATCH] Incidental setup.exe patches #3: Simplify packagedb task handling
On 15/04/2010 09:57, Corinna Vinschen wrote: On Apr 14 18:17, Dave Korn wrote: OK now? I think so, yes. Thank you. Applied, finally. Here's a question. Do you have any idea how much work it would be to convert the packagedb singleton into an ordinary class with an ordinary class member which could be constructed and deconstructed at will? For instance, if somebody presses Next up to the chooser dialog and then presses Back up to the root dir dialog, just to choose another root dir? Not too much, I think, but it's not going to be my first priority. cheers, DaveK
Re: [PATCH] Incidental setup.exe patches #3: Simplify packagedb task handling
On 14/04/2010 09:21, Corinna Vinschen wrote: [ ... ] I couldn't work out what the original problem referred to might have been Are you sure? Please check again. The original situation which this was supposed to fix is this: - You have an existing installation in C:\cygwin - You want to create a new installation in D:\cygwin-new - You choose D:\cygwin-new as root dir in the root dir dialog - The package list was nevertheless based on the c:\cygwin directory installation, because the package_db stuff was already initialized with the Cygwin root dir set to C:\cygwin Thanks, that's just what I was looking for. Can you make sure that this doesn't happen after your change? Argh, zOMG. See, I did this: $ grep -w task *.[ch]* archive.cc: * One such task is identifying archives compress.cc: * One such task is identifying compresss package_db.cc: packagedb::task = package_db.h: static PackageDBActions task; package_meta.cc: return db.task == PackageDB_Install ? Reinstall : Retri eve; root.cc: db.task = chosen_db_task; threebar.cc: switch (task) threebar.cc: Window::PostMessage (task); threebar.h: int task; threebar.h:task = t; and reasoned that there really is only one place the behaviour of the application can possibly depend on the value set in task. Then I looked at this: - /* Deferred initialization of packagedb *after* the root dir has been - chosen. */ - packagedb db; - db.task = chosen_db_task; and thought Oh, and we don't need to actually construct a packagedb and throw it away again just to access a static member. *Sigh*, I should have read what the constructor does. Wow, what a misbegotten application of OOP that is. A pseudo-singleton that stores all the data in class static members the first time you construct one and retrieves it for any subsequently constructed ones. That's probably the first non-idempotent default constructor I've ever seen. So: 1. There's no problem setting the class-static task variable early: it's just constructing the first packagedb that mustn't be done until after the root is set. 1a. So we can still get rid of the caching-and-deferred-initialisation. The original bug was solved by /not/ constructing a packagedb at the original site where the task was set, rather than specifically by constructing one later. 1b. It never needed to construct a packagedb at that point anyway, because you don't need a this-pointer to set a static member; it was that misunderstanding that caused the bug in the first place. 2. There's no need to construct a packagedb immediately after the root dir is set; whenever we first construct one subsequently, it'll work. 3. For that reason the patch ought to fix the original bug in any case. I have to run out to the shops for half an hour now, and when I get back I'll fire up a VM, and make absolutely certain. cheers, DaveK
Re: [PATCH] Incidental setup.exe patches #3: Simplify packagedb task handling
On 14/04/2010 14:30, Dave Korn wrote: On 14/04/2010 09:21, Corinna Vinschen wrote: Are you sure? Please check again. The original situation which this was supposed to fix is this: - You have an existing installation in C:\cygwin - You want to create a new installation in D:\cygwin-new - You choose D:\cygwin-new as root dir in the root dir dialog - The package list was nevertheless based on the c:\cygwin directory installation, because the package_db stuff was already initialized with the Cygwin root dir set to C:\cygwin 1. There's no problem setting the class-static task variable early: it's just constructing the first packagedb that mustn't be done until after the root is set. 1a. So we can still get rid of the caching-and-deferred-initialisation. The original bug was solved by /not/ constructing a packagedb at the original site where the task was set, rather than specifically by constructing one later. 1b. It never needed to construct a packagedb at that point anyway, because you don't need a this-pointer to set a static member; it was that misunderstanding that caused the bug in the first place. 2. There's no need to construct a packagedb immediately after the root dir is set; whenever we first construct one subsequently, it'll work. 3. For that reason the patch ought to fix the original bug in any case. I have to run out to the shops for half an hour now, and when I get back I'll fire up a VM, and make absolutely certain. So I verified not just that the bug was indeed fixed (point 3), but also that my theory in point 1 was correct by adding code back to save_dialog() in source.cc that just constructed a packagedb and threw it away and verifying that it re-introduced the bug. I'll rewrite the comments now I know exactly what's going on and resend it later. cheers, DaveK
Re: [PATCH] Incidental setup.exe patches #3: Simplify packagedb task handling
On 14/04/2010 15:41, Dave Korn wrote:
I'll rewrite the comments now I know exactly what's going on and resend it
later.
Here:
* root.cc (RootPage::OnNext): Don't construct a packagedb here nor
do deferred initialisation of static packagedb::task.
* source.cc (save_dialog): Don't construct a packagedb here, and
set static packagedb::task directly instead of chosen_db_task.
* package_meta.cc (packagemeta::action_caption): Don't bother to
construct a packagedb here, just access packagedb::task directly.
* package_db.cc: Move 'static members' comment near static members.
(chosen_db_task): Delete.
* package_db.h (chosen_db_task): Don't declare extern.
(packagedb): Extend comments on class.
OK now?
cheers,
DaveK
Index: root.cc
===
RCS file: /cvs/cygwin-apps/setup/root.cc,v
retrieving revision 2.25
diff -p -u -r2.25 root.cc
--- root.cc 28 Jan 2010 22:59:09 - 2.25
+++ root.cc 14 Apr 2010 16:46:25 -
@@ -287,11 +287,6 @@ RootPage::OnNext ()
(root_text == IDC_ROOT_TEXT ? text : binary)
(root_scope == IDC_ROOT_USER ? user : system) endLog;
- /* Deferred initialization of packagedb *after* the root dir has been
- chosen. */
- packagedb db;
- db.task = chosen_db_task;
-
return 0;
}
Index: source.cc
===
RCS file: /cvs/cygwin-apps/setup/source.cc,v
retrieving revision 2.21
diff -p -u -r2.21 source.cc
--- source.cc 28 Jun 2009 03:50:43 - 2.21
+++ source.cc 14 Apr 2010 16:46:25 -
@@ -54,7 +54,12 @@ static void
save_dialog (HWND h)
{
source = rbget (h, rb);
- chosen_db_task =
+ /* We mustn't construct any packagedb objects until after the root
+ directory has been selected, but setting the static data member
+ that records the mode we're running in is fine here (and conversely,
+ would be A Bad Thing if we did it again after the first time we
+ construct a packagedb object; see package_db.h for details). */
+ packagedb::task =
source == IDC_SOURCE_DOWNLOAD ? PackageDB_Download : PackageDB_Install;
}
Index: package_meta.cc
===
RCS file: /cvs/cygwin-apps/setup/package_meta.cc,v
retrieving revision 2.56
diff -p -u -r2.56 package_meta.cc
--- package_meta.cc 13 Dec 2009 19:23:43 - 2.56
+++ package_meta.cc 14 Apr 2010 16:46:25 -
@@ -362,10 +362,7 @@ packagemeta::action_caption () const
else if (!desired)
return Skip;
else if (desired == installed desired.picked())
-{
- packagedb db;
- return db.task == PackageDB_Install ? Reinstall : Retrieve;
-}
+return packagedb::task == PackageDB_Install ? Reinstall : Retrieve;
else if (desired == installed desired.sourcePackage() desired.sourcePackage().picked())
/* FIXME: Redo source should come up if the tarball is already present locally */
return Source;
Index: package_db.cc
===
RCS file: /cvs/cygwin-apps/setup/package_db.cc,v
retrieving revision 2.43
diff -p -u -r2.43 package_db.cc
--- package_db.cc 18 Dec 2009 11:59:54 - 2.43
+++ package_db.cc 14 Apr 2010 16:46:25 -
@@ -45,10 +45,6 @@ static const char *cvsid =
using namespace std;
-PackageDBActions chosen_db_task = PackageDB_Install;
-
-/* static members */
-
packagedb::packagedb ()
{
io_stream *db = 0;
@@ -199,6 +195,8 @@ packagedb::findSource (PackageSpecificat
return NULL;
}
+/* static members */
+
int
packagedb::installeddbread =
0;
Index: package_db.h
===
RCS file: /cvs/cygwin-apps/setup/package_db.h,v
retrieving revision 2.23
diff -p -u -r2.23 package_db.h
--- package_db.h 12 Aug 2008 20:32:08 - 2.23
+++ package_db.h 14 Apr 2010 16:46:25 -
@@ -29,12 +29,33 @@ typedef enum {
PackageDB_Download
} PackageDBActions;
-extern PackageDBActions chosen_db_task;
-
class packagedb;
typedef std::vector packagemeta *::iterator PackageDBConnectedIterator;
/*TODO: add mutexs */
+
+/*TODO: add sanity. Beware, Here Be C++ Dragons:
+
+ This class is a hidden singleton. It's a singleton, but you create
+ and delete transient objects of the class, none of which have any
+ member data, but solely serve as shortcuts to access one static set
+ of shared data through an irrelevant this-pointer.
+
+ Not only that, but it's a hidden singleton that is constructed
+ the first time you access it, and constructed differently
+ based on implicit global state.
+
+ Not only that, but it has some static state of its own that also
+ controls how it gets constructed, but that could then be changed
+ afterward without invalidating the cached data, silently changing
+ its semantic interpretation.
+
+ To use this class, you must first set
Re: [PATCH] Incidental setup.exe patches #2: Fix chooser vertical scroll bar.
On 13/04/2010 08:55, Corinna Vinschen wrote:
On Apr 12 22:59, Dave Korn wrote:
+RECT windowRect = GetWindowRect ();
+if (hasWindowRect)
{
int dx;
-if ((dx = clientRect.right - clientRect.left -
-lastClientRect.width ()) != 0)
+if ((dx = windowRect.right - windowRect.left -
+lastWindowRect.width ()) != 0)
{
[ ... snip ... ]
}
+if (windowRect.right - windowRect.left - lastWindowRect.width ())
+ set_vscroll_info (GetClientRect ());
}
OK?
Yes.
Because I was everso disciplined and applied the patches to a clean tree and
built and tested them before committing, I spotted the above refactoring error
which I cut'n'pasto'd during the last-minute renaming of
hasWindowRect/lastWindowRect. The delta y test should of course be checking
the vertical, not horizontal co-ordinates. *blushes*
Applied after re-testing with the relevant line corrected like so:
+ if (windowRect.bottom - windowRect.top - lastWindowRect.height ())
+ set_vscroll_info (GetClientRect ());
cheers,
DaveK
Re: [PATCH] Incidental setup.exe patches #2: Fix chooser vertical scroll bar.
On 13/04/2010 19:08, Dave Korn wrote:
Because I was everso disciplined
Sigh, and just to remind me that you should never gloat on the internet, I
left a line of debug trace in there. Doesn't impair the operation in any way,
but it could leave a lot of clutter in the logs.
* PickView.cc (PickView::WindowProc): Delete inadvertently-committed
debug logging.
Committed as obvious, after testing in the debugger to make sure I would
actually see all the logging going on this time.
cheers,
DaveK
Index: PickView.cc
===
RCS file: /cvs/cygwin-apps/setup/PickView.cc,v
retrieving revision 2.37
diff -p -u -r2.37 PickView.cc
--- PickView.cc 13 Apr 2010 17:49:11 - 2.37
+++ PickView.cc 14 Apr 2010 02:35:44 -
@@ -818,8 +818,6 @@ PickView::WindowProc (UINT message, WPAR
{
// Note: WM_SIZE msgs only appear when 'just' scrolling the window
RECT windowRect = GetWindowRect ();
- log(LOG_BABBLE) WR: ( windowRect.left , windowRect.top
- ) x ( windowRect.right , windowRect.bottom ) endLog;
if (hasWindowRect)
{
int dx;
[PATCH] Incidental setup.exe patches #3: Simplify packagedb task handling
I found out why we never see packages being set to Retrieve in download
mode any more. There was a bit of a refactoring accident here:
2008-08-12
Revamp for Cygwin 1.7.
* package_db.cc (chosen_db_task): New global variable.
* package_db.h (chosen_db_task): Declare.
(RootPage::OnNext): Initialize packagedb here the first time, to
avoid fetching wrong data from different previous installation.
* source.cc (save_dialog): Don't initialize packagedb here, rather
just memorize setting in chosen_db_task for the deferred initialization
in RootPage::OnNext.
The problem with this design is that the root page isn't run in download
mode, so the deferred assignment never happens. As it happens, the default
setting is PackageDB_Install, which means that download mode is the only mode
in which the deferred assignment would actually change anything - but it's
also the one mode in which the deferred assignment never takes place!
Fortunately, as far as I can tell, it no longer matters. I couldn't work
out what the original problem referred to might have been, because subsequent
changes have apparently rendered it moot. The one and only thing for which
the packagedb's task setting is used any more is in order to decide whether to
return the string Reinstall or Retrieve when generating the action caption
for the PickPackageLine related to a given packagemeta.
So, I think we can now safely remove chosen_db_task and the whole deferred
init construct, giving the attached patch.
* package_db.cc (chosen_db_task): Delete variable. Relocate
trailing comment.
* package_db.h (chosen_db_task): Don't declare extern.
* package_meta.cc (packagemeta::action_caption): Simplify static
member access to packagedb task.
* root.cc (RootPage::OnNext): Don't deferred-init packagedb task.
* source.cc (save_dialog): Set packagedb task directly instead of
caching value in chosen_db_task for deferred init.
In download mode, the strings that until now used to say Reinstall, now
say Retrieve again. OK?
Also, a more general question: what does it mean that setup.exe offers an
Uninstall option in download mode? (I'm going to have to fire up a VM and
see whether it actually does anything or not, but what could it be *supposed*
to do?) My first thought is that it's an accident and shouldn't be there.
cheers,
DaveK
Index: package_db.cc
===
RCS file: /cvs/cygwin-apps/setup/package_db.cc,v
retrieving revision 2.43
diff -p -u -r2.43 package_db.cc
--- package_db.cc 18 Dec 2009 11:59:54 - 2.43
+++ package_db.cc 14 Apr 2010 03:50:54 -
@@ -45,10 +45,6 @@ static const char *cvsid =
using namespace std;
-PackageDBActions chosen_db_task = PackageDB_Install;
-
-/* static members */
-
packagedb::packagedb ()
{
io_stream *db = 0;
@@ -199,6 +195,8 @@ packagedb::findSource (PackageSpecificat
return NULL;
}
+/* static members */
+
int
packagedb::installeddbread =
0;
Index: package_db.h
===
RCS file: /cvs/cygwin-apps/setup/package_db.h,v
retrieving revision 2.23
diff -p -u -r2.23 package_db.h
--- package_db.h 12 Aug 2008 20:32:08 - 2.23
+++ package_db.h 14 Apr 2010 03:50:54 -
@@ -29,8 +29,6 @@ typedef enum {
PackageDB_Download
} PackageDBActions;
-extern PackageDBActions chosen_db_task;
-
class packagedb;
typedef std::vector packagemeta *::iterator PackageDBConnectedIterator;
Index: package_meta.cc
===
RCS file: /cvs/cygwin-apps/setup/package_meta.cc,v
retrieving revision 2.56
diff -p -u -r2.56 package_meta.cc
--- package_meta.cc 13 Dec 2009 19:23:43 - 2.56
+++ package_meta.cc 14 Apr 2010 03:50:54 -
@@ -362,10 +362,7 @@ packagemeta::action_caption () const
else if (!desired)
return Skip;
else if (desired == installed desired.picked())
-{
- packagedb db;
- return db.task == PackageDB_Install ? Reinstall : Retrieve;
-}
+return packagedb::task == PackageDB_Install ? Reinstall : Retrieve;
else if (desired == installed desired.sourcePackage() desired.sourcePackage().picked())
/* FIXME: Redo source should come up if the tarball is already present locally */
return Source;
Index: root.cc
===
RCS file: /cvs/cygwin-apps/setup/root.cc,v
retrieving revision 2.25
diff -p -u -r2.25 root.cc
--- root.cc 28 Jan 2010 22:59:09 - 2.25
+++ root.cc 14 Apr 2010 03:50:54 -
@@ -287,11 +287,6 @@ RootPage::OnNext ()
(root_text == IDC_ROOT_TEXT ? text : binary)
(root_scope == IDC_ROOT_USER ? user : system) endLog;
- /* Deferred initialization of packagedb *after* the root dir has been
- chosen. */
- packagedb db;
- db.task = chosen_db_task;
-
[PATCH] Incidental setup.exe patches #2: Fix chooser vertical scroll bar.
Hi,
Here's another one I noticed: the vertical scroll bar doesn't get adjusted
when you resize the chooser vertically. It does get reproportioned correctly
when you click anywhere in the chooser (or change mode or do anything that
triggers a full redraw), and this patch factors out the code to adjust it into
a routine that can be called from both clicks and resize operations. While
it's doing that, it clears up a bit of naming confusion where variables with
names relating to ClientRect are used to store details that are actually
those returned from GetWindowRect(); I figured that would look doubly
confusing when I went and introduced an actual GetClientRect() call in the
same area if I didn't clean it up.
* PickView.h (PickView::set_vscroll_info): Add prototype.
(PickView::hasClientRect): Rename from this ...
(PickView::hasWindowRect): ... to this ...
(PickView::lastClientRect): ... and from this ...
(PickView::lastWindowRect): ... to this.
* PickView.cc (PickView::PickView): Adjust member init to match.
(PickView::set_vscroll_info): Abstract code to set vertical scroll
bar proportions from ...
(PickView::list_click): ... here. Call it. Fix comment typo.
(PickView::WindowProc): Update all renamed variables in WM_SIZE
case, and check also for a y delta, calling set_vscroll_info if so.
OK?
cheers,
DaveK
Index: PickView.h
===
RCS file: /cvs/cygwin-apps/setup/PickView.h,v
retrieving revision 2.19
diff -u -p -r2.19 PickView.h
--- PickView.h 1 Jul 2009 07:50:07 - 2.19
+++ PickView.h 12 Apr 2010 21:34:59 -
@@ -51,6 +51,7 @@ public:
LRESULT CALLBACK list_click (HWND hwnd, BOOL dblclk, int x, int y, UINT hitCode);
LRESULT CALLBACK list_hscroll (HWND hwnd, HWND hctl, UINT code, int pos);
LRESULT CALLBACK list_vscroll (HWND hwnd, HWND hctl, UINT code, int pos);
+ void set_vscroll_info (const RECT r);
virtual LRESULT WindowProc (UINT uMsg, WPARAM wParam, LPARAM lParam);
Header *headers;
PickView (Category cat);
@@ -146,8 +147,8 @@ private:
std::string packageFilterString;
// Stuff needed to handle resizing
- bool hasClientRect;
- RECTWrapper lastClientRect;
+ bool hasWindowRect;
+ RECTWrapper lastWindowRect;
int total_delta_x;
int set_header_column_order (views vm);
Index: PickView.cc
===
RCS file: /cvs/cygwin-apps/setup/PickView.cc,v
retrieving revision 2.36
diff -u -p -r2.36 PickView.cc
--- PickView.cc 13 Dec 2009 19:23:43 - 2.36
+++ PickView.cc 12 Apr 2010 21:34:59 -
@@ -527,7 +527,7 @@ PickView::init_headers (HDC dc)
PickView::PickView (Category cat) : deftrust (TRUST_UNKNOWN),
contents (*this, cat, 0, false, true), showObsolete (false),
-packageFilterString (), hasClientRect (false), total_delta_x (0)
+packageFilterString (), hasWindowRect (false), total_delta_x (0)
{
}
@@ -668,6 +668,28 @@ PickView::list_hscroll (HWND hwnd, HWND
return 0;
}
+void
+PickView::set_vscroll_info (const RECT r)
+{
+ SCROLLINFO si;
+ memset (si, 0, sizeof (si));
+ si.cbSize = sizeof (si);
+ si.fMask = SIF_ALL | SIF_DISABLENOSCROLL;/* SIF_RANGE was giving strange behaviour */
+ si.nMin = 0;
+
+ si.nMax = contents.itemcount () * row_height;
+ si.nPage = r.bottom - header_height;
+
+ /* if we are under the minimum display count ,
+ * set the offset to 0
+ */
+ if ((unsigned int) si.nMax = si.nPage)
+scroll_ulc_y = 0;
+ si.nPos = scroll_ulc_y;
+
+ SetScrollInfo (GetHWND(), SB_VERT, si, TRUE);
+}
+
LRESULT CALLBACK
PickView::list_click (HWND hwnd, BOOL dblclk, int x, int y, UINT hitCode)
{
@@ -688,31 +710,14 @@ PickView::list_click (HWND hwnd, BOOL db
refresh = click (row, x);
- // XXX we need a method to queryt he database to see if more
+ // XXX we need a method to query the database to see if more
// than just one package has changed! Until then...
#if 0
if (refresh)
{
#endif
RECT r = GetClientRect ();
- SCROLLINFO si;
- memset (si, 0, sizeof (si));
- si.cbSize = sizeof (si);
- si.fMask = SIF_ALL | SIF_DISABLENOSCROLL;/* SIF_RANGE was giving strange behaviour */
- si.nMin = 0;
-
- si.nMax = contents.itemcount () * row_height;
- si.nPage = r.bottom - header_height;
-
- /* if we are under the minimum display count ,
- * set the offset to 0
- */
- if ((unsigned int) si.nMax = si.nPage)
-scroll_ulc_y = 0;
- si.nPos = scroll_ulc_y;
-
- SetScrollInfo (GetHWND(), SB_VERT, si, TRUE);
-
+ set_vscroll_info (r);
InvalidateRect (GetHWND(), r, TRUE);
#if 0
}
@@ -812,12 +817,12 @@ PickView::WindowProc (UINT message, WPAR
case WM_SIZE:
{
// Note: WM_SIZE msgs only appear when 'just' scrolling the window
-RECT clientRect = GetWindowRect ();
-if
Re: Setup 2.693 unable to replace files through reboot
On 07/04/2010 12:40, Corinna Vinschen wrote: I just applied the matching patch. Chris, could you please upload a new setup.exe? And can we renew the tradition of uploading the debug versions and source tarball from the build into the http://cygwin.com/setup/ dir? We're kind-of bordering on gpl non-compliant, because there's no way of knowing for sure (after downloading the binary of setup.exe) whether whoever compiled it had everything up-to-date in their sandbox, and cvs doesn't even have atomic revisions, so it's not entirely straightforward to reconstruct what the checkout must have been from the version number of the uploaded binary which is just the revision of the ChangeLog. cheers, DaveK
Re: setup: use external crypto libraries
On 25/03/2010 16:55, Christopher Faylor wrote: I'd rather get verification that it works in the native environment for someone else. Testing now. cheers, DaveK
Re: setup: use external crypto libraries
On 26/03/2010 01:26, Dave Korn wrote: On 25/03/2010 16:55, Christopher Faylor wrote: I'd rather get verification that it works in the native environment for someone else. Testing now. WJFFM, both before and after deleting the libgcrypt/libgpg-error subdirs from my sandbox. Thanks Chuck! cheers, DaveK
Re: setup: use external crypto libraries
On 19/03/2010 00:40, Charles Wilson wrote: About a week after this patch, or something like it, goes in, I'll prepare another one that actually removes libgpg-error/ and libgcrypt/ I really can't see any benefit in separating the two. For a week, people checking out CVS will have to download eight megs of code that isn't even going to be used any more!? Built and tested; the setup.exe works fine. However, unlike my report here: http://cygwin.com/ml/cygwin-apps/2010-03/msg00085.html, THIS time I did get the error from upx: upx: setup.exe: CantPackException: TLS callbacks are not supported It comes from tlssup.o in libmingw32.a, in the most recent mingw-runtime versions. cheers, DaveK
Re: RFC: setup.exe, mingw-libgpg-error/mingw-gcrypt
On 14/03/2010 18:35, Christopher Faylor wrote:
On Sun, Mar 14, 2010 at 02:00:51PM -0400, Charles Wilson wrote:
One of the things that bugs me about building setup.exe is if you do a
make from the top level, it always recurses into the libgpg-error and
libgcrypt subdirectories, even when there's nothing to do. Because part
of our build process 'installs' the gcrypt stuff into a local private
'installation' directory, this is /not/ actually a fast no-op; it takes
a reasonable amount of time, each time. So, you end up 'installing'
libgpg over and over and over -- unless you retrain your fingers to do
'make setup.exe' rather than simply 'make'.
This has always bugged me too.
I don't remember what the motivation was for doing the pseudo-install step
in the first place, it was something you added after my initial version of the
code. Possibly it was to do with not wanting to embed knowledge of the
libraries' build tree into setup's makefile.
I've looked at the machinery which seems
to insist on repeated recompilation of libg* objects but I've never
been motivated enough to fix it.
Well, we could do this:
Index: Makefile.am
===
RCS file: /cvs/cygwin-apps/setup/Makefile.am,v
retrieving revision 2.77
diff -p -u -r2.77 Makefile.am
--- Makefile.am 28 Jun 2009 03:50:42 - 2.77
+++ Makefile.am 14 Mar 2010 20:29:05 -
@@ -321,4 +321,4 @@ snapshot: release
.PHONY: ${INST_SUBDIRS}
${INST_SUBDIRS}:
- ${MAKE} -C $@ install
+ ${MAKE} -C $@ -q || ${MAKE} -C $@ install
... which only does the install if there would be anything to do during the
'all' part of the build, but that isn't robust against deleting all or part of
the $objdir/inst tree. It does speed up the build very nicely though! We
could even add just a few extra static dependencies that would re-run the
install stage(s) if the needed lib(s) wasn't found in the inst/ tree. (Or we
could even go back to linking the build libs directly out of the sub-$objdirs.)
Moving it out of the tree entirely would be a nicer fix.
Sounds good too. I checked the whole lot in in the first place because we
were in a rush to get it done, and because the thought of making it into
separate packages for the distro didn't occur to me at the time. There's
certainly no special reason for it.
cheers,
DaveK
setup snapshots missing?
Did something break during the 1.5-1.7 changes maybe? I can't find the setup snapshots anymore: 404 http://cygwin.com/setup/ 404 http://cygwin.com/setup/snapshots/ Or is it just missing because we haven't spun any new ones since the rearrangements? cheers, DaveK
Re: setup snapshots missing?
On 01/03/2010 20:38, Christopher Faylor wrote: On Mon, Mar 01, 2010 at 08:21:22PM +, Dave Korn wrote: Did something break during the 1.5-1.7 changes maybe? I can't find the setup snapshots anymore: 404 http://cygwin.com/setup/ 404 http://cygwin.com/setup/snapshots/ Or is it just missing because we haven't spun any new ones since the rearrangements? When the snapshots are older than the released version it's sure to generate confusion. I deleted the snapshots. Ah. Does that mean there's no downloadable archive of the exact sources used to build the currently-distributed setup.exe/setup-legacy.exe, nor (what I was particularly hoping to find) corresponding debug builds? (I thought we generally did releases by uploading a snapshot and then copying that to the top-level URL, but I guess I was just assuming, nobody ever said so explicitly.) cheers, DaveK
Re: [PATCH] Add chooser-only mode to setup.exe
On 19/02/2010 09:49, Andy Koppe wrote: Dave Korn: I think we talked about this idea before once. It's a variant of setup.exe's unattended mode that skips through everything automatically except for the chooser page. I decided to call it 'package manager mode', because that's what I'm planning on using it for Thank you very much for implementing this; very convenient. One problem: if the selected mirror is out of action, 'setup -M' goes into an endless loop trying to fetch setup.ini. Blargle! Thanks for the report, I'll get onto it when I get a chance (gcc 4.5 is a higher priority for me right now so probably not until next week, unless someone else jumps in.) cheers, DaveK
[PATCH] Add chooser-only mode to setup.exe
Hi gang,
I think we talked about this idea before once. It's a variant of
setup.exe's unattended mode that skips through everything automatically except
for the chooser page. I decided to call it 'package manager mode', because
that's what I'm planning on using it for, but don't mind if anyone wants to
change the option name.
setup/ChangeLog:
* choose.cc (ChooserPage::PlaceDialog): Only skip resizing window
in fully-unattended mode, not chooser-only mode.
(ChooserPage::OnUnattended): Return appropriate status to run page
or not according to kind of unattended mode.
* choose.h (ChooserPage::OnUnattended): Remove inline implementation
and retain prototype only.
* main.cc (PackageManagerOption): New boolean option.
(main): Take it into account when setting unattended_mode.
* proppage.cc (PropertyPage::DialogProc): Use new enum type when
setting unattended_mode.
* state.cc (unattended_mode): Change from bool to enum attend_mode.
* state.h (enum attend_mode): Declare new enum type.
(unattended_mode): Update extern declaration to use it.
Ok?
cheers,
DaveK
Index: choose.cc
===
RCS file: /cvs/cygwin-apps/setup/choose.cc,v
retrieving revision 2.153
diff -p -u -r2.153 choose.cc
--- choose.cc 22 Dec 2009 01:26:39 - 2.153
+++ choose.cc 6 Feb 2010 03:25:39 -
@@ -176,8 +176,8 @@ ChooserPage::getParentRect (HWND parent,
void
ChooserPage::PlaceDialog (bool doit)
{
- if (unattended_mode)
-/* Don't jump up and down in unattended mode */;
+ if (unattended_mode == unattended)
+/* Don't jump up and down in (fully) unattended mode */;
else if (doit)
{
pre_chooser_placement.length = sizeof pre_chooser_placement;
@@ -262,6 +262,16 @@ ChooserPage::OnActivate()
PlaceDialog (true);
}
+long
+ChooserPage::OnUnattended()
+{
+ if (unattended_mode == unattended)
+return OnNext ();
+ // Magic constant -1 (FIXME) means 'display page but stay unattended', as
+ // also used for progress bars; see proppage.cc!PropertyPage::DialogProc().
+ return -1;
+}
+
void
ChooserPage::logResults()
{
Index: choose.h
===
RCS file: /cvs/cygwin-apps/setup/choose.h,v
retrieving revision 2.39
diff -p -u -r2.39 choose.h
--- choose.h 30 Jun 2009 04:03:12 - 2.39
+++ choose.h 6 Feb 2010 03:25:39 -
@@ -37,10 +37,7 @@ public:
virtual long OnNext ();
virtual long OnBack ();
virtual void OnActivate ();
- virtual long OnUnattended ()
- {
-return OnNext ();
- };
+ virtual long OnUnattended ();
static void SetHwndDialog (HWND h)
{
Index: main.cc
===
RCS file: /cvs/cygwin-apps/setup/main.cc,v
retrieving revision 2.62
diff -p -u -r2.62 main.cc
--- main.cc 27 Dec 2009 17:46:25 - 2.62
+++ main.cc 6 Feb 2010 03:25:39 -
@@ -85,6 +85,7 @@ HINSTANCE hinstance;
bool is_legacy;
static BoolOption UnattendedOption (false, 'q', quiet-mode, Unattended setup mode);
+static BoolOption PackageManagerOption (false, 'M', package-manager, Semi-attended chooser-only mode);
static BoolOption HelpOption (false, 'h', help, print help);
static BOOL WINAPI (*dyn_AttachConsole) (DWORD);
static BOOL WINAPI (*dyn_GetLongPathName) (LPCTSTR, LPTSTR, DWORD);
@@ -299,7 +300,9 @@ main (int argc, char **argv)
if (!GetOption::GetInstance ().Process (argc,_argv, NULL))
exit (1);
-unattended_mode = UnattendedOption;
+unattended_mode = PackageManagerOption ? chooseronly
+ : (UnattendedOption ? unattended : attended);
+
if (unattended_mode || HelpOption)
set_cout ();
Index: proppage.cc
===
RCS file: /cvs/cygwin-apps/setup/proppage.cc,v
retrieving revision 2.18
diff -p -u -r2.18 proppage.cc
--- proppage.cc 15 Apr 2006 21:21:25 - 2.18
+++ proppage.cc 6 Feb 2010 03:25:39 -
@@ -195,7 +195,7 @@ PropertyPage::DialogProc (UINT message,
long nextwindow = OnUnattended();
if (nextwindow == -2)
{
- unattended_mode = false;
+ unattended_mode = attended;
SetWindowLong (GetHWND (), DWL_MSGRESULT, 0);
return TRUE;
}
Index: state.cc
===
RCS file: /cvs/cygwin-apps/setup/state.cc,v
retrieving revision 2.6
diff -p -u -r2.6 state.cc
--- state.cc 7 Aug 2008 22:59:17 - 2.6
+++ state.cc 6 Feb 2010 03:25:39 -
@@ -22,7 +22,7 @@ static const char *cvsid =
#include state.h
-bool unattended_mode;
+enum attend_mode unattended_mode = attended;
bool rebootneeded;
int source;
Index: state.h
===
RCS file: /cvs/cygwin-apps/setup/state.h,v
Re: [PATCH] Add chooser-only mode to setup.exe
On 06/02/2010 06:48, Christopher Faylor wrote: On Sat, Feb 06, 2010 at 06:32:59AM +, Dave Korn wrote: I think we talked about this idea before once. It's a variant of setup.exe's unattended mode that skips through everything automatically except for the chooser page. I decided to call it 'package manager mode', because that's what I'm planning on using it for, but don't mind if anyone wants to change the option name. I don't recall discussing this. Ah, no, I think I just mentioned it in passing when adding the --only-site option: http://www.cygwin.com/ml/cygwin-apps/2009-11/msg00018.html Could you clarify how this would be used? It basically just skips a couple of screens at the beginning, right? Does it skip the mirror selection too? Is it intended to just manage your packages after cygwin is installed, keeping all of your default settings? Yes. It is basically the exact same as unattended mode, except you get manual control returned for the chooser screen, that is the only difference. It's intended for 3PPs, mostly: you can install a full local package dir onto the user's HD and then give them a shortcut in their start menu that behaves kind-of like add/remove programs or a linux package manager. cheers, DaveK
Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
On 25/01/2010 01:34, Yaakov (Cygwin/X) wrote: On 24/01/2010 19:03, JonY wrote: and libiberty.a. Wouldn't this belong in /usr/$triplet/lib/? Libiberty needn't be installed or shipped at all really. It's pretty damn useless without any header file. Dunno why make install even bothers with it. cheers, DaveK
Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
On 25/01/2010 04:16, JonY wrote: This could be changed in the upstream GCC with libw32stdc++-6 as 32bit mingw-w64 toolchain, libw64stdc++-6 as 64bit mingw-w64, and the normal libstdc++-6 for the mingw.org toolchain. Now all 3 can live side by side. That seems like a logical and consistent extension of the existing cyg*-vs-lib* DLL namespacing convention. cheers, DaveK
Re: Need input on packaging mingw-w64 for Cygwin
On 23/01/2010 19:02, Christopher Faylor wrote: On 1/23/2010 21:51, Chris Sutcliffe wrote: mingw-w64http://mingw-w64.sourceforge.net/ is a fork of mingw to support both win32 and win64. It'll obviously be setup as a cross compiler on Cygwin. Does this mean that these are all non-cygwin mingw apps? Nope, they are cygwin-based cross development tools. cheers, DaveK
Re: Is anyone looking into the file-in-use setup.exe problems?
Christopher Faylor wrote: On Thu, Jan 14, 2010 at 11:33:34AM -0500, Christopher Faylor wrote: Do I have this right? Is anyone thinking about looking into this or does anyone have any insight into the recent breakage? I've just fixed a bug that may have been the root cause of this problem. Thanks. I'm pretty tied up right now. cheers, DaveK
Re: [ITP, take 2] Re: [ITP] libelf
Dave Korn wrote: send me the libelf0-0.8.13-1-compile.log offlist and I'll see how it compares to one of mine. Also if you could dump a list of the imports from your version of the dll, I'd like to see which symbols its pulling in. Nevermind; I figured it out. I have a local patch in my binutils (which I'm about to send upstream) that accounts for the difference. I'll upload libelf without libgcc1 in the requires: line, since the DLL that I build won't have the import. (DLLs built using unpatched binutils will continue to pull in this redundant dependency, but that's not a problem for me, only for anyone who for whatever reason decides they want to repackage it themselves.) cheers, DaveK
Re: [ITP, take 2] Re: [ITP] libelf
Yaakov (Cygwin/X) wrote: On 30/12/2009 11:38, Dave Korn wrote: Nevermind; I figured it out. I have a local patch in my binutils (which I'm about to send upstream) that accounts for the difference. I'll upload libelf without libgcc1 in the requires: line, since the DLL that I build won't have the import. (DLLs built using unpatched binutils will continue to pull in this redundant dependency, but that's not a problem for me, only for anyone who for whatever reason decides they want to repackage it themselves.) Why is a dependency on libgcc1 redundant? Because it doesn't actually need anything from libgcc1. It gets pulled in by the weak reference here in gcc/config/i386/cygming-crtbegin.c: --- extern void __register_frame_info (const void *, struct object *) TARGET_ATTRIBUTE_WEAK; extern void *__deregister_frame_info (const void *) TARGET_ATTRIBUTE_WEAK; [ ... ] if (h) register_frame_fn = (void (*) (const void *, struct object *)) GetProcAddress (h, __register_frame_info); else register_frame_fn = __register_frame_info; if (register_frame_fn) register_frame_fn (__EH_FRAME_BEGIN__, obj); --- This is a PE weak external, and if there aren't any strong definitions elsewhere in the program, it should fall back to the default value (zero); in particular it should not cause the import stub to be pulled in from the libgcc import library. The bug in binutils causes the weakness of the symbol to be forgotten, causing the reference to be pulled in; the result is that at startup the program unnecessarily calls into the libgcc dll to register empty EH frame tables. Harmless but wasteful. The reason this only happens sometimes when linking a DLL is because it depends on the order in which LD encounters the weak reference and other undefined references to the same symbol; the weakness can get lost. It's another side of the same bug as here, http://cygwin.com/ml/cygwin/2009-12/threads.html#00583 where it resulted in a weak reference giving an undefined symbol error; here, there is a version of the symbol in question available, so it just ends up pulling the symbol in when it wasn't wanted. (I'll post the fix to the binutils list shortly, I'm writing it up now.) cheers, DaveK
Re: [ITP, take 2] Re: [ITP] libelf
Yaakov (Cygwin/X) wrote: On 23/12/2009 21:52, Dave Korn wrote: When I build those packages from source, there is no dependency on libgcc: Did you actually get such a dependency when you built it, or was this just a thinko? Yes, when I rebuilt your package from source, there is a libgcc1 dependency, and strangely enough, your original binary does not. The question is, why not? Dunno yet, and I'm gonna be AFK for a couple of days now, but send me the libelf0-0.8.13-1-compile.log offlist and I'll see how it compares to one of mine. Also if you could dump a list of the imports from your version of the dll, I'd like to see which symbols its pulling in. cheers, DaveK
