On 9/16/2010 9:38 AM, JonY wrote:
I have uploaded the 32bit toolchain, I hope there are no thinkos when
adapting the cygport files.
All packages rebuild from source ok. Packaging looks good; I used them
to build a working xz and liblzma with no trouble. genini is happy with
the setup.hints
On 9/17/2010 16:17, Charles Wilson wrote:
On 9/16/2010 9:38 AM, JonY wrote:
I have uploaded the 32bit toolchain, I hope there are no thinkos when
adapting the cygport files.
All packages rebuild from source ok. Packaging looks good; I used them
to build a working xz and liblzma with no
On Sep 17 04:17, Charles Wilson wrote:
On 9/16/2010 9:38 AM, JonY wrote:
I have uploaded the 32bit toolchain, I hope there are no thinkos when
adapting the cygport files.
All packages rebuild from source ok. Packaging looks good; I used them
to build a working xz and liblzma with no
On Sep 17 10:33, Charles Wilson wrote:
On 9/17/2010 7:24 AM, Corinna Vinschen wrote:
cygwin-pkg-maint?
Done.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Hi,
I have uploaded the 32bit toolchain, I hope there are no thinkos when
adapting the cygport files.
mingw64-i686-binutils
category: Devel
requires: libgcc1 libintl8 zlib0
sdesc: Binutils for MinGW-w64 Win32 toolchain
ldesc: Mingw-w64 Cross binutils for Win32 target.
On Tue, Sep 14, 2010 at 05:58:08AM +0100, Andy Koppe wrote:
On 13 September 2010 18:26, Charles Wilson wrote:
On 9/13/2010 6:52 AM, JonY wrote:
OK, new headers tarballs up. Thanks for keeping an eye out.
All packages are uploaded.
A big round of applause for JonY, Chuck, and Yaakov for the
On 9/12/2010 10:24 PM, JonY wrote:
On 9/13/2010 01:01, Charles Wilson wrote:
On 9/11/2010 2:07 AM, JonY wrote:
OK, new files are up, same links.
Err...the pthread packages seem to be missing...
Sorry about that, pthreads now uploaded.
OK, all packages rebuild fine from souce. Also, now we
On 9/13/2010 6:52 AM, JonY wrote:
OK, new headers tarballs up. Thanks for keeping an eye out.
All packages are uploaded. Please wait 24 hours until they can
propagate to the mirrors, then post announcements to cygwin-announce.
Please look at the suggested templates here:
On Sep 13 13:26, Charles Wilson wrote:
On 9/13/2010 6:52 AM, JonY wrote:
OK, new headers tarballs up. Thanks for keeping an eye out.
All packages are uploaded. Please wait 24 hours until they can
propagate to the mirrors, then post announcements to cygwin-announce.
Chuck, can you please
On 9/13/2010 2:16 PM, Corinna Vinschen wrote:
Chuck, can you please update http://cygwin.com/cygwin-pkg-maint, too?
Done.
On 13 September 2010 18:26, Charles Wilson wrote:
On 9/13/2010 6:52 AM, JonY wrote:
OK, new headers tarballs up. Thanks for keeping an eye out.
All packages are uploaded.
A big round of applause for JonY, Chuck, and Yaakov for the huge
amount of work they've put into this.
Andy
On 9/11/2010 2:07 AM, JonY wrote:
OK, new files are up, same links.
Err...the pthread packages seem to be missing...
--
Chuck
On 9/13/2010 01:01, Charles Wilson wrote:
On 9/11/2010 2:07 AM, JonY wrote:
OK, new files are up, same links.
Err...the pthread packages seem to be missing...
Sorry about that, pthreads now uploaded.
On 9/10/2010 08:51, JonY wrote:
On 9/10/2010 07:09, Charles Wilson wrote:
On 9/9/2010 6:10 AM, JonY wrote:
OK, we're amost there.
binutils and runtime are GTG.
gcc, headers, and pthreads are really close.
Everything rebuilds from source fine, and the uploaded packages actually
match the
On 9/2/2010 01:35, Charles Wilson wrote:
On 9/1/2010 11:44 AM, JonY wrote:
On 9/1/2010 23:15, Charles Wilson wrote:
On 8/31/2010 11:20 PM, JonY wrote:
On 9/1/2010 10:28, Charles Wilson wrote:
On 8/31/2010 8:52 PM, JonY wrote:
Strange, I'll try a rebuild. The former should be the correct
On 9/9/2010 6:10 AM, JonY wrote:
OK, we're amost there.
binutils and runtime are GTG.
gcc, headers, and pthreads are really close.
Everything rebuilds from source fine, and the uploaded packages actually
match the rebuilt versions (or vice versa). So that's all good. Plus, I
was able to
On 9/10/2010 07:09, Charles Wilson wrote:
On 9/9/2010 6:10 AM, JonY wrote:
OK, we're amost there.
binutils and runtime are GTG.
gcc, headers, and pthreads are really close.
Everything rebuilds from source fine, and the uploaded packages actually
match the rebuilt versions (or vice
On 8/31/2010 11:20 PM, JonY wrote:
On 9/1/2010 10:28, Charles Wilson wrote:
On 8/31/2010 8:52 PM, JonY wrote:
Strange, I'll try a rebuild. The former should be the correct location.
Errr...no. The *latter* is the correct location (at least, that's where
the sysroot'ed compiler will look for
On 9/1/2010 23:15, Charles Wilson wrote:
On 8/31/2010 11:20 PM, JonY wrote:
On 9/1/2010 10:28, Charles Wilson wrote:
On 8/31/2010 8:52 PM, JonY wrote:
Strange, I'll try a rebuild. The former should be the correct location.
Errr...no. The *latter* is the correct location (at least, that's
On 9/1/2010 11:44 AM, JonY wrote:
On 9/1/2010 23:15, Charles Wilson wrote:
On 8/31/2010 11:20 PM, JonY wrote:
On 9/1/2010 10:28, Charles Wilson wrote:
On 8/31/2010 8:52 PM, JonY wrote:
Strange, I'll try a rebuild. The former should be the correct
location.
Errr...no. The *latter* is the
On 8/25/2010 12:19 AM, JonY wrote:
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Here are the packages.
Overall comments: I see you reverted to bundling the DLLs with the
compiler packages (e.g. no separate mingw64-x86_64-libfoo-* tarballs).
While
On 9/1/2010 03:32, Charles Wilson wrote:
On 8/25/2010 12:19 AM, JonY wrote:
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Here are the packages.
Overall comments: I see you reverted to bundling the DLLs with the
compiler packages (e.g. no separate
On 8/31/2010 8:52 PM, JonY wrote:
On 9/1/2010 03:32, Charles Wilson wrote:
Rebuilds fine from source (*), but the binary tarball above is not ok.
It has the headers in the following directory:
usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/
instead of
On 9/1/2010 10:28, Charles Wilson wrote:
On 8/31/2010 8:52 PM, JonY wrote:
On 9/1/2010 03:32, Charles Wilson wrote:
Rebuilds fine from source (*), but the binary tarball above is not ok.
It has the headers in the following directory:
On 8/25/2010 8:14 PM, JonY wrote:
On 8/25/2010 12:19, JonY wrote:
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Ping.
Less than a single day is a bit quick to ping.
I'll take a look at this tonight or tomorrow; thanks for your hard work.
--
Chuck
On 8/26/2010 22:21, Charles Wilson wrote:
On 8/25/2010 8:14 PM, JonY wrote:
On 8/25/2010 12:19, JonY wrote:
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Ping.
Less than a single day is a bit quick to ping.
I'll take a look at this tonight or
On 8/25/2010 12:19, JonY wrote:
Hi,
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Here are the packages.
mingw64-x86_64-pthreads
Hi,
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Here are the packages.
mingw64-x86_64-pthreads
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1.tar.bz2/download
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 7/6/2010 1:10 AM, JonY wrote:
I had a thinko, thanks for the patch. Yeah, cygport moves the libtool
dlls around.
I will recheck on the README file and libobjc-2, I thought I patched up
the configure file.
You did, but...
Alright, I repackaged binutils to add the /etc/profile.d scripts
On 7/6/2010 23:36, Charles Wilson wrote:
On 7/6/2010 1:10 AM, JonY wrote:
I had a thinko, thanks for the patch. Yeah, cygport moves the libtool
dlls around.
I will recheck on the README file and libobjc-2, I thought I patched up
the configure file.
You did, but...
Alright, I repackaged
On 7/6/2010 11:59 AM, JonY wrote:
On 7/6/2010 23:36, Charles Wilson wrote:
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 did this too with the libstdc++-v3,
On 7/7/2010 04:26, Charles Wilson wrote:
On 7/6/2010 11:59 AM, JonY wrote:
On 7/6/2010 23:36, Charles Wilson wrote:
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.
On 7/2/2010 2:36 AM, JonY wrote:
Here are the GCC links. I hope I got them all.
mingw64-m32-libgcc1-4.6.20100619-1.tar.bz2
mingw64-m32-libgfortran3-4.6.20100619-1.tar.bz2
mingw64-m32-libgomp1-4.6.20100619-1.tar.bz2
mingw64-m32-libobjc2-4.6.20100619-1.tar.bz2
OK, a bit further along. With the recently posted patch to cygport:
http://cygwin.com/ml/cygwin/2010-07/msg00117.html
AND the attached patch to your .cygport script, I get a bit further with
the install step. It completes without error (but I still have the
warning about the missing
On 7/6/2010 01:38, Charles Wilson wrote:
OK, a bit further along. With the recently posted patch to cygport:
http://cygwin.com/ml/cygwin/2010-07/msg00117.html
AND the attached patch to your .cygport script, I get a bit further with
the install step. It completes without error (but I still have
On 7/6/2010 09:33, JonY wrote:
On 7/6/2010 01:38, Charles Wilson wrote:
OK, a bit further along. With the recently posted patch to cygport:
http://cygwin.com/ml/cygwin/2010-07/msg00117.html
AND the attached patch to your .cygport script, I get a bit further with
the install step. It completes
Hi,
New copies are up, no changes to CRT. All have the same links except for
pthreads. libgomp requires: is also fixed due to pthreads change.
I hope I'm not getting sloppy.
mingw64-tc64-m64-libpthread-devel
On Sun, Jul 4, 2010 at 12:26 AM, Andy Koppe andy.ko...@gmail.com wrote:
PERHAPS it makes the most sense to provide two single-target compilers
(but most of the interop issues would remain; the only simplification
would be the elimination of any packages that are explicitly
On 3 July 2010 03:07, Charles Wilson wrote:
Is mingw64 already part of a major Linux distribution? Otherwise it
needs five votes from Cygwin maintainers.
AFAICT, mingw64 is the mingw cross compiler provided by fedora.
Great.
Finally, I'm not sure what the conclusion was about which
On 7/3/2010 2:28 AM, Andy Koppe wrote:
On 3 July 2010 03:07, Charles Wilson wrote:
Is mingw64 already part of a major Linux distribution? Otherwise it
needs five votes from Cygwin maintainers.
AFAICT, mingw64 is the mingw cross compiler provided by fedora.
Great.
Finally, I'm not sure
On 7/3/2010 1:44 PM, JonY wrote:
On 7/3/2010 11:27, Charles Wilson wrote:
Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8
(and cygwin, of course, but that is never included in requires:).
It doesn't? I thought I saw -lz linked in for some executables. OK, will
On 7/4/2010 04:04, Charles Wilson wrote:
On 7/3/2010 1:44 PM, JonY wrote:
On 7/3/2010 11:27, Charles Wilson wrote:
Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8
(and cygwin, of course, but that is never included in requires:).
It doesn't? I thought I saw -lz linked
On 7/3/2010 9:17 PM, JonY wrote:
On 7/4/2010 04:04, Charles Wilson wrote:
On 7/3/2010 1:44 PM, JonY wrote:
On 7/3/2010 11:27, Charles Wilson wrote:
Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8
(and cygwin, of course, but that is never included in requires:).
It
On 7/4/2010 12:41, Charles Wilson wrote:
On 7/3/2010 9:17 PM, JonY wrote:
On 7/4/2010 04:04, Charles Wilson wrote:
On 7/3/2010 1:44 PM, JonY wrote:
On 7/3/2010 11:27, Charles Wilson wrote:
Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8
(and cygwin, of course, but
Hi,
Here are the GCC links. I hope I got them all.
mingw64-tc64-gcc4:
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-gcc4-4.6.20100619-1-src.tar.bz2/download
I forgot to mention, don't upload GCC first, I need to confirm the
nature of the gcc bug with Kai.
Some GCC headers are needlessly shadowing the system headers.
On 7/2/2010 14:38, JonY wrote:
I forgot to mention, don't upload GCC first, I need to confirm the
nature of the gcc bug with Kai.
Some GCC headers are needlessly shadowing the system headers.
OK to upload if packaging is fine, no changes needed.
On 2 July 2010 08:17, JonY wrote:
OK to upload if packaging is fine, no changes needed.
Great to see mingw64 coming to Cygwin, but I think the upload should
wait until Cygwin gcc maintainer Dave Korn has had a chance to comment
on this.
Is mingw64 already part of a major Linux distribution?
On Fri, Jul 2, 2010 at 1:41 PM, Andy Koppe andy.ko...@gmail.com wrote:
Is mingw64 already part of a major Linux distribution? Otherwise it
needs five votes from Cygwin maintainers.
Ubuntu, Debian, and Fedora.
Also, are you sure that gcc-4.6 is sufficiently stable for release,
i.e. that there
On 7/2/2010 1:41 PM, Andy Koppe wrote:
On 2 July 2010 08:17, JonY wrote:
OK to upload if packaging is fine, no changes needed.
Great to see mingw64 coming to Cygwin, but I think the upload should
wait until Cygwin gcc maintainer Dave Korn has had a chance to comment
on this.
I agree.
I am a little surprised that you got this to work simply by passing
--prefix=/opt/mingw64/... and a few other flags. Last time I looked
closely, cygport assumed /usr in quite a few places. Maybe that's
changed; if so, cool!
On 7/2/2010 1:29 AM, JonY wrote:
mingw64-tc64-headers:
...
category:
On 6/30/2010 7:12 PM, Charles Wilson wrote:
Do also give the ability to tell cygport to exclude some libtool files
from getting fixed up, thanks.
Again, I *think* you can suppress this; I'll check tomorrow.
No, apparently you can't (yet) do this. It's fairly easy to add,
though. I'll try
On 6/30/2010 3:50 PM, Charles Wilson wrote:
On 6/30/2010 1:51 PM, JonY wrote:
Right now, human intervention still needed. cygport messes up the target
dll locations by moving them around and trying to fix libtool files. Its
also using cygwin strip(1) to strip 64bit dlls, it fails but doesn't
Hi,
new uploads done. GCC links in the next mail.
mingw64-tc64-headers:
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-headers/mingw64-tc64-headers-20100701-1-src.tar.bz2/download
On 6/29/2010 1:13 PM, JonY wrote:
On 6/30/2010 00:10, Charles Wilson wrote:
Now, I thought you wanted to use the w64 prefix as a project origin
indicator, and assumed that -mingw64- would be the target bitdepth
indicator. However, given w64-mingw64-pthreads-devel32 and
As an aside, to compile with a different prefix using cygport requires a
bit of work right now, because AFAIK cygport doesn't support anything
but --prefix=/usr.
See
http://cygwin.osuosl.org/release/autoconf/gcc-tools-epoch2-autoconf/gcc-tools-epoch2-autoconf-2.64-1-src.tar.bz2
for how I did
On 7/1/2010 00:36, Charles Wilson wrote:
On 6/29/2010 1:13 PM, JonY wrote:
On 6/30/2010 00:10, Charles Wilson wrote:
Now, I thought you wanted to use the w64 prefix as a project origin
indicator, and assumed that -mingw64- would be the target bitdepth
indicator. However, given
On 7/1/2010 00:49, Charles Wilson wrote:
As an aside, to compile with a different prefix using cygport requires a
bit of work right now, because AFAIK cygport doesn't support anything
but --prefix=/usr.
See
On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson
cyg...@cwilson.fastmail.fm wrote:
Hmm. So, big picture, we have possibly three different mingw-ish compilers,
and you're currently attempting to shepherd the first one, while being
mindful of future issues related to simultaneous installation of
On 6/30/2010 2:53 PM, NightStrike wrote:
On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson wrote:
Hmm. So, big picture, we have possibly three different mingw-ish compilers,
and you're currently attempting to shepherd the first one, while being
mindful of future issues related to simultaneous
On Wed, Jun 30, 2010 at 3:34 PM, Charles Wilson
cyg...@cwilson.fastmail.fm wrote:
On 6/30/2010 2:53 PM, NightStrike wrote:
On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson wrote:
Hmm. So, big picture, we have possibly three different mingw-ish
compilers,
and you're currently attempting to
On 6/30/2010 1:51 PM, JonY wrote:
On 7/1/2010 00:36, Charles Wilson wrote:
I don't know much about sf's buildbot; I assume that if you can get a
cygport to DTRT on your home PC without human intervention except for
kicking off the build, then you can convince the buildbot to do it for
you?
On 6/30/2010 2:06 PM, JonY wrote:
Thanks, I will check it out. (btw, libtool too needs to get an epoch
version, having problems with macro version mismatches in gcc
cygautoreconf).
Oh boy. Yeah, I would imagine so. The gcc-tools-* stuff was added to
support Dave Korn's needs when building
On 6/29/2010 12:56, NightStrike wrote:
On Mon, Jun 28, 2010 at 11:27 PM, JonYjo...@users.sourceforge.net wrote:
Sourceforge doesn't have an FTP, it makes things a bit hard, I'll try to get
an FTP server soon. Basically, its everything under:
On 6/28/2010 15:16, JonY wrote:
On 6/28/2010 14:53, Charles Wilson wrote:
If you *really* want to prefix everything with w64 to indicate which
compiler family they belong to, then something like
w64-mingw64-libgcc1
w64-mingw64-libstdc++6
w64-mingw64-libgfortran3
or
On 6/30/2010 00:10, Charles Wilson wrote:
On 6/28/2010 15:16, JonY wrote:
On 6/28/2010 14:53, Charles Wilson wrote:
If you *really* want to prefix everything with w64 to indicate which
compiler family they belong to, then something like
w64-mingw64-libgcc1
On 6/27/2010 8:32 PM, JonY wrote:
On 6/26/2010 19:59, JonY wrote:
Hello,
mingw-w64 (mingw-w64.sourceforge.net) is a toolchain to target 64bit
windows. It is setup as a cygwin hosted cross compiler. Currently it is
split into 4 packages: headers, crt, binutils and gcc. The latter 2 is
from
On 6/28/2010 14:53, Charles Wilson wrote:
On 6/27/2010 8:32 PM, JonY wrote:
On 6/26/2010 19:59, JonY wrote:
Hello,
mingw-w64 (mingw-w64.sourceforge.net) is a toolchain to target 64bit
windows. It is setup as a cygwin hosted cross compiler. Currently it is
split into 4 packages: headers, crt,
On 6/28/2010 15:16, JonY wrote:
On 6/28/2010 14:53, Charles Wilson wrote:
On 6/27/2010 8:32 PM, JonY wrote:
On 6/26/2010 19:59, JonY wrote:
Hello,
mingw-w64 (mingw-w64.sourceforge.net) is a toolchain to target 64bit
windows. It is setup as a cygwin hosted cross compiler. Currently it is
split
On Mon, Jun 28, 2010 at 11:27 PM, JonY jo...@users.sourceforge.net wrote:
Sourceforge doesn't have an FTP, it makes things a bit hard, I'll try to get
an FTP server soon. Basically, its everything under:
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/
Is FTP
On 6/27/2010 21:10, NightStrike wrote:
On Sat, Jun 26, 2010 at 7:59 AM, JonYjo...@users.sourceforge.net wrote:
mingw-w64 gcc-rt (runtime):
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w64-gcc/w64-gcc-rt/w64-gcc-rt-4.6.20100619-1.tar.bz2
On 6/26/2010 19:59, JonY wrote:
Hello,
mingw-w64 (mingw-w64.sourceforge.net) is a toolchain to target 64bit
windows. It is setup as a cygwin hosted cross compiler. Currently it is
split into 4 packages: headers, crt, binutils and gcc. The latter 2 is
from FSF.
GCC 4.6 (trunk) was chosen to
74 matches
Mail list logo
