Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
Andy Koppe writes: 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? Try the cygport from Git master, I believe it should fix that. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On Apr 13 06:55, Andy Koppe wrote: On 11 April 2013 23:37, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:37, Charles Wilson wrote: #2) Is it possible to use the auto-setup.hint-generator functionality for multi-part package sets (e.g. which contain multiple separate tarballs, in addition to -src and -debuginfo)? If so, how? Yes; it just works, and also handles inter-subpackage dependencies (e.g. apps in foo will dep libfooX, and implibs in libfoo-devel will dep the corresponding DLL in libfooX). Just define CATEGORY/SUMMARY/DESCRIPTION (there are also subpackage-specific variants of these) and omit the hint files from $C; at the end of the package stage, cygport will show you the dependencies it computes for each package so you can check them. 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: 64bit: cygstdc++-6.dll
On Apr 12 21:31, Dave Korn wrote: On 12/04/2013 16:57, Corinna Vinschen wrote: On Apr 10 16:49, Dave Korn wrote: 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 Out of curiosity, which linker script is that? What's the difference to the normal 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? 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 13 April 2013 10:03, Corinna Vinschen wrote: On Apr 13 06:55, Andy Koppe wrote: On 11 April 2013 23:37, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:37, Charles Wilson wrote: #2) Is it possible to use the auto-setup.hint-generator functionality for multi-part package sets (e.g. which contain multiple separate tarballs, in addition to -src and -debuginfo)? If so, how? Yes; it just works, and also handles inter-subpackage dependencies (e.g. apps in foo will dep libfooX, and implibs in libfoo-devel will dep the corresponding DLL in libfooX). Just define CATEGORY/SUMMARY/DESCRIPTION (there are also subpackage-specific variants of these) and omit the hint files from $C; at the end of the package stage, cygport will show you the dependencies it computes for each package so you can check them. 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. Thanks, Andy
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
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 2013-04-12 12:34, Dave Korn wrote: 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? Yes, absolutely. Yaakov
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 2013-04-13 00:55, Andy Koppe wrote: 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. As Corinna already pointed out, this is a sign that the setup.hint generation succeeded, and in this case the requires: line is blank (and rightfully so, since mintty uses only cygwin1.dll and Win32 APIs). If it had failed, there would have been a warning about a missing .hint file instead. I've also tried installing cygport from git master but got this after running ./autogen.sh make: make: *** No rule to make target `data/gnuconfig/config.guess', needed by `all-am'. Stop. This is one quirk of git that I've never understood: git clone does not expand submodules by default without the --recursive flag. Run git submodule update --init to get these after a clone. BTW: _CYGPORT_RESTRICT_postinst_doc_=1 Variables beginning with an underscore are for internal use only. This should be RESTRICT=postinstall-doc. But what problem did you encounter to necessitate this? insinto /usr/share/man/man1 doins docs/mintty.1 doman docs/mintty.1 dodoc COPYING dodoc LICENSE.Oxygen dodoc LICENSE.PuTTY FYI, dodoc takes multiple arguments. Yaakov
