Latest 64 bit test stuff on sourceware

[Corinna Vinschen]

Hi guys,

I just uploaded all the stuff I have 64 bit-wise to the sourceware ftp
area. See ftp://cygwin.com/pub/cygwin/64bit/

What you see there is this:

- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130209.tar.xz

This >80 Megs archive contains a binary toolchain dir, representing
the full cross-build toolchain for x86_64 Linux, targeting
x86_64-pc-cygwin. This toolchain allows to build 64 bit Cygwin as
well as 64 bit Cygwin binaries. Only C and C++ are supported as
languages, since that's all I need. libgcc and libstdc++ only exist
as static libs so far.

After unpacking you get a directory called x86_64-pc-cygwin. Assuming
you install to /opt, just add /opt/x86_64-pc-cygwin/bin to $PATH and
you should be all set. Again, this is a toolchain only running on
x86_64 Linux. I'm using it on Fedora 17 right now.

- x86_64-pc-cygwin-binutils-20130209.patch
- x86_64-pc-cygwin-gcc-20130209.patch

These are the current patchsets to binutils and gcc, relative to
current CVS/SVN HEAD. The problem I described in my mail
http://cygwin.com/ml/cygwin-developers/2013-02/msg00009.html
is yet unsolved, but the required changes to gcc to support that
scenario will be addresses by my collegue Kai Tietz within this
month.

- 64bit-testdir-20130209.tar.xz

This is the full set of 64 bit binaries I have right now, apart from
cygserver, which I missed to include. The set consists of the
cygwin DLL, the Cygwin utils, a dash shell, and a tool called
cat-maps, which I hacked to print out /proc/$PID/maps of a 64 bit
process. In fact, it's a simple cat(1), but only for printing the
maps file. Why not cat? Easy: cat-maps also works outside of a
Cygwin shell...

However, what's also include is a subdir called mingw64-gdb. That
subdir contains what the name implies, a x86_64 Mingw GDB targeting
x86_64 Windows. This GDB is *extremly* helpful to track down
problems in 64 bit Cygwin. Apart from that, strace also seems to
work quite nicely.

Please note, even if you can start 64 bit Cygwin processes from
32 bit Cygwin and vice versa, there's no real interaction between
32 and 64 bit Cygwin processes yet, especially not at execve time.
Don't try to run 64 bit processes from 32 bit mintty, it won't
work as expected. Use a Windows console for now.

- What's missing are the Cygwin sources, but you can easily fetch them
from the Cygwin CVS repo:

cvs -d :pserver:anoncvs-rDBXBDvO6BXQT0dZR+***@public.gmane.org co -r cygwin-64bit-branch winsup

Play with this all you like. If you find bugs, please report them to
this list. As usual, the best way to report bugs is to send patches.
Apart from that, I'm grateful if you use the included GDB to try to
track down the problem or, baring that, use strace and/or write a
testcase.


Peace,
Corinna

[Andy Koppe]

Post by Corinna Vinschen
Hi guys,
I just uploaded all the stuff I have 64 bit-wise to the sourceware ftp
area. See ftp://cygwin.com/pub/cygwin/64bit/
- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130209.tar.xz
This >80 Megs archive contains a binary toolchain dir, representing
the full cross-build toolchain for x86_64 Linux, targeting
x86_64-pc-cygwin. This toolchain allows to build 64 bit Cygwin as
well as 64 bit Cygwin binaries. Only C and C++ are supported as
languages, since that's all I need. libgcc and libstdc++ only exist
as static libs so far.
After unpacking you get a directory called x86_64-pc-cygwin. Assuming
you install to /opt, just add /opt/x86_64-pc-cygwin/bin to $PATH and
you should be all set. Again, this is a toolchain only running on
x86_64 Linux. I'm using it on Fedora 17 right now.

Great to see this. I tried building mintty with it. After a bit of
makefile hacking I got it to compile, albeit a bunch of warning that
I'll need to address. Linking failed due to undefined references
select() and gethostname() though, so I guess they're not implemented
yet?

Post by Corinna Vinschen
- x86_64-pc-cygwin-binutils-20130209.patch
- x86_64-pc-cygwin-gcc-20130209.patch
These are the current patchsets to binutils and gcc, relative to
current CVS/SVN HEAD. The problem I described in my mail
http://cygwin.com/ml/cygwin-developers/2013-02/msg00009.html
is yet unsolved, but the required changes to gcc to support that
scenario will be addresses by my collegue Kai Tietz within this
month.

Is it worth attempting to build the toolchain on current Cygwin?

Andy

[Yaakov (Cygwin/X)]

Post by Andy Koppe

Post by Corinna Vinschen
- x86_64-pc-cygwin-binutils-20130209.patch
- x86_64-pc-cygwin-gcc-20130209.patch
These are the current patchsets to binutils and gcc, relative to
current CVS/SVN HEAD. The problem I described in my mail
http://cygwin.com/ml/cygwin-developers/2013-02/msg00009.html
is yet unsolved, but the required changes to gcc to support that
scenario will be addresses by my collegue Kai Tietz within this
month.

Is it worth attempting to build the toolchain on current Cygwin?

I'm in the process of doing so now.


Yaakov

[Corinna Vinschen]

Post by Andy Koppe

Post by Corinna Vinschen
Hi guys,
I just uploaded all the stuff I have 64 bit-wise to the sourceware ftp
area. See ftp://cygwin.com/pub/cygwin/64bit/
- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130209.tar.xz
This >80 Megs archive contains a binary toolchain dir, representing
the full cross-build toolchain for x86_64 Linux, targeting
x86_64-pc-cygwin. This toolchain allows to build 64 bit Cygwin as
well as 64 bit Cygwin binaries. Only C and C++ are supported as
languages, since that's all I need. libgcc and libstdc++ only exist
as static libs so far.
After unpacking you get a directory called x86_64-pc-cygwin. Assuming
you install to /opt, just add /opt/x86_64-pc-cygwin/bin to $PATH and
you should be all set. Again, this is a toolchain only running on
x86_64 Linux. I'm using it on Fedora 17 right now.

Great to see this. I tried building mintty with it. After a bit of
makefile hacking I got it to compile, albeit a bunch of warning that
I'll need to address. Linking failed due to undefined references
select() and gethostname() though, so I guess they're not implemented
yet?

It's a bug. I noticed the same yesterday when I was trying to track
down a problem with an undefined gethostbyname symbol. I found that
there are two problems. In the first place I screwed up cygwin64.din
and a couple of symbols were missing. But even if I fix it, I can't
use gethostbyname since the application doesn't start due to a missing
symbol. Right now it *seems* that the 64 bit linker doesn't correctly
evaluate the `foo = bar' expressions in the .def file for somae reason.
But I'm still investigating.

Post by Andy Koppe

Post by Corinna Vinschen
- x86_64-pc-cygwin-binutils-20130209.patch
- x86_64-pc-cygwin-gcc-20130209.patch
These are the current patchsets to binutils and gcc, relative to
current CVS/SVN HEAD. The problem I described in my mail
http://cygwin.com/ml/cygwin-developers/2013-02/msg00009.html
is yet unsolved, but the required changes to gcc to support that
scenario will be addresses by my collegue Kai Tietz within this
month.

Is it worth attempting to build the toolchain on current Cygwin?

I was going to ask, but it seems a bit early. The above problem is
a real showstopper.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Andy Koppe

Post by Corinna Vinschen
Hi guys,
I just uploaded all the stuff I have 64 bit-wise to the sourceware ftp
area. See ftp://cygwin.com/pub/cygwin/64bit/
- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130209.tar.xz
This >80 Megs archive contains a binary toolchain dir, representing
the full cross-build toolchain for x86_64 Linux, targeting
x86_64-pc-cygwin. This toolchain allows to build 64 bit Cygwin as
well as 64 bit Cygwin binaries. Only C and C++ are supported as
languages, since that's all I need. libgcc and libstdc++ only exist
as static libs so far.
After unpacking you get a directory called x86_64-pc-cygwin. Assuming
you install to /opt, just add /opt/x86_64-pc-cygwin/bin to $PATH and
you should be all set. Again, this is a toolchain only running on
x86_64 Linux. I'm using it on Fedora 17 right now.

Great to see this. I tried building mintty with it. After a bit of
makefile hacking I got it to compile, albeit a bunch of warning that
I'll need to address. Linking failed due to undefined references
select() and gethostname() though, so I guess they're not implemented
yet?

It's a bug. I noticed the same yesterday when I was trying to track
down a problem with an undefined gethostbyname symbol. I found that
there are two problems. In the first place I screwed up cygwin64.din
and a couple of symbols were missing. But even if I fix it, I can't
use gethostbyname since the application doesn't start due to a missing
symbol. Right now it *seems* that the 64 bit linker doesn't correctly
evaluate the `foo = bar' expressions in the .def file for somae reason.
But I'm still investigating.

And good that I did. The problem is fixed by my today's checkin.
The *other* problem was not an ld problem, but a corinna problem.
It's quite tricky to test a fix when accidentally debugging the
wrong DLL all the time...

Post by Corinna Vinschen

Post by Andy Koppe
Is it worth attempting to build the toolchain on current Cygwin?

I was going to ask, but it seems a bit early. The above problem is
a real showstopper.

Nope, no showstopper here. Oh well.


Corinna

[Yaakov (Cygwin/X)]

Post by Corinna Vinschen
This >80 Megs archive contains a binary toolchain dir, representing
the full cross-build toolchain for x86_64 Linux, targeting
x86_64-pc-cygwin. This toolchain allows to build 64 bit Cygwin as
well as 64 bit Cygwin binaries. Only C and C++ are supported as
languages, since that's all I need. libgcc and libstdc++ only exist
as static libs so far.

I tried building the latest GCC snapshot with your patch, and my
attempt to build libgcc shared failed. Known issue?


Yaakov

[Corinna Vinschen]

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
This >80 Megs archive contains a binary toolchain dir, representing
the full cross-build toolchain for x86_64 Linux, targeting
x86_64-pc-cygwin. This toolchain allows to build 64 bit Cygwin as
well as 64 bit Cygwin binaries. Only C and C++ are supported as
languages, since that's all I need. libgcc and libstdc++ only exist
as static libs so far.

I tried building the latest GCC snapshot with your patch, and my
attempt to build libgcc shared failed. Known issue?

Honestly? I have no idea. Not much time has been spent on the
toolchain yet, only what was necessary to get it working to build newlib
and Cygwin. This is all still on the TODO list.


Corinna

[Yaakov (Cygwin/X)]

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)
I tried building the latest GCC snapshot with your patch, and my
attempt to build libgcc shared failed. Known issue?

Honestly? I have no idea. Not much time has been spent on the
toolchain yet, only what was necessary to get it working to build newlib
and Cygwin. This is all still on the TODO list.

Re-reading the related threads, I see this is indeed a known issue,
specifically with pc-relative relocations in auto-import[1]. However, I
was able to build zlib, including minizip (which uses libtool), albeit
with the "cyg" prefix for the moment.


Yaakov

[1] http://cygwin.com/ml/cygwin-developers/2013-02/msg00009.html

[Corinna Vinschen]

Post by Corinna Vinschen
Hi guys,
I just uploaded all the stuff I have 64 bit-wise to the sourceware ftp
area. See ftp://cygwin.com/pub/cygwin/64bit/

What's new:

- x86_64-pc-cygwin-gcc-20130211.patch

Fixes two problems, one the incorrectly defined DWARF2_UNWIND_INFO
in gcc/config/i386/cygming.h, the other a problem with undefined
weak symbols in libgcc/config/i386/cygming-crtbegin.c.

- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130211.tar.xz

Apart from the aforementioned fixes, the toolchain executables are now
stripped so the size shrank to ~30 Megs.

A libtermcap.a is included now, too, using the sources from the FSF.
I needed this to build tcsh.

- 64bit-testdir-20130211.tar.xz

Now contains a bin and etc dir, a simple cat and *drumrolls* tcsh.
The etc dir consists of a termcap file and a simple fstab naming
the cygdrive dir /mnt.


Corinna

[Andy Koppe]

Post by Corinna Vinschen

Post by Corinna Vinschen
Hi guys,
I just uploaded all the stuff I have 64 bit-wise to the sourceware ftp
area. See ftp://cygwin.com/pub/cygwin/64bit/

- x86_64-pc-cygwin-gcc-20130211.patch
Fixes two problems, one the incorrectly defined DWARF2_UNWIND_INFO
in gcc/config/i386/cygming.h, the other a problem with undefined
weak symbols in libgcc/config/i386/cygming-crtbegin.c.
- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130211.tar.xz
Apart from the aforementioned fixes, the toolchain executables are now
stripped so the size shrank to ~30 Megs.
A libtermcap.a is included now, too, using the sources from the FSF.
I needed this to build tcsh.
- 64bit-testdir-20130211.tar.xz
Now contains a bin and etc dir, a simple cat and *drumrolls* tcsh.
The etc dir consists of a termcap file and a simple fstab naming
the cygdrive dir /mnt.

Thanks! With this, mintty now links, and after a couple of fixes it
actually works, amazingly enough. You can get it from here:

http://mintty.googlecode.com/files/mintty-r1295-cygwin64.zip

Just drop mintty.exe into the testdirs' bin folder and invoke with
/bin/dash or /bin/tcsh as argument.

(Sorry, I haven't checked in the source tweaks yet.)

Andy

[Corinna Vinschen]

Post by Andy Koppe

Post by Corinna Vinschen

Post by Corinna Vinschen
Hi guys,
I just uploaded all the stuff I have 64 bit-wise to the sourceware ftp
area. See ftp://cygwin.com/pub/cygwin/64bit/

- x86_64-pc-cygwin-gcc-20130211.patch
Fixes two problems, one the incorrectly defined DWARF2_UNWIND_INFO
in gcc/config/i386/cygming.h, the other a problem with undefined
weak symbols in libgcc/config/i386/cygming-crtbegin.c.
- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130211.tar.xz
Apart from the aforementioned fixes, the toolchain executables are now
stripped so the size shrank to ~30 Megs.
A libtermcap.a is included now, too, using the sources from the FSF.
I needed this to build tcsh.
- 64bit-testdir-20130211.tar.xz
Now contains a bin and etc dir, a simple cat and *drumrolls* tcsh.
The etc dir consists of a termcap file and a simple fstab naming
the cygdrive dir /mnt.

Thanks! With this, mintty now links, and after a couple of fixes it
http://mintty.googlecode.com/files/mintty-r1295-cygwin64.zip
Just drop mintty.exe into the testdirs' bin folder and invoke with
/bin/dash or /bin/tcsh as argument.

Wow, super! I'm just tracking down a problem in cygheap management,
but after that I will download mintty and play with it.


Thanks,
Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Andy Koppe

Post by Corinna Vinschen

Post by Corinna Vinschen
Hi guys,
I just uploaded all the stuff I have 64 bit-wise to the sourceware ftp
area. See ftp://cygwin.com/pub/cygwin/64bit/

- x86_64-pc-cygwin-gcc-20130211.patch
Fixes two problems, one the incorrectly defined DWARF2_UNWIND_INFO
in gcc/config/i386/cygming.h, the other a problem with undefined
weak symbols in libgcc/config/i386/cygming-crtbegin.c.
- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130211.tar.xz
Apart from the aforementioned fixes, the toolchain executables are now
stripped so the size shrank to ~30 Megs.
A libtermcap.a is included now, too, using the sources from the FSF.
I needed this to build tcsh.
- 64bit-testdir-20130211.tar.xz
Now contains a bin and etc dir, a simple cat and *drumrolls* tcsh.
The etc dir consists of a termcap file and a simple fstab naming
the cygdrive dir /mnt.

Thanks! With this, mintty now links, and after a couple of fixes it
http://mintty.googlecode.com/files/mintty-r1295-cygwin64.zip
Just drop mintty.exe into the testdirs' bin folder and invoke with
/bin/dash or /bin/tcsh as argument.

Wow, super! I'm just tracking down a problem in cygheap management,
but after that I will download mintty and play with it.

Works fine. I'm impressed, given the bug in Cygwin I just found :)


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen
Hi guys,
I just uploaded all the stuff I have 64 bit-wise to the sourceware ftp
area. See ftp://cygwin.com/pub/cygwin/64bit/

What's new:

- 64bit-testdir-20130212.tar.xz

Now comes with mintty and the full set of native binutils.
ld will already use the 0x4:00000000 - 0x6:00000000 region
for --auto-image-base.

Corinna

[Teemu Nätkinniemi]

I've tried building a native GCC and it actually runs on Windows but
when trying to compile Hello World I get the following error:

Program received signal SIGSEGV, Segmentation fault.
0x000007fb2ec81e3f in bcryptPrimitives!ProcessPrng ()
from C:\Windows\SYSTEM32\bcryptprimitives.dll

I am in the process of building a debug version to see if I can get
any more information about the crash.

Attached is a small patch to config.host that enables .exe extension
to compiled files.

[Corinna Vinschen]

Post by Teemu Nätkinniemi
I've tried building a native GCC and it actually runs on Windows but
Program received signal SIGSEGV, Segmentation fault.
0x000007fb2ec81e3f in bcryptPrimitives!ProcessPrng ()
from C:\Windows\SYSTEM32\bcryptprimitives.dll
I am in the process of building a debug version to see if I can get
any more information about the crash.
Attached is a small patch to config.host that enables .exe extension
to compiled files.

I have that already locally. I'm just in the process to add
configuration stuff missing for a native toolchain build. I'll upload
some of this stuff shortly, but right now I'm still stuttering along.

Stay tuned,
Corinna

[Teemu Nätkinniemi]

I managed to compile native version of coreutils, using Cygwin's patched
sources. I might actually compile cygport as I had to manually edit
Makefile to get lib/cygwin.c compiling. This is obviously not very
secure and might cause problems with Windows but at least uname now
shows correct information:

http://www.mediafire.com/?awc2odc9ld8zbd8

[Corinna Vinschen]

Post by Teemu Nätkinniemi
I managed to compile native version of coreutils, using Cygwin's
patched sources. I might actually compile cygport as I had to
manually edit Makefile to get lib/cygwin.c compiling. This is
obviously not very secure and might cause problems with Windows but
http://www.mediafire.com/?awc2odc9ld8zbd8

Cool.

Btw., I just uploaded new patchsets for binutils and gcc to

ftp://cygwin.com/pub/cygwin/64bit/x86_64-pc-cygwin-binutils-20130213.patch
ftp://cygwin.com/pub/cygwin/64bit/x86_64-pc-cygwin-gcc-20130213.patch


Corinna

[Teemu Nätkinniemi]

Post by Corinna Vinschen
Btw., I just uploaded new patchsets for binutils and gcc to
ftp://cygwin.com/pub/cygwin/64bit/x86_64-pc-cygwin-binutils-20130213.patch
ftp://cygwin.com/pub/cygwin/64bit/x86_64-pc-cygwin-gcc-20130213.patch

Ok, with this I got the compiler working. It doesn't seem to find any
headers or libraries without specifying the directories but at least it
does what it is supposed to do.

[Corinna Vinschen]

Hi guys,

I just uploaded all the latest 64 bit stuff to
ftp://cygwin.com/pub/cygwin/64bit/

The main change here is what has been discussed in
http://cygwin.com/ml/cygwin-developers/2013-02/msg00029.html

- The cygwin DLL is named cygwin1.dll rather than cyg64win1.dll.
- The DLL library prefix is "cyg" rather than "cyg64".
- The link library search path is /usr/lib, rather than /usr/lib64.

Here's what you get:

- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130215.tar.xz

A complete binary x86_64 Linux cross toolchain, latest patches.
Otherwise, business as usual:

After unpacking you get a directory called x86_64-pc-cygwin.
Assuming you install to /opt, just add /opt/x86_64-pc-cygwin/bin to
$PATH and you should be all set.

- x86_64-pc-cygwin-binutils-20130215.patch
- x86_64-pc-cygwin-gcc-20130215.patch

Latest patchsets to binutils and gcc, relative to current CVS/SVN
HEAD. The solution for the problem described in
http://cygwin.com/ml/cygwin-developers/2013-02/msg00009.html is
still in the works.

- bootstrap.sh

The script to bootstrap cross toolchain, cygwin, native toolchain.

- 64bit-testdir-20130215.tar.xz

Full set of 64 bit binaries I have right now, including (entirely
untested) cygserver, and a native toolchain with gcc and g++,
which is the reason the archive got a teensy little bit bigger.

A simple cat, dash, tcsh, and mintty are included, too. cat, dash,
and tcsh are rebuilt versions. Mintty works because I hexedited
"cygwin1.dll" into the binary ;)

Still include is a subdir called mingw64-gdb with an x86_64 Mingw
GDB targeting x86_64 Windows for easy debugging.

- As always, the Cygwin sources are in the CVS repo:

cvs -d :pserver:anoncvs-rDBXBDvO6BXQT0dZR+***@public.gmane.org co -r cygwin-64bit-branch winsup

If you find bugs, please report them to this list. As usual, the best
way to report bugs is to send patches. Apart from that, I'm grateful if
you use the included GDB to try to track down the problem or, baring
that, use strace and/or write a testcase.


Live long and prosper,
Corinna

[Corinna Vinschen]

Post by Corinna Vinschen
Hi guys,
I just uploaded all the latest 64 bit stuff to
ftp://cygwin.com/pub/cygwin/64bit/

I just added a few packages to that site. Just unpack in your
64 bit root dir:

file-5.11-1.x86_64.tar.xz
gawk-4.0.2-1.x86_64.tar.xz
sed-4.2.1-1.x86_64.tar.xz

File is the first package which also comes with a x86_64 DLL.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen
Hi guys,
I just uploaded all the latest 64 bit stuff to
ftp://cygwin.com/pub/cygwin/64bit/

I just added a few packages to that site. [...]

This morning I changed the layout of the aforementioned dir. The
toplevel only contains the non-native stuff:

binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130215.tar.xz
bootstrap.sh
x86_64-pc-cygwin-binutils-20130215.patch
x86_64-pc-cygwin-gcc-20130215.patch

There's a new subdir called install, I filled with the packages require
to get us up to speed. Except for mintty, which I borrowed from Andi,
and mingw-gdb, which Kai built for us, I cross built all of them on
Linux to collect a basic set of tools we need to build and debug
subsequent packages.

None of these packages is fit for a distro, but they should basically
work, and especially help to create distro packages, for instance, all
the library packages missing yet (libintl, libiconv, libreadline, etc).
At least typical configure scripts should run now.

Here's the list of packages I prepared:

base-cygwin-toolchain-install-first-20130216.x86_64.tar.xz
coreutils-8.14-1.x86_64.tar.xz
dash-0.5.7-1.x86_64.tar.xz
file-5.11-1.x86_64.tar.xz
findutils-4.5.9-2.x86_64.tar.xz
gawk-4.0.2-1.x86_64.tar.xz
grep-2.6.3-1.x86_64.tar.xz
m4-1.4.16-1.x86_64.tar.xz
make-3.82-1.x86_64.tar.xz
md5.sum
mingw-gdb.x86_64.tar.xz
mintty-r1295.x86_64.tar.xz
rebase-4.4.0-1.x86_64.tar.xz
sed-4.2.1-1.x86_64.tar.xz
tar-1.26-1.x86_64.tar.xz
tcsh-6.18.01-1.x86_64.tar.xz

For installation, start with untar'ing the base-cygwin-* package, which
contains cygwin itself and the native toolchain. Then untar all the
other packages on top if it. In the end, you have dash/sh, and tcsh to
work with. What you need to provide yourself are passwd and group
files, as well as fstab and personal profiles to fit your needs.

Yaakov, care to provide a quick-and-dirty vim package and, maybe, a
cygport for x86_64? Or is anything missing to get cygport running
natively? Since you have upload privs anyway, just upload what you can
create easily. Don't look for man pages or locale files, just the bare
tools would suffice, I guess.


Corinna

[Peter Rosin]

Post by Corinna Vinschen

Post by Corinna Vinschen
Hi guys,
I just uploaded all the latest 64 bit stuff to
ftp://cygwin.com/pub/cygwin/64bit/

I just added a few packages to that site. [...]

This morning I changed the layout of the aforementioned dir. The
binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130215.tar.xz
bootstrap.sh
x86_64-pc-cygwin-binutils-20130215.patch
x86_64-pc-cygwin-gcc-20130215.patch
There's a new subdir called install, I filled with the packages require
to get us up to speed. Except for mintty, which I borrowed from Andi,
and mingw-gdb, which Kai built for us, I cross built all of them on
Linux to collect a basic set of tools we need to build and debug
subsequent packages.
None of these packages is fit for a distro, but they should basically
work, and especially help to create distro packages, for instance, all
the library packages missing yet (libintl, libiconv, libreadline, etc).
At least typical configure scripts should run now.
base-cygwin-toolchain-install-first-20130216.x86_64.tar.xz
coreutils-8.14-1.x86_64.tar.xz
dash-0.5.7-1.x86_64.tar.xz
file-5.11-1.x86_64.tar.xz
findutils-4.5.9-2.x86_64.tar.xz
gawk-4.0.2-1.x86_64.tar.xz
grep-2.6.3-1.x86_64.tar.xz
m4-1.4.16-1.x86_64.tar.xz
make-3.82-1.x86_64.tar.xz
md5.sum
mingw-gdb.x86_64.tar.xz
mintty-r1295.x86_64.tar.xz
rebase-4.4.0-1.x86_64.tar.xz
sed-4.2.1-1.x86_64.tar.xz
tar-1.26-1.x86_64.tar.xz
tcsh-6.18.01-1.x86_64.tar.xz
For installation, start with untar'ing the base-cygwin-* package, which
contains cygwin itself and the native toolchain. Then untar all the
other packages on top if it. In the end, you have dash/sh, and tcsh to
work with. What you need to provide yourself are passwd and group
files, as well as fstab and personal profiles to fit your needs.

Hi!

I tried this out a little bit. Neat stuff!

Some comments:

1. base-cygwin...tar.xz puts its binaries in /bin, but gcc
et al expects to be in /usr/bin (I think, at least that was
the case in the previous version of that tarball). The other
tarballs but their binaries in /usr/bin. The default mounts:

$ mount
C:/Cygwin/opt/bin on /usr/bin type ntfs (binary,auto)
C:/Cygwin/opt/lib on /usr/lib type ntfs (binary,auto)
C:/Cygwin/opt on / type ntfs (binary,auto)
...

"joins" /bin and /usr/bin as usual but I have found that it's
probably best to explode all tarballs, then move all of
x:\...\usr\bin to x:\...\bin and then do PATH=/usr/bin.
At least that was my remedy for gcc not finding its stuff (it
doesn't like PATH=/bin) and mintty not finding sh when I
double-click it. Or is there a way to explode the
non-base-tarballs from inside the cygwin64 instance so that
the /usr/bin stuff ends up in the same windows x:\...\bin
folder as the base like it should?

This issue feels like it's something I've misunderstood.

2. A configure script I ran hit a snag because
"gcc conftest.c -lc" failed with a missing libc. I know -lc
isn't needed, but it works with plain old non-64-cygwin. I could
get past it by seeding the cache, so it's not a show-stopper (at
least not in this incarnation).

3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

Cheers,
Peter

[Ken Brown]

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as Peter
with all Makefiles being empty. In addition, the configure test for
mktime (attached) fails; CPU usage spins up to 25% (one core), and the
program has to be killed from the Task Manager.

Ken

[Corinna Vinschen]

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure

Yup, confirmed. Looks like a gawk thingy.

Post by Ken Brown
test for mktime (attached) fails; CPU usage spins up to 25% (one
core), and the program has to be killed from the Task Manager.

Thanks for the testcase. I'll have a look this week. Yesterday I
already noticed a time problem when fetching stat info from NFS shares.
NFS uses 8 byte timespecs, 64 bit cygwin uses 16 byte timespecs. I
guess there's some 4 byte/8 byte time_t problem lurking somewhere in
Cygwin.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure

Yup, confirmed. Looks like a gawk thingy.

Baaaaaad bug in Cygwin. The ReadFile OS function expects a pointer to
a DWORD variable (always 4 byte) to return the number of bytes read.
Cygwin provides a pointer to a size_t variable (4 bytes on i686, 8 bytes
on x86_64). Given the lots of scenarios in which this core function
is used, it's a miracle that other applications worked at all.

I'm curious how many of these little buggers still lurk in the code...

Anyway, I just applied a fix for the above problem. I'm going to look
into the mktime issue and then I'll upload a new base package soon.


Corinna

[Andy Koppe]

Post by Corinna Vinschen

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure

Yup, confirmed. Looks like a gawk thingy.

Baaaaaad bug in Cygwin. The ReadFile OS function expects a pointer to
a DWORD variable (always 4 byte) to return the number of bytes read.
Cygwin provides a pointer to a size_t variable (4 bytes on i686, 8 bytes
on x86_64). Given the lots of scenarios in which this core function
is used, it's a miracle that other applications worked at all.
I'm curious how many of these little buggers still lurk in the code...

Shouldn't the compiler catch that sort of error?

Andy

[Kai Tietz]

Post by Andy Koppe

Post by Corinna Vinschen

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure

Yup, confirmed. Looks like a gawk thingy.

Baaaaaad bug in Cygwin. The ReadFile OS function expects a pointer to
a DWORD variable (always 4 byte) to return the number of bytes read.
Cygwin provides a pointer to a size_t variable (4 bytes on i686, 8 bytes
on x86_64). Given the lots of scenarios in which this core function
is used, it's a miracle that other applications worked at all.
I'm curious how many of these little buggers still lurk in the code...

Shouldn't the compiler catch that sort of error?
Andy

Well, it does in general. But of course if you are casting here
explicit to LPDWORD, it doesn't claim anything. Nevertheless it is an
error, and I think at least a strict-aliasing warning should be
emitted here.

Kai

[Corinna Vinschen]

Post by Andy Koppe

Post by Corinna Vinschen

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure

Yup, confirmed. Looks like a gawk thingy.

Baaaaaad bug in Cygwin. The ReadFile OS function expects a pointer to
a DWORD variable (always 4 byte) to return the number of bytes read.
Cygwin provides a pointer to a size_t variable (4 bytes on i686, 8 bytes
on x86_64). Given the lots of scenarios in which this core function
is used, it's a miracle that other applications worked at all.
I'm curious how many of these little buggers still lurk in the code...

Shouldn't the compiler catch that sort of error?

Not when using a cast.


Corinna

[Corinna Vinschen]

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure
test for mktime (attached) fails; CPU usage spins up to 25% (one
core), and the program has to be killed from the Task Manager.
Ken

Oh well. I don't know how to "fix" this, other than by ripping out
the entire localtime/mktime implementation and replacing it with
something new.

Post by Ken Brown
static int
mktime_test (time_t now)
{
return (mktime_test1 (now)
&& mktime_test1 ((time_t) (time_t_max - now))
&& mktime_test1 ((time_t) (time_t_min + now)));
}
[...]
int
main ()
{
int result = 0;
time_t t, delta;
int i, j;
int time_t_signed_magnitude = (time_t) ~ (time_t) 0 < (time_t) -1;
int time_t_signed = ! ((time_t) 0 < (time_t) -1);
/* This test makes some buggy mktime implementations loop.
Give up after 60 seconds; a mktime slower than that
isn't worth using anyway. */
alarm (60);
time_t_max = (! time_t_signed
? (time_t) -1
: ((((time_t) 1 << (sizeof (time_t) * CHAR_BIT - 2)) - 1)
* 2 + 1));
time_t_min = (! time_t_signed
? (time_t) 0
: time_t_signed_magnitude
? ~ (time_t) 0
: ~ time_t_max);
[...]

So what it does is calling localtime with a time_t value set to
time_t_max. That's 0x7fffffff on i686, which manages to do the job in
less than 60 seconds. On 64 bit, time_t_max is 0x7fffffffffffffff.
That's roughly 2^32 times bigger than the 32 bit value, but the 64 bit
CPU isn't 2^32 times faster, unfortunately.

The problem in Cygwin's localtime is the loop in timesub. It uses a
loop to subtract days-per-year from the incoming value. That can take
quite some time...


Corinna

[Ken Brown]

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure
test for mktime (attached) fails; CPU usage spins up to 25% (one
core), and the program has to be killed from the Task Manager.
Ken

Oh well. I don't know how to "fix" this, other than by ripping out
the entire localtime/mktime implementation and replacing it with
something new.

Post by Ken Brown
static int
mktime_test (time_t now)
{
return (mktime_test1 (now)
&& mktime_test1 ((time_t) (time_t_max - now))
&& mktime_test1 ((time_t) (time_t_min + now)));
}
[...]
int
main ()
{
int result = 0;
time_t t, delta;
int i, j;
int time_t_signed_magnitude = (time_t) ~ (time_t) 0 < (time_t) -1;
int time_t_signed = ! ((time_t) 0 < (time_t) -1);
/* This test makes some buggy mktime implementations loop.
Give up after 60 seconds; a mktime slower than that
isn't worth using anyway. */
alarm (60);
time_t_max = (! time_t_signed
? (time_t) -1
: ((((time_t) 1 << (sizeof (time_t) * CHAR_BIT - 2)) - 1)
* 2 + 1));
time_t_min = (! time_t_signed
? (time_t) 0
: time_t_signed_magnitude
? ~ (time_t) 0
: ~ time_t_max);
[...]

So what it does is calling localtime with a time_t value set to
time_t_max. That's 0x7fffffff on i686, which manages to do the job in
less than 60 seconds. On 64 bit, time_t_max is 0x7fffffffffffffff.
That's roughly 2^32 times bigger than the 32 bit value, but the 64 bit
CPU isn't 2^32 times faster, unfortunately.

OK. But is there something else going on in addition to that? In my
tests, the program doesn't terminate after 60 seconds. Moreover, it
doesn't respond to `kill -9'; I have to kill it from the Task Manager.

Ken

[Corinna Vinschen]

Post by Ken Brown

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure
test for mktime (attached) fails; CPU usage spins up to 25% (one
core), and the program has to be killed from the Task Manager.
Ken

Oh well. I don't know how to "fix" this, other than by ripping out
the entire localtime/mktime implementation and replacing it with
something new.
[...]
So what it does is calling localtime with a time_t value set to
time_t_max. That's 0x7fffffff on i686, which manages to do the job in
less than 60 seconds. On 64 bit, time_t_max is 0x7fffffffffffffff.
That's roughly 2^32 times bigger than the 32 bit value, but the 64 bit
CPU isn't 2^32 times faster, unfortunately.

OK. But is there something else going on in addition to that? In
my tests, the program doesn't terminate after 60 seconds. Moreover,
it doesn't respond to `kill -9'; I have to kill it from the Task
Manager.

It's running in an endless loop within an internal function. That
defeats any signals.


Corinna

[Teemu Nätkinniemi]

Post by Corinna Vinschen

Post by Ken Brown

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure
test for mktime (attached) fails; CPU usage spins up to 25% (one
core), and the program has to be killed from the Task Manager.
Ken

Oh well. I don't know how to "fix" this, other than by ripping out
the entire localtime/mktime implementation and replacing it with
something new.
[...]
So what it does is calling localtime with a time_t value set to
time_t_max. That's 0x7fffffff on i686, which manages to do the job in
less than 60 seconds. On 64 bit, time_t_max is 0x7fffffffffffffff.
That's roughly 2^32 times bigger than the 32 bit value, but the 64 bit
CPU isn't 2^32 times faster, unfortunately.

OK. But is there something else going on in addition to that? In
my tests, the program doesn't terminate after 60 seconds. Moreover,
it doesn't respond to `kill -9'; I have to kill it from the Task
Manager.

It's running in an endless loop within an internal function. That
defeats any signals.

How about Darwin's implementation of localtime? Would that work with Cygwin?

http://opensource.apple.com/source/Libc/Libc-825.25/stdtime/FreeBSD/localtime.c

[Corinna Vinschen]

Post by Teemu Nätkinniemi

Post by Corinna Vinschen

Post by Ken Brown

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure
test for mktime (attached) fails; CPU usage spins up to 25% (one
core), and the program has to be killed from the Task Manager.
Ken

Oh well. I don't know how to "fix" this, other than by ripping out
the entire localtime/mktime implementation and replacing it with
something new.
[...]
So what it does is calling localtime with a time_t value set to
time_t_max. That's 0x7fffffff on i686, which manages to do the job in
less than 60 seconds. On 64 bit, time_t_max is 0x7fffffffffffffff.
That's roughly 2^32 times bigger than the 32 bit value, but the 64 bit
CPU isn't 2^32 times faster, unfortunately.

OK. But is there something else going on in addition to that? In
my tests, the program doesn't terminate after 60 seconds. Moreover,
it doesn't respond to `kill -9'; I have to kill it from the Task
Manager.

It's running in an endless loop within an internal function. That
defeats any signals.

How about Darwin's implementation of localtime? Would that work with Cygwin?
http://opensource.apple.com/source/Libc/Libc-825.25/stdtime/FreeBSD/localtime.c

We're using an older version of the Olson code in Cygwin already.
The problem is that the code hasn't been updated for ages, apart
from minor bugfixes. Besides, the loop in the apple code looks
pretty much the same as ours, I don't see that it handles the
testcase any better than our code. I'm just looking into updating
our code along the lines of the current NetBSD implementation.
It will refuse certain, too big input values, which doesn't always
guarantee the same results as the Linux implementation, but at
least it won't spin almost endlessly.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Ken Brown

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure
test for mktime (attached) fails; CPU usage spins up to 25% (one
core), and the program has to be killed from the Task Manager.
Ken

Oh well. I don't know how to "fix" this, other than by ripping out
the entire localtime/mktime implementation and replacing it with
something new.
[...]
So what it does is calling localtime with a time_t value set to
time_t_max. That's 0x7fffffff on i686, which manages to do the job in
less than 60 seconds. On 64 bit, time_t_max is 0x7fffffffffffffff.
That's roughly 2^32 times bigger than the 32 bit value, but the 64 bit
CPU isn't 2^32 times faster, unfortunately.

OK. But is there something else going on in addition to that? In
my tests, the program doesn't terminate after 60 seconds. Moreover,
it doesn't respond to `kill -9'; I have to kill it from the Task
Manager.

It's running in an endless loop within an internal function. That
defeats any signals.

Well, actually the loop isn't endless, but given the number of
iterations it's for all practical purposes endless.

Btw., I'm just looking into updating our code to the latest from
NetBSD. I really hope that helps.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure
test for mktime (attached) fails; CPU usage spins up to 25% (one
core), and the program has to be killed from the Task Manager.
Ken

Oh well. I don't know how to "fix" this, other than by ripping out
the entire localtime/mktime implementation and replacing it with
something new.

I spent the entire day to pull our 1999 localtime.cc file, which only
saw minor changes since then, up to the latest code from NetBSD. This
implementation appears to work quick and it runs the entire mktime
testcase successfully.

I'm going to upload a new Cygwin tomorrow, I'm simply too tired today.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure
test for mktime (attached) fails; CPU usage spins up to 25% (one
core), and the program has to be killed from the Task Manager.
Ken

Oh well. I don't know how to "fix" this, other than by ripping out
the entire localtime/mktime implementation and replacing it with
something new.

I spent the entire day to pull our 1999 localtime.cc file, which only
saw minor changes since then, up to the latest code from NetBSD. This
implementation appears to work quick and it runs the entire mktime
testcase successfully.
I'm going to upload a new Cygwin tomorrow, I'm simply too tired today.

I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz
Please give it a try.


Corinna

[Yaakov (Cygwin/X)]

Post by Corinna Vinschen
I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz
Please give it a try.

1) The import libs still need to be regenerated with the fixed
speclib.

2) Neither iconv.h nor unctrl.h should be shipped, as those are
provided by libiconv and ncurses, respectively.

3) There are definitely bugs (as to be expected); I'll try to STC them
later.


Yaakov

[Corinna Vinschen]

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz
Please give it a try.

1) The import libs still need to be regenerated with the fixed
speclib.

Ok.

Post by Yaakov (Cygwin/X)
2) Neither iconv.h nor unctrl.h should be shipped, as those are
provided by libiconv and ncurses, respectively.

I didn't even know they *are* shipped... thanks for the hint.

Post by Yaakov (Cygwin/X)
3) There are definitely bugs (as to be expected); I'll try to STC them
later.

Thank you. I would be surprised if there were no bugs...


Corinna

[Christopher Faylor]

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz
Please give it a try.

1) The import libs still need to be regenerated with the fixed
speclib.

Ok.

Post by Yaakov (Cygwin/X)
2) Neither iconv.h nor unctrl.h should be shipped, as those are
provided by libiconv and ncurses, respectively.

I didn't even know they *are* shipped... thanks for the hint.

Post by Yaakov (Cygwin/X)
3) There are definitely bugs (as to be expected); I'll try to STC them
later.

Thank you. I would be surprised if there were no bugs...

Sure, but it's pretty amazing that things seem to be working as well as
they are.

cgf

[Corinna Vinschen]

Post by Christopher Faylor

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz
Please give it a try.

1) The import libs still need to be regenerated with the fixed
speclib.

Ok.

Post by Yaakov (Cygwin/X)
2) Neither iconv.h nor unctrl.h should be shipped, as those are
provided by libiconv and ncurses, respectively.

I didn't even know they *are* shipped... thanks for the hint.

Post by Yaakov (Cygwin/X)
3) There are definitely bugs (as to be expected); I'll try to STC them
later.

Thank you. I would be surprised if there were no bugs...

Sure, but it's pretty amazing that things seem to be working as well as
they are.

Yeah, I'm not exactly unhappy of the current state. I didn't expect
that already in February.

What doesn't work at all right now is exception handling, btw. It looks
like the installed exception handler is entirely ignored for some reason.
I'm going to look into this over the week.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz

Replaced with
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219-2.x86_64.tar.xz

fixing the below mentioned points 1 and 2. Also, cygcheck now works
correct on 64 bit binaries. And only on 64 bit binaries. I disabled
checking 32 bit binaries on 64 bit and vice versa. The reason is that
cygcheck won't find the correct DLLs due to the search path, which only
leads to confusion.

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
Please give it a try.

1) The import libs still need to be regenerated with the fixed
speclib.

Ok.

Post by Yaakov (Cygwin/X)
2) Neither iconv.h nor unctrl.h should be shipped, as those are
provided by libiconv and ncurses, respectively.

I didn't even know they *are* shipped... thanks for the hint.

Post by Yaakov (Cygwin/X)
3) There are definitely bugs (as to be expected); I'll try to STC them
later.

Thank you. I would be surprised if there were no bugs...

Corinna

[Teemu Nätkinniemi]

Post by Corinna Vinschen

Post by Corinna Vinschen
I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz

Replaced with
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219-2.x86_64.tar.xz

This last update seems to have broken GCC.

[Corinna Vinschen]

Post by Teemu Nätkinniemi

Post by Corinna Vinschen

Post by Corinna Vinschen
I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz

Replaced with
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219-2.x86_64.tar.xz

This last update seems to have broken GCC.

How so? It seems to work for me with a simple example. Ideally, bug
reports come with details...


Corinna

[Teemu Nätkinniemi]

Post by Corinna Vinschen

Post by Teemu Nätkinniemi

Post by Corinna Vinschen

Post by Corinna Vinschen
I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz

Replaced with
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219-2.x86_64.tar.xz

This last update seems to have broken GCC.

How so? It seems to work for me with a simple example. Ideally, bug
reports come with details...

Sorry, I was in the middle of trying to get Perl working so I replaced
it with the previous version. Here's an excerpt from a not very
informative config.log.

configure:2922: $? = 0
configure:2929: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-cygwin
Configured with: /home/corinna/src/cross-cygwin/gcc/configure
--host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --prefix=/usr
--sysconfdir=/etc --enable-languages=c,c++ --disable-shared --enable-static
Thread model: single
gcc version 4.8.0 20130215 (experimental) (GCC)
configure:2933: $? = 0
configure:2940: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:2944: $? = 1
configure:2967: checking for C compiler default output file name
configure:2989: gcc conftest.c >&5
gcc: error: spawn: No such file or directory
configure:2993: $? = 1
configure:3031: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "GNU Texinfo"
| #define PACKAGE_TARNAME "texinfo"
| #define PACKAGE_VERSION "4.13"
| #define PACKAGE_STRING "GNU Texinfo 4.13"
| #define PACKAGE_BUGREPORT "bug-texinfo-mXXj517/***@public.gmane.org"
| #define PACKAGE "texinfo"
| #define VERSION "4.13"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3037: error: in `/src/kede':
configure:3039: error: C compiler cannot create executables
See `config.log' for more details.

[Corinna Vinschen]

Post by Teemu Nätkinniemi

Post by Corinna Vinschen

Post by Teemu Nätkinniemi
This last update seems to have broken GCC.

How so? It seems to work for me with a simple example. Ideally, bug
reports come with details...

Sorry, I was in the middle of trying to get Perl working so I
replaced it with the previous version. Here's an excerpt from a not
very informative config.log.
configure:2922: $? = 0
configure:2929: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-cygwin
Configured with: /home/corinna/src/cross-cygwin/gcc/configure
--host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --prefix=/usr
--sysconfdir=/etc --enable-languages=c,c++ --disable-shared
--enable-static
Thread model: single
gcc version 4.8.0 20130215 (experimental) (GCC)
configure:2933: $? = 0
configure:2940: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:2944: $? = 1
configure:2967: checking for C compiler default output file name
configure:2989: gcc conftest.c >&5
gcc: error: spawn: No such file or directory
configure:2993: $? = 1

/* confdefs.h. */
#define PACKAGE_NAME "GNU Texinfo"
#define PACKAGE_TARNAME "texinfo"
#define PACKAGE_VERSION "4.13"
#define PACKAGE_STRING "GNU Texinfo 4.13"
#define PACKAGE_BUGREPORT "bug-texinfo-mXXj517/***@public.gmane.org"
#define PACKAGE "texinfo"
#define VERSION "4.13"
/* end confdefs.h. */

int
main ()
{

;
return 0;
}

Post by Teemu Nätkinniemi
configure:3039: error: C compiler cannot create executables
See `config.log' for more details.

Works for me. Note that the only changes are the speclib change,
the two headers I removed, and the new cygcheck.exe.


Corinna

[Ryan Johnson]

Post by Teemu Nätkinniemi

Post by Teemu Nätkinniemi

Post by Corinna Vinschen

Post by Corinna Vinschen
I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz

Replaced with
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219-2.x86_64.tar.xz

This last update seems to have broken GCC.

How so? It seems to work for me with a simple example. Ideally, bug
reports come with details...

Sorry, I was in the middle of trying to get Perl working so I replaced
it with the previous version. Here's an excerpt from a not very
informative config.log.
configure:2922: $? = 0
configure:2929: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-cygwin
Configured with: /home/corinna/src/cross-cygwin/gcc/configure
--host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --prefix=/usr
--sysconfdir=/etc --enable-languages=c,c++ --disable-shared
--enable-static
Thread model: single
gcc version 4.8.0 20130215 (experimental) (GCC)
configure:2933: $? = 0
configure:2940: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.

That's odd... I don't think -V has ever been a legal command-line option
to gcc. Was that supposed to be -v?

Ryan

[Corinna Vinschen]

Post by Ryan Johnson

Post by Teemu Nätkinniemi

Post by Teemu Nätkinniemi

Post by Corinna Vinschen

Post by Corinna Vinschen
I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz

Replaced with
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219-2.x86_64.tar.xz

This last update seems to have broken GCC.

How so? It seems to work for me with a simple example. Ideally, bug
reports come with details...

Sorry, I was in the middle of trying to get Perl working so I
replaced it with the previous version. Here's an excerpt from a
not very informative config.log.
configure:2922: $? = 0
configure:2929: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-cygwin
Configured with: /home/corinna/src/cross-cygwin/gcc/configure
--host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --prefix=/usr
--sysconfdir=/etc --enable-languages=c,c++ --disable-shared
--enable-static
Thread model: single
gcc version 4.8.0 20130215 (experimental) (GCC)
configure:2933: $? = 0
configure:2940: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.

That's odd... I don't think -V has ever been a legal command-line
option to gcc. Was that supposed to be -v?

It's not the problem. This test is always performed by configure and
it's result is not crucial. Certain non-gcc compilers apparently know
a -V flag...


Corinna

[Teemu Nätkinniemi]

Post by Corinna Vinschen

Post by Ryan Johnson

Post by Teemu Nätkinniemi

Post by Teemu Nätkinniemi

Post by Corinna Vinschen

Post by Corinna Vinschen
I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz

Replaced with
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219-2.x86_64.tar.xz

This last update seems to have broken GCC.

How so? It seems to work for me with a simple example. Ideally, bug
reports come with details...

Sorry, I was in the middle of trying to get Perl working so I
replaced it with the previous version. Here's an excerpt from a
not very informative config.log.
configure:2922: $? = 0
configure:2929: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-cygwin
Configured with: /home/corinna/src/cross-cygwin/gcc/configure
--host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --prefix=/usr
--sysconfdir=/etc --enable-languages=c,c++ --disable-shared
--enable-static
Thread model: single
gcc version 4.8.0 20130215 (experimental) (GCC)
configure:2933: $? = 0
configure:2940: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.

That's odd... I don't think -V has ever been a legal command-line
option to gcc. Was that supposed to be -v?

It's not the problem. This test is always performed by configure and
it's result is not crucial. Certain non-gcc compilers apparently know
a -V flag...

Ok, I tried it again and now it seems to be working. On the other hand,
Perl compiles nicely but won't run.

(gdb) run --help
Starting program: G:\cygwin64\src\perl-5.16.2\perl.exe --help
[New Thread 5928.0x16e8]
warning: cYgFFFFFFFF 1801E6960 0
[New Thread 5928.0x940]
warning: cYgstd 0x23aa30 d 3

Program received signal SIGSEGV, Segmentation fault.
main (argc=2, argv=0x23aad0, env=0x6000281a0) at perlmain.c:110
110 if (!PL_do_undump) {

[Teemu Nätkinniemi]

The problem with Perl is that dynamic loading does not work. I still
haven't figured out why but for the time being, here's a static version
of Perl 5.16.2.

https://sourceforge.net/projects/cyg64files/files/perl-5.16.2-0.x86_64-static.tar.xz/download

[Teemu Nätkinniemi]

The problem with Perl is that dynamic loading does not work. I still haven't
figured out why but for the time being, here's a static version of Perl
5.16.2.
https://sourceforge.net/projects/cyg64files/files/perl-5.16.2-0.x86_64-static.tar.xz/download

Earlier version was missing threads/shared module and couldn't compile
Automake. I've uploaded Perl, Autoconf, Automake and Libtool:

https://sourceforge.net/projects/cyg64files/

[Ken Brown]

Post by Corinna Vinschen

Post by Corinna Vinschen

Post by Corinna Vinschen

Post by Ken Brown

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

I made a first attempt to build emacs. I had the same problem as
Peter with all Makefiles being empty. In addition, the configure
test for mktime (attached) fails; CPU usage spins up to 25% (one
core), and the program has to be killed from the Task Manager.
Ken

Oh well. I don't know how to "fix" this, other than by ripping out
the entire localtime/mktime implementation and replacing it with
something new.

I spent the entire day to pull our 1999 localtime.cc file, which only
saw minor changes since then, up to the latest code from NetBSD. This
implementation appears to work quick and it runs the entire mktime
testcase successfully.
I'm going to upload a new Cygwin tomorrow, I'm simply too tired today.

I just uploaded
ftp://cygwin.com/pub/cygwin/64bit/install/base-cygwin-toolchain-install-first-20130219.x86_64.tar.xz
Please give it a try.

Both problems I reported (empty Makefiles, mktime test failure) are
fixed. Thanks!

Ken

[Corinna Vinschen]

Hi Peter,

Post by Peter Rosin

Post by Corinna Vinschen
base-cygwin-toolchain-install-first-20130216.x86_64.tar.xz
coreutils-8.14-1.x86_64.tar.xz
dash-0.5.7-1.x86_64.tar.xz
file-5.11-1.x86_64.tar.xz
findutils-4.5.9-2.x86_64.tar.xz
gawk-4.0.2-1.x86_64.tar.xz
grep-2.6.3-1.x86_64.tar.xz
m4-1.4.16-1.x86_64.tar.xz
make-3.82-1.x86_64.tar.xz
md5.sum
mingw-gdb.x86_64.tar.xz
mintty-r1295.x86_64.tar.xz
rebase-4.4.0-1.x86_64.tar.xz
sed-4.2.1-1.x86_64.tar.xz
tar-1.26-1.x86_64.tar.xz
tcsh-6.18.01-1.x86_64.tar.xz
For installation, start with untar'ing the base-cygwin-* package, which
contains cygwin itself and the native toolchain. Then untar all the
other packages on top if it. In the end, you have dash/sh, and tcsh to
work with. What you need to provide yourself are passwd and group
files, as well as fstab and personal profiles to fit your needs.

Hi!
I tried this out a little bit. Neat stuff!
1. base-cygwin...tar.xz puts its binaries in /bin, but gcc
et al expects to be in /usr/bin (I think, at least that was
the case in the previous version of that tarball). The other
[...]
This issue feels like it's something I've misunderstood.

The base package installs symlinks usr/bin -> ../bin and usr/lib ->
../lib. This was supposed to solve the problem since when unpacking the
other packages, the 32 bit tar finds the symlinks and installs
everything usr/bin to bin and everything usr/lib to lib, as expected.

Are you saying that didn't work?

Post by Peter Rosin
2. A configure script I ran hit a snag because
"gcc conftest.c -lc" failed with a missing libc. I know -lc
isn't needed, but it works with plain old non-64-cygwin. I could
get past it by seeding the cache, so it's not a show-stopper (at
least not in this incarnation).

Oh, right. libc.a, libg.a and libm.a are missing for some reason.
I missed that, sorry.

Post by Peter Rosin
3. The config.status scripts generated by the configure scrips
I have tested are not working (all Makefiles end up empty), but
I suspect that's some issue between autoconf and dash. So far it
has worked to run ./config.status from plain old non-64-cygwin
between configure and make.

Yes, I noticed this as well. The blame is either on gawk, or on
the combination of dash and gawk. For testing I just tried to run
the gawk testsuite (should have done that from the start :-() and
noticed that all output files in the testsuite are generated empty.

Well, bugs were to be expected. I'll debug that this week (but
obviously have nothing against others debugging this as well...)

Thanks for testing, it's much appreciated.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Peter Rosin
2. A configure script I ran hit a snag because
"gcc conftest.c -lc" failed with a missing libc. I know -lc
isn't needed, but it works with plain old non-64-cygwin. I could
get past it by seeding the cache, so it's not a show-stopper (at
least not in this incarnation).

Oh, right. libc.a, libg.a and libm.a are missing for some reason.
I missed that, sorry.

Bug in the bootstrap script. I uploaded a fixed version of bootstrap.sh
and a new base-cygwin-toolchain-install-first-20130217.x86_64.tar.xz.


Corinna

[Teemu Nätkinniemi]

Post by Corinna Vinschen

Post by Corinna Vinschen
Oh, right. libc.a, libg.a and libm.a are missing for some reason.
I missed that, sorry.

Bug in the bootstrap script. I uploaded a fixed version of bootstrap.sh
and a new base-cygwin-toolchain-install-first-20130217.x86_64.tar.xz.

I noticed that include files are different in Cygwin64. For example
dirent.h is from /newlib/libc/include/sys. Is this correct?

[Corinna Vinschen]

Post by Teemu Nätkinniemi

Post by Corinna Vinschen

Post by Corinna Vinschen
Oh, right. libc.a, libg.a and libm.a are missing for some reason.
I missed that, sorry.

Bug in the bootstrap script. I uploaded a fixed version of bootstrap.sh
and a new base-cygwin-toolchain-install-first-20130217.x86_64.tar.xz.

I noticed that include files are different in Cygwin64. For example
dirent.h is from /newlib/libc/include/sys. Is this correct?

Not at all. Another problem in the bootstrap script. It's not really
a good idea to use -j at make install time. The newlib headers have to
be installed first, then the cygwin headers are supposed to overwrite
the newlib ones. By using -j, make install in winsup managed to be
faster than make install in newlib, so the newlib headers overwrote
the cygwin headers instead.

I uploaded a changed bootstrap.sh script and a new
base-cygwin-toolchain-install-first-20130217-2.x86_64.tar.xz


Thanks for the heads up,
Corinna

[Ryan Johnson]

Post by Corinna Vinschen

Post by Teemu Nätkinniemi

Post by Corinna Vinschen

Post by Corinna Vinschen
Oh, right. libc.a, libg.a and libm.a are missing for some reason.
I missed that, sorry.

Bug in the bootstrap script. I uploaded a fixed version of bootstrap.sh
and a new base-cygwin-toolchain-install-first-20130217.x86_64.tar.xz.

I noticed that include files are different in Cygwin64. For example
dirent.h is from /newlib/libc/include/sys. Is this correct?

Not at all. Another problem in the bootstrap script. It's not really
a good idea to use -j at make install time. The newlib headers have to
be installed first, then the cygwin headers are supposed to overwrite
the newlib ones. By using -j, make install in winsup managed to be
the cygwin headers instead.

That's arguably a bug in the makefile... -j doesn't schedule things in
parallel if it knows there's a dependency between them.

Ryan

[Corinna Vinschen]

Post by Ryan Johnson

Post by Corinna Vinschen

Post by Teemu Nätkinniemi

Post by Corinna Vinschen

Post by Corinna Vinschen
Oh, right. libc.a, libg.a and libm.a are missing for some reason.
I missed that, sorry.

Bug in the bootstrap script. I uploaded a fixed version of bootstrap.sh
and a new base-cygwin-toolchain-install-first-20130217.x86_64.tar.xz.

I noticed that include files are different in Cygwin64. For example
dirent.h is from /newlib/libc/include/sys. Is this correct?

Not at all. Another problem in the bootstrap script. It's not really
a good idea to use -j at make install time. The newlib headers have to
be installed first, then the cygwin headers are supposed to overwrite
the newlib ones. By using -j, make install in winsup managed to be
the cygwin headers instead.

That's arguably a bug in the makefile... -j doesn't schedule things
in parallel if it knows there's a dependency between them.

I agree, but I'm not in the mood to hunt down this problem in the
sourceware src tree configury. Just calling make -j1 install is
sufficent for now.


Corinna

[Ken Brown]

Post by Corinna Vinschen
Hi Peter,

Post by Peter Rosin

Post by Corinna Vinschen
base-cygwin-toolchain-install-first-20130216.x86_64.tar.xz
coreutils-8.14-1.x86_64.tar.xz
dash-0.5.7-1.x86_64.tar.xz
file-5.11-1.x86_64.tar.xz
findutils-4.5.9-2.x86_64.tar.xz
gawk-4.0.2-1.x86_64.tar.xz
grep-2.6.3-1.x86_64.tar.xz
m4-1.4.16-1.x86_64.tar.xz
make-3.82-1.x86_64.tar.xz
md5.sum
mingw-gdb.x86_64.tar.xz
mintty-r1295.x86_64.tar.xz
rebase-4.4.0-1.x86_64.tar.xz
sed-4.2.1-1.x86_64.tar.xz
tar-1.26-1.x86_64.tar.xz
tcsh-6.18.01-1.x86_64.tar.xz
For installation, start with untar'ing the base-cygwin-* package, which
contains cygwin itself and the native toolchain. Then untar all the
other packages on top if it. In the end, you have dash/sh, and tcsh to
work with. What you need to provide yourself are passwd and group
files, as well as fstab and personal profiles to fit your needs.

Hi!
I tried this out a little bit. Neat stuff!
1. base-cygwin...tar.xz puts its binaries in /bin, but gcc
et al expects to be in /usr/bin (I think, at least that was
the case in the previous version of that tarball). The other
[...]
This issue feels like it's something I've misunderstood.

The base package installs symlinks usr/bin -> ../bin and usr/lib ->
../lib. This was supposed to solve the problem since when unpacking the
other packages, the 32 bit tar finds the symlinks and installs
everything usr/bin to bin and everything usr/lib to lib, as expected.
Are you saying that didn't work?

It didn't work for me either. Unpacking the base package creates the
symlinks, but unpacking the remaining packages blows them away. I had
to move everything from /usr/bin to /bin and from /usr/lib to /lib and
then recreate the symlinks.

Ken

[Corinna Vinschen]

Post by Ken Brown

Post by Corinna Vinschen

Post by Peter Rosin
1. base-cygwin...tar.xz puts its binaries in /bin, but gcc
et al expects to be in /usr/bin (I think, at least that was
the case in the previous version of that tarball). The other
[...]
This issue feels like it's something I've misunderstood.

The base package installs symlinks usr/bin -> ../bin and usr/lib ->
../lib. This was supposed to solve the problem since when unpacking the
other packages, the 32 bit tar finds the symlinks and installs
everything usr/bin to bin and everything usr/lib to lib, as expected.
Are you saying that didn't work?

It didn't work for me either. Unpacking the base package creates
the symlinks, but unpacking the remaining packages blows them away.
I had to move everything from /usr/bin to /bin and from /usr/lib to
/lib and then recreate the symlinks.

Try `tar xJkf <archive>'

Corinna

[Andy Koppe]

Post by Corinna Vinschen

Post by Ken Brown

Post by Corinna Vinschen

Post by Peter Rosin
1. base-cygwin...tar.xz puts its binaries in /bin, but gcc
et al expects to be in /usr/bin (I think, at least that was
the case in the previous version of that tarball). The other
[...]
This issue feels like it's something I've misunderstood.

The base package installs symlinks usr/bin -> ../bin and usr/lib ->
../lib. This was supposed to solve the problem since when unpacking the
other packages, the 32 bit tar finds the symlinks and installs
everything usr/bin to bin and everything usr/lib to lib, as expected.
Are you saying that didn't work?

It didn't work for me either. Unpacking the base package creates
the symlinks, but unpacking the remaining packages blows them away.
I had to move everything from /usr/bin to /bin and from /usr/lib to
/lib and then recreate the symlinks.

Try `tar xJkf <archive>'

That worked for me.

I've uploaded a new mintty to
ftp://cygwin.com/pub/cygwin/64bit/install, after checking fixes into
svn trunk. It's built with the native x86_64 toolchain.

I've also tried ye olde date fork benchmark (`while true; do date;
done | uniq -c`), on a Windows 8-64 laptop: I got 26 dates per second
with 32-bit Cygwin, but 50 with 64-bit Cygwin, so that's looking quite
promising.

Andy

[Corinna Vinschen]

Post by Andy Koppe

Post by Corinna Vinschen

Post by Ken Brown

Post by Corinna Vinschen

Post by Peter Rosin
1. base-cygwin...tar.xz puts its binaries in /bin, but gcc
et al expects to be in /usr/bin (I think, at least that was
the case in the previous version of that tarball). The other
[...]
This issue feels like it's something I've misunderstood.

The base package installs symlinks usr/bin -> ../bin and usr/lib ->
../lib. This was supposed to solve the problem since when unpacking the
other packages, the 32 bit tar finds the symlinks and installs
everything usr/bin to bin and everything usr/lib to lib, as expected.
Are you saying that didn't work?

It didn't work for me either. Unpacking the base package creates
the symlinks, but unpacking the remaining packages blows them away.
I had to move everything from /usr/bin to /bin and from /usr/lib to
/lib and then recreate the symlinks.

Try `tar xJkf <archive>'

That worked for me.
I've uploaded a new mintty to
ftp://cygwin.com/pub/cygwin/64bit/install, after checking fixes into
svn trunk. It's built with the native x86_64 toolchain.
I've also tried ye olde date fork benchmark (`while true; do date;
done | uniq -c`), on a Windows 8-64 laptop: I got 26 dates per second
with 32-bit Cygwin, but 50 with 64-bit Cygwin, so that's looking quite
promising.

Sounds good. I just hope it's not only a side-effect of some bug still
lurking in Cygwin :}


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Andy Koppe
I've also tried ye olde date fork benchmark (`while true; do date;
done | uniq -c`), on a Windows 8-64 laptop: I got 26 dates per second
with 32-bit Cygwin, but 50 with 64-bit Cygwin, so that's looking quite
promising.

Sounds good. I just hope it's not only a side-effect of some bug still
lurking in Cygwin :}

Did you test dash vs. bash by any chance? If so, bash is rather slow
compared to dash. On my 2008R2 testmachine I tested the above date loop
in dash, and I get 45 with Cygwin 1.7.17 (35 with bash), and 58+ with
the 64 bit DLL, so that's about 28% faster.


Corinna

[Andy Koppe]

Post by Corinna Vinschen

Post by Corinna Vinschen

Post by Andy Koppe
I've also tried ye olde date fork benchmark (`while true; do date;
done | uniq -c`), on a Windows 8-64 laptop: I got 26 dates per second
with 32-bit Cygwin, but 50 with 64-bit Cygwin, so that's looking quite
promising.

Sounds good. I just hope it's not only a side-effect of some bug still
lurking in Cygwin :}

Did you test dash vs. bash by any chance?

You're right, I did.

Post by Corinna Vinschen
If so, bash is rather slow
compared to dash. On my 2008R2 testmachine I tested the above date loop
in dash, and I get 45 with Cygwin 1.7.17 (35 with bash), and 58+ with
the 64 bit DLL, so that's about 28% faster.

Retesting with the latest stuff I got 47 vs 34 in dash (+38%), and 39
vs 26 in bash (+50%).

Andy

[Teemu Nätkinniemi]

Post by Andy Koppe

Post by Corinna Vinschen

Post by Corinna Vinschen

Post by Andy Koppe
I've also tried ye olde date fork benchmark (`while true; do date;
done | uniq -c`), on a Windows 8-64 laptop: I got 26 dates per second
with 32-bit Cygwin, but 50 with 64-bit Cygwin, so that's looking quite
promising.

Sounds good. I just hope it's not only a side-effect of some bug still
lurking in Cygwin :}

Did you test dash vs. bash by any chance?

You're right, I did.

Post by Corinna Vinschen
If so, bash is rather slow
compared to dash. On my 2008R2 testmachine I tested the above date loop
in dash, and I get 45 with Cygwin 1.7.17 (35 with bash), and 58+ with
the 64 bit DLL, so that's about 28% faster.

Retesting with the latest stuff I got 47 vs 34 in dash (+38%), and 39
vs 26 in bash (+50%).

I tested the same on my Windows 8 machine and got 70 for Cygwin 1.7.17
(Bash), 105 with x64 Bash. Dash on x64 gives me 129.

[Yaakov (Cygwin/X)]

Post by Corinna Vinschen
Yaakov, care to provide a quick-and-dirty vim package and, maybe, a
cygport for x86_64? Or is anything missing to get cygport running
natively? Since you have upload privs anyway, just upload what you can
create easily. Don't look for man pages or locale files, just the bare
tools would suffice, I guess.

I just uploaded binutils, bzip2, gzip, libiconv, rsync, xz, and zlib.

cygport git master can now target x86_64-pc-cygwin from either
i686-cygwin or Linux with the --64 flag (must be the first argument);
we'll need bash, gcc, perl (for autoconf/automake), plus a few others
before cygport itself will run natively on x86_64. I'll continue
working on the necessary prereqs over the next few days.


Yaakov

[Teemu Nätkinniemi]

Post by Yaakov (Cygwin/X)
cygport git master can now target x86_64-pc-cygwin from either
i686-cygwin or Linux with the --64 flag (must be the first argument);
we'll need bash, gcc, perl (for autoconf/automake), plus a few others
before cygport itself will run natively on x86_64. I'll continue
working on the necessary prereqs over the next few days.

Here's a basic version of Cygwin's Bash 4.1.10-4. I had to patch it a
bit to get it compiling but the binary seems to be working. YMMV.

http://www.mediafire.com/?lod94oa3q8nqqu8

Here's the error I got.

bashline.o: In function `initialize_readline':
/src/bash-4.1/bashline.c:455: undefined reference to
`_imp__rl_vi_editing_mode'
/src/bash-4.1/bashline.c:455:(.text+0x45a7): relocation truncated to
fit: R_X86_64_PC32 against undefined symbol `_imp__rl_vi_editing_mode'
/src/bash-4.1/bashline.c:459: undefined reference to
`_imp__rl_vi_editing_mode'
/src/bash-4.1/bashline.c:459:(.text+0x45d4): relocation truncated to
fit: R_X86_64_PC32 against undefined symbol `_imp__rl_vi_editing_mode'
/src/bash-4.1/bashline.c:479: undefined reference to `_imp__rl_tilde_expand'
/src/bash-4.1/bashline.c:479:(.text+0x466f): relocation truncated to
fit: R_X86_64_PC32 against undefined symbol `_imp__rl_tilde_expand'
/src/bash-4.1/bashline.c:503: undefined reference to `_imp__rl_tab_insert'
/src/bash-4.1/bashline.c:503:(.text+0x47a1): relocation truncated to
fit: R_X86_64_PC32 against undefined symbol `_imp__rl_tab_insert'
collect2: error: ld returned 1 exit status
make: *** [bash.exe] Error 1

[Yaakov (Cygwin/X)]

Post by Yaakov (Cygwin/X)
I just uploaded binutils, bzip2, gzip, libiconv, rsync, xz, and zlib.

Tonight I added crypt, cvs, cygutils, diffstat, gettext-runtime, less,
lndir, nano, ncurses, openssl (may not be working though), patch, popt,
tzcode, unzip, util-linux, and wget to 64bit/install, and bzip2, crypt,
ncurses, openssl, and popt to the cygwin64 toolchain in Ports. I think
bash and perl (for autotools) are all we need now to get cygport up and
running natively on x86_64.


Yaakov

[Yaakov (Cygwin/X)]

Post by Yaakov (Cygwin/X)

Post by Yaakov (Cygwin/X)
I just uploaded binutils, bzip2, gzip, libiconv, rsync, xz, and zlib.

Tonight I added crypt, cvs, cygutils, diffstat, gettext-runtime, less,
lndir, nano, ncurses, openssl (may not be working though), patch, popt,
tzcode, unzip, util-linux, and wget to 64bit/install, and bzip2, crypt,
ncurses, openssl, and popt to the cygwin64 toolchain in Ports. I think
bash and perl (for autotools) are all we need now to get cygport up and
running natively on x86_64.

I uploaded bash, bison, cygport, dos2unix, flex, gmp, libmpc,
mingw64-x86_64-binutils, mpfr, nettle, tcl, texinfo, and which.
cygport only works for packages which don't need to (re)run
autoconf/automake, nor can cygwin itself be built, as perl isn't
available yet. I tried openssh and vim but they're not working and I
haven't had time to debug them.


Yaakov

[Teemu Nätkinniemi]

Post by Yaakov (Cygwin/X)

Post by Yaakov (Cygwin/X)

Post by Yaakov (Cygwin/X)
I just uploaded binutils, bzip2, gzip, libiconv, rsync, xz, and zlib.

Tonight I added crypt, cvs, cygutils, diffstat, gettext-runtime, less,
lndir, nano, ncurses, openssl (may not be working though), patch, popt,
tzcode, unzip, util-linux, and wget to 64bit/install, and bzip2, crypt,
ncurses, openssl, and popt to the cygwin64 toolchain in Ports. I think
bash and perl (for autotools) are all we need now to get cygport up and
running natively on x86_64.

I uploaded bash, bison, cygport, dos2unix, flex, gmp, libmpc,
mingw64-x86_64-binutils, mpfr, nettle, tcl, texinfo, and which.
cygport only works for packages which don't need to (re)run
autoconf/automake, nor can cygwin itself be built, as perl isn't
available yet. I tried openssh and vim but they're not working and I
haven't had time to debug them.

I tried building Perl with the available source from Cygwin
(perl-5.14.2-3) but it fails:

/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../lib/libssp.a(ssp.o): In
function `__stack_chk_fail':
/home/corinna/src/cross-cygwin/gcc/libssp/ssp.c:167: multiple definition
of `__stack_chk_fail'
./libperl.dll.a(d001665.o):(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
make: *** [perl.exe] Error 1

[Andy Koppe]

Post by Corinna Vinschen
Hi guys,
I just uploaded all the latest 64 bit stuff to
ftp://cygwin.com/pub/cygwin/64bit/
The main change here is what has been discussed in
http://cygwin.com/ml/cygwin-developers/2013-02/msg00029.html
- The cygwin DLL is named cygwin1.dll rather than cyg64win1.dll.
- The DLL library prefix is "cyg" rather than "cyg64".
- The link library search path is /usr/lib, rather than /usr/lib64.
- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130215.tar.xz
A complete binary x86_64 Linux cross toolchain, latest patches.

Apparently this one can't find its Win32 libraries:

$ cat test.c
main(){}

$ x86_64-pc-cygwin-gcc test.c
/home/andy/opt/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -ladvapi32
/home/andy/opt/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lshell32
/home/andy/opt/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -luser32
/home/andy/opt/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lkernel32
collect2: error: ld returned 1 exit status

A somewhat related issue: in the mintty makefile, I tried to work
around the fact that there are two libuuids, one in the main library
directory and one in its w32api subdirectory, by adding -L`$(HOST)-gcc
-print-sysroot`/usr/lib/w32api to the link line, so as to pick up the
w32api one. (Incidentally that should also work around the issue
above.) Unfortunately that doesn't work with the Linux-hosted
cross-compiler because that returns nothing for -print-sysroot,
whereas Yaakov's Cygwin-32-to-64 cross-compiler does return the
appropriate directory.

Is there a better approach for dealing with that, other than requiring
the library directory to be passed into the makefile?

Andy

[Corinna Vinschen]

Post by Andy Koppe

Post by Corinna Vinschen
Hi guys,
I just uploaded all the latest 64 bit stuff to
ftp://cygwin.com/pub/cygwin/64bit/
The main change here is what has been discussed in
http://cygwin.com/ml/cygwin-developers/2013-02/msg00029.html
- The cygwin DLL is named cygwin1.dll rather than cyg64win1.dll.
- The DLL library prefix is "cyg" rather than "cyg64".
- The link library search path is /usr/lib, rather than /usr/lib64.
- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130215.tar.xz
A complete binary x86_64 Linux cross toolchain, latest patches.

$ cat test.c
main(){}
$ x86_64-pc-cygwin-gcc test.c
cannot find -ladvapi32
cannot find -lshell32
cannot find -luser32
cannot find -lkernel32
collect2: error: ld returned 1 exit status

This really puzzles me. The toolchain I uploaded is the exact toolchain
I'm using on Linux right now. And for me, building applications works.
I built the packages I uploaded to the 64bit/install dir with it and
your STC works fine for me.

Post by Andy Koppe
A somewhat related issue: in the mintty makefile, I tried to work
around the fact that there are two libuuids, one in the main library
directory and one in its w32api subdirectory, by adding -L`$(HOST)-gcc
-print-sysroot`/usr/lib/w32api to the link line, so as to pick up the
w32api one. (Incidentally that should also work around the issue
above.) Unfortunately that doesn't work with the Linux-hosted
cross-compiler because that returns nothing for -print-sysroot,
whereas Yaakov's Cygwin-32-to-64 cross-compiler does return the
appropriate directory.

The toolchain I created on Linux is not using --with-sysroot. All
target files are installed into $(exec_prefix)/$(target_alias) and
expected there by the compiler. For testing I moved away
/ext/redhat/x86_64-pc-cygwin/x86_64-pc-cygwin/lib/w32api/libkernel32.a
and I got

$ x86_64-pc-cygwin-gcc -g test.c
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lkernel32
collect2: error: ld returned 1 exit status

If I move libkernel32.a back, linking works.

Post by Andy Koppe
Is there a better approach for dealing with that, other than requiring
the library directory to be passed into the makefile?

Where is the non w32api libuuid.a coming from? I don't have such a
file.


Corinna

[Andy Koppe]

Post by Corinna Vinschen

Post by Andy Koppe

Post by Corinna Vinschen
Hi guys,
I just uploaded all the latest 64 bit stuff to
ftp://cygwin.com/pub/cygwin/64bit/
The main change here is what has been discussed in
http://cygwin.com/ml/cygwin-developers/2013-02/msg00029.html
- The cygwin DLL is named cygwin1.dll rather than cyg64win1.dll.
- The DLL library prefix is "cyg" rather than "cyg64".
- The link library search path is /usr/lib, rather than /usr/lib64.
- binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130215.tar.xz
A complete binary x86_64 Linux cross toolchain, latest patches.

$ cat test.c
main(){}
$ x86_64-pc-cygwin-gcc test.c
cannot find -ladvapi32
cannot find -lshell32
cannot find -luser32
cannot find -lkernel32
collect2: error: ld returned 1 exit status

This really puzzles me. The toolchain I uploaded is the exact toolchain
I'm using on Linux right now. And for me, building applications works.
I built the packages I uploaded to the 64bit/install dir with it and
your STC works fine for me.

Post by Andy Koppe
A somewhat related issue: in the mintty makefile, I tried to work
around the fact that there are two libuuids, one in the main library
directory and one in its w32api subdirectory, by adding -L`$(HOST)-gcc
-print-sysroot`/usr/lib/w32api to the link line, so as to pick up the
w32api one. (Incidentally that should also work around the issue
above.) Unfortunately that doesn't work with the Linux-hosted
cross-compiler because that returns nothing for -print-sysroot,
whereas Yaakov's Cygwin-32-to-64 cross-compiler does return the
appropriate directory.

The toolchain I created on Linux is not using --with-sysroot. All
target files are installed into $(exec_prefix)/$(target_alias) and
expected there by the compiler.

I see. Is it generally reasonable to assume that if `$(CC)
-print-sysroot` comes back empty, the library directory can be found
at ../$(target)/lib relative to the target-gcc's location?

Post by Corinna Vinschen
For testing I moved away
/ext/redhat/x86_64-pc-cygwin/x86_64-pc-cygwin/lib/w32api/libkernel32.a
and I got
$ x86_64-pc-cygwin-gcc -g test.c
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lkernel32
collect2: error: ld returned 1 exit status
If I move libkernel32.a back, linking works.

Hmm. I tried putting the toolchain into the same location you have it
in, but that didn't make a difference. -v output at the end of this
mail. A couple of things I noticed there:
- It says 'ignoring nonexistent directory "../../include/w32api"'
- The collect2 command line contains the main lib directory
('L/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/lib/../lib',
aka /ext/redhat/x86_64-pc-cygwin/x86_64-pc-cygwin/lib), but not its
w32api subdirectory.

It does build if I add
'-L/ext/redhat/x86_64-pc-cygwin/x86_64-pc-cygwin/lib/w32api'.

Btw, I'm using openSuse 12.2.

Post by Corinna Vinschen

Post by Andy Koppe
Is there a better approach for dealing with that, other than requiring
the library directory to be passed into the makefile?

Where is the non w32api libuuid.a coming from? I don't have such a
file.

On Cygwin proper it comes from the libuuid-devel package. Previously I
got around this by explicitly linking in /usr/lib/w32api/libuuid.a,
but obviously that's no good for cross-compiling. I'd like to address
this "properly" rather than rely on lib/libuuid.a not appearing in
cross build setups.

Andy



~/tmp$ x86_64-pc-cygwin-gcc test.c -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-cygwin-gcc
COLLECT_LTO_WRAPPER=/ext/redhat/x86_64-pc-cygwin/bin/../libexec/gcc/x86_64-pc-cygwin/4.8.0/lto-wrapper
Target: x86_64-pc-cygwin
Configured with: /home/corinna/src/cross-cygwin/gcc/configure
--target=x86_64-pc-cygwin --prefix=/usr/cygnus/x86_64-pc-cygwin
--enable-languages=c,c++ --with-newlib --disable-shared
--enable-static
Thread model: single
gcc version 4.8.0 20130215 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/ext/redhat/x86_64-pc-cygwin/bin/../libexec/gcc/x86_64-pc-cygwin/4.8.0/cc1
-quiet -v -iprefix
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/
-D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/lib/../lib/../include/w32api
-idirafter ../../include/w32api test.c -quiet -dumpbase test.c
-mtune=generic -march=x86-64 -auxbase test -version -o /tmp/cc3VMFP7.s
GNU C (GCC) version 4.8.0 20130215 (experimental) (x86_64-pc-cygwin)
compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2),
GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param
ggc-min-heapsize=4096
ignoring nonexistent directory
"/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/sys-include"
ignoring duplicate directory
"/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/../../lib/gcc/x86_64-pc-cygwin/4.8.0/include"
ignoring duplicate directory
"/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/../../lib/gcc/x86_64-pc-cygwin/4.8.0/include-fixed"
ignoring nonexistent directory
"/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/../../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/sys-include"
ignoring duplicate directory
"/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/../../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/include"
ignoring nonexistent directory "../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/include
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/include-fixed
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/include
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/lib/../lib/../include/w32api
End of search list.
GNU C (GCC) version 4.8.0 20130215 (experimental) (x86_64-pc-cygwin)
compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2),
GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param
ggc-min-heapsize=4096
Compiler executable checksum: 8527d13c6ece457755a7b6c7f6b2537a
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/as
-o /tmp/cc1q3fg5.o /tmp/cc3VMFP7.s
COMPILER_PATH=/ext/redhat/x86_64-pc-cygwin/bin/../libexec/gcc/x86_64-pc-cygwin/4.8.0/:/ext/redhat/x86_64-pc-cygwin/bin/../libexec/gcc/:/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/
LIBRARY_PATH=/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/:/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/:/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/lib/../lib/:/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/lib/
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/ext/redhat/x86_64-pc-cygwin/bin/../libexec/gcc/x86_64-pc-cygwin/4.8.0/collect2
-m i386pep --wrap _Znwj --wrap _Znaj --wrap _ZdlPv --wrap _ZdaPv
--wrap _ZnwjRKSt9nothrow_t --wrap _ZnajRKSt9nothrow_t --wrap
_ZdlPvRKSt9nothrow_t --wrap _ZdaPvRKSt9nothrow_t -Bdynamic
--dll-search-prefix=cyg -tsaware
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/lib/../lib/crt0.o
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/crtbegin.o
-L/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0
-L/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc
-L/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/lib/../lib
-L/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/lib
/tmp/cc1q3fg5.o -lgcc -lcygwin -ladvapi32 -lshell32 -luser32
-lkernel32 -lgcc
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/crtend.o
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -ladvapi32
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lshell32
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -luser32
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lkernel32
collect2: error: ld returned 1 exit status

[Corinna Vinschen]

Post by Andy Koppe

Post by Corinna Vinschen
The toolchain I created on Linux is not using --with-sysroot. All
target files are installed into $(exec_prefix)/$(target_alias) and
expected there by the compiler.

I see. Is it generally reasonable to assume that if `$(CC)
-print-sysroot` comes back empty, the library directory can be found
at ../$(target)/lib relative to the target-gcc's location?

Erm... I guess you have to ask a toolchain guy there :-}

Post by Andy Koppe

Post by Corinna Vinschen
For testing I moved away
/ext/redhat/x86_64-pc-cygwin/x86_64-pc-cygwin/lib/w32api/libkernel32.a
and I got
$ x86_64-pc-cygwin-gcc -g test.c
/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lkernel32
collect2: error: ld returned 1 exit status
If I move libkernel32.a back, linking works.

Hmm. I tried putting the toolchain into the same location you have it
in, but that didn't make a difference. -v output at the end of this
- It says 'ignoring nonexistent directory "../../include/w32api"'
- The collect2 command line contains the main lib directory
('L/ext/redhat/x86_64-pc-cygwin/bin/../lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/lib/../lib',
aka /ext/redhat/x86_64-pc-cygwin/x86_64-pc-cygwin/lib), but not its
w32api subdirectory.

Oh, hmm. Maybe the toolchain is *not* what I'm using. I just remember
that we had a problem with the default library path last week or so.
There's a chance I tweaked my toolchain locally but didn't upload the
changes. I'm just going to upload a new
binary-toolchain-x86_64-pc-linux-x-x86_64-pc-cygwin-20130221.tar.xz
Hopefully that problem heals itself by using that toolchain.

Post by Andy Koppe
Btw, I'm using openSuse 12.2.

Shouldn't matter at all.

Post by Andy Koppe

Post by Corinna Vinschen

Post by Andy Koppe
Is there a better approach for dealing with that, other than requiring
the library directory to be passed into the makefile?

Where is the non w32api libuuid.a coming from? I don't have such a
file.

On Cygwin proper it comes from the libuuid-devel package. Previously I
got around this by explicitly linking in /usr/lib/w32api/libuuid.a,
but obviously that's no good for cross-compiling. I'd like to address
this "properly" rather than rely on lib/libuuid.a not appearing in
cross build setups.

What about `$(CC) -print-file-name=w32api/libuuid.a'?


Corinna

[Yaakov (Cygwin/X)]

Post by Corinna Vinschen

Post by Andy Koppe

Post by Corinna Vinschen

Post by Andy Koppe
Is there a better approach for dealing with that, other than requiring
the library directory to be passed into the makefile?

Where is the non w32api libuuid.a coming from? I don't have such a
file.

On Cygwin proper it comes from the libuuid-devel package. Previously I
got around this by explicitly linking in /usr/lib/w32api/libuuid.a,
but obviously that's no good for cross-compiling. I'd like to address
this "properly" rather than rely on lib/libuuid.a not appearing in
cross build setups.

What about `$(CC) -print-file-name=w32api/libuuid.a'?

This is the most reliable solution.


Yaakov

[Andy Koppe]

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen

Post by Andy Koppe

Post by Corinna Vinschen

Post by Andy Koppe
Is there a better approach for dealing with that, other than requiring
the library directory to be passed into the makefile?

Where is the non w32api libuuid.a coming from? I don't have such a
file.

On Cygwin proper it comes from the libuuid-devel package. Previously I
got around this by explicitly linking in /usr/lib/w32api/libuuid.a,
but obviously that's no good for cross-compiling. I'd like to address
this "properly" rather than rely on lib/libuuid.a not appearing in
cross build setups.

What about `$(CC) -print-file-name=w32api/libuuid.a'?

This is the most reliable solution.

Thanks very much, that's working nicely. Interestingly,
-print-file-name=w32api works too.

Andy