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 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
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 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
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 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
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
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
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
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 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 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
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 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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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.
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
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
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'
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
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
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
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
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
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
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
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
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
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
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
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
. */
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
1 - 100 of 528 matches
Mail list logo
