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 2013-04-11 23:24, Dave Korn wrote:
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?
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.
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!
*Within the scope of cygport*, cygport(1) is the user and it controls
CC based on a number of factors. CC can then be used within the
cygport(5), e.g. with a handwritten makefile:
src_compile() {
lndirs
cd ${B}
cygmake CC=${CC} CFLAGS=${CFLAGS} AR=${AR} RANLIB=${RANLIB}
}
But like most cygport APIs, CC (and others marked as [Definitions] in
the manual) should be treated as opaque constants; it might end up as
gcc if building natively, or one of {i686,x86_64}-pc-cygwin-gcc if
cross-compiling (cygport supports doing so from both Cygwin and Linux),
${CROSS_HOST}-gcc if cross.cygclass is in use, or even clang or
$host-clang with clang.cygclass. Saying CC=gcc-4 obviously doesn't work
in all those scenarios.
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.
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.)
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.
On the contrary, the compiler knows best how to links its own libs
without libtool's help; in fact, sometimes libtool tries to be *too*
smart and ends up just getting in the way, hence the need for patches
such as this:
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libtool;a=blob;f=2.4-pass-ldflags.patch;h=cd08a54;hb=HEAD
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?
Yaakov
Re: [64bit] type conflict for INT32
On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote: It does mean that Win32API (or X11, for that matter) headers must be #include'd before jpeglib.h. Before I spin a new release, could you test if this works with emacs? Would this problem go away if we switched to jpeg-turbo? -- Chuck
Re: Recent cygport and cygwin-specific READMEs
On 4/11/2013 6:37 PM, Yaakov (Cygwin/X) wrote: No, cygport(1) doesn't generate README content. Too bad. Well, maintaining the READMEs in my local git repo side-by-side with the cygport(5) is not that big a deal -- especially with the other cygport(1) improvements, incl #3 below. #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 Fabulous. #3) As I've been gone for a while, I might've missed recent changes: do setup.exe and/or cygport support build dependencies directly in any way, rather than the ad-hoc put-it-in-a-cygwin-README technique I've been using 'til now? See DEPEND in the cygport manual. (Yes, this is confusing now that REQUIRES exists for additional *runtime* dependencies. I'm thinking of renaming this to BUILDREQUIRES or the like, but for API compatibility DEPEND would still work.) These are checked at the beginning of the build step, and a warning issued if any are missing. Great -- which actually means I can remove that bit from the cygwin-specific READMEs. That's the most annoying part of keeping the READMEs up-to-date anyway. -- Chuck
Re: [64bit] type conflict for INT32
On 4/12/2013 10:04 AM, Charles Wilson wrote: On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote: It does mean that Win32API (or X11, for that matter) headers must be #include'd before jpeglib.h. Before I spin a new release, could you test if this works with emacs? Would this problem go away if we switched to jpeg-turbo? No, the 64bit repository is already using jpeg-turbo. Ken
Re: [64bit] type conflict for INT32
On Apr 12 10:24, Ken Brown wrote: On 4/12/2013 10:04 AM, Charles Wilson wrote: On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote: It does mean that Win32API (or X11, for that matter) headers must be #include'd before jpeglib.h. Before I spin a new release, could you test if this works with emacs? Would this problem go away if we switched to jpeg-turbo? No, the 64bit repository is already using jpeg-turbo. And, in fact, it's not *really* a terrible problem, is it? You have to expect type name conflicts when mixing applications and libraries from the POSIX world with Windows headers. Just see the stuff in the newlib, Cygwin, and w32api headers centered around conflicting definitions due to winsock being almost, but not quite, BSD sockets. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [64bit] type conflict for INT32
On 4/12/2013 11:07 AM, Corinna Vinschen wrote: On Apr 12 10:24, Ken Brown wrote: On 4/12/2013 10:04 AM, Charles Wilson wrote: On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote: It does mean that Win32API (or X11, for that matter) headers must be #include'd before jpeglib.h. Before I spin a new release, could you test if this works with emacs? Would this problem go away if we switched to jpeg-turbo? No, the 64bit repository is already using jpeg-turbo. And, in fact, it's not *really* a terrible problem, is it? You have to No, not at all. Yaakov came up with a simple fix. Ken expect type name conflicts when mixing applications and libraries from the POSIX world with Windows headers. Just see the stuff in the newlib, Cygwin, and w32api headers centered around conflicting definitions due to winsock being almost, but not quite, BSD sockets. Corinna
Re: 64bit: cygstdc++-6.dll
Dave? Ping? 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? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
64 bit Cygwin 1.7.18-19
Hi again kiddies,
I'm just uploading the 64 bit cygwin 1.7.18-19 package. While testing
something ugly with sockets, I accidentally stumbled over another bug
based on the size difference between DWORD and {s}size_t. I fixed that
a couple of days ago for recv/send and most of read/write, but I missed
the overlapped functions used for pipes and fifos. They, too, suffered
from the problem Marco reported last week.
That should be fixed in -19. Please give it a try.
Thanks,
Mum^WCorinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
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: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
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.
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.
Andy
mintty.cygport:
NAME=mintty
VERSION=1.2-beta1
RELEASE=1
CATEGORY=Base Shells
DEPEND=make gcc-core w32api
HOMEPAGE=http://mintty.googlecode.com;
SRC_URI=http://mintty.googlecode.com/files/mintty-${PV}-src.tar.bz2;
SUMMARY=Terminal emulator with native Windows look and feel
DESCRIPTION=\
Mintty is a terminal emulator for Cygwin. It is based on code
from PuTTY 0.60 by Simon Tatham and team.
Features include:
* Xterm-compatible terminal emulation.
* Full Unicode support.
* Native Windows user interface that tries to keep things simple.
* Graphical options dialog. Options stored in a text file.
* Drag drop and copy paste of text, files and folders.
* Extensive mouse support.
* Window transparency.
_CYGPORT_RESTRICT_postinst_doc_=1
src_compile() {
lndirs
cd ${B}
cygmake
}
src_install() {
cd ${B}
dobin mintty.exe
insinto /usr/share/man/man1
doins docs/mintty.1
dodoc COPYING
dodoc LICENSE.Oxygen
dodoc LICENSE.PuTTY
}
