On Apr 24 00:52, Charles Wilson wrote:
On 4/13/2013 11:45 PM, Yaakov (Cygwin/X) wrote:
On 2013-04-13 00:55, Andy Koppe wrote:
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',
On 4/24/2013 4:34 AM, Corinna Vinschen wrote:
On Apr 24 00:52, Charles Wilson wrote:
Why would simply shortening the PATH have this effect?
Do you have a big environment? Thre's a chance that the stack address
moves due to that.
$ printenv | wc
65 1162418
$ echo $PATH | wc
On Apr 24 09:54, Charles Wilson wrote:
On 4/24/2013 4:34 AM, Corinna Vinschen wrote:
On Apr 24 00:52, Charles Wilson wrote:
Why would simply shortening the PATH have this effect?
Do you have a big environment? Thre's a chance that the stack address
moves due to that.
$ printenv | wc
On 4/13/2013 11:45 PM, Yaakov (Cygwin/X) wrote:
On 2013-04-13 00:55, Andy Koppe wrote:
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
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
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
On 14 April 2013 04:45, Yaakov (Cygwin/X) wrote:
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
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,
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
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
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
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
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
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
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
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
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
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;
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
On 2013-04-11 01:02, Dave Korn wrote:
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
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
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
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
On 4/11/2013 2:58 AM, Yaakov (Cygwin/X) wrote:
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.
I know that cygwin-specific READMEs are now no longer required or
While the mirror script pulls down the shiny new gcc from Dave…
Charles Wilson writes:
#1) Is it possible to also record cygwin-specific README content
within the cygport(5)? [1] If so, can you do more than one? (I'm
thinking here of inetutils, which has a separate cygwin-specific
README for
Am 11.04.2013 14:34, schrieb Dave Korn:
On 11/04/2013 13:19, Corinna Vinschen 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
On 2013-04-11 07:37, Charles Wilson wrote:
#1) Is it possible to also record cygwin-specific README content within
the cygport(5)? [1] If so, can you do more than one? (I'm thinking here
of inetutils, which has a separate cygwin-specific README for the
-server (sub)package and for the -client
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
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
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
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
On Apr 9 17:17, Dave Korn wrote:
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
Dave Korn writes:
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
On Wed, Apr 10, 2013 at 05:31:55PM +0200, Achim Gratz wrote:
Dave Korn writes:
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
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
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
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
37 matches
Mail list logo
