Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 7:18 AM, Corinna Vinschen wrote: > On Sep 14 18:15, JonY wrote: >> What do you suggest the fix should be? > > I really don't know, but it's certainly not a fix in Cygwin. The fact > that /usr/bin is a mount point to /bin is nothing which wouldn't be > allowed under Linux as well. There's a default mechanism in gcc which > evaluates the paths to the tools, headers and libdb dirs by massaging > the $prefix and $exec_prefix values in some way. I assume you can > work around this issue by using slightly different values, but I'm > not fluent enough with the path evaluationin gcc to suggest the > correct solution, for a given value of "correct". Actually, I don't think this "problem" is all that critical. I think that in order to trigger it, you have to do some fairly unusual things: set your $PATH so that /bin precedes /usr/bin (which, in most cases, has zero effect...so why would you do that?), or deliberately invoke the compiler by one of its full PATH specifications (that is not the "usual" /usr/bin/ one). I think I'd just put a note in the README, the "Port Notes" section, like this: = If you invoke the compiler or other tools using a path like this: /bin/x86_64-w64-mingw32-gcc ... rather than these /usr/bin/x86_64-w64-mingw32-gcc ... x86_64-w64-mingw32-gcc ... you may see errors. If you must invoke the compiler using the /bin formulation, you can avoid these errors by creating a temporary mount point (or add the following to your ~/.bashrc): mount -o bind /usr/x86_64-w32-mingw32 /x86_64-w32-mingw32 = This can certainly wait until the next normal package update. At least, that's my opinion... -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On Sep 14 18:15, JonY wrote: > On 9/14/2010 16:03, Corinna Vinschen wrote: > >On Sep 14 15:30, JonY wrote: > >>On 9/14/2010 15:29, Charles Wilson wrote: > >>>I don't know about Andy, but I sure do -- and I can reproduce his > >>>problem. I suspect there is a "bug" in how the cross tool locates the > >>> /usr/x86_64-w64-mingw32/bin > >>>directory, given the mount structure: > >>> /usr/bin = /bin > >>> /usr/lib = /lib > >>>BUT > >>> /usr/x86_64-w64-mingw32 != /x86_64-w64-mingw32 > >>> > >>>because if I do THIS: > >>>mount -o bind /usr/x86_64-w64-mingw32 /x86_64-w64-mingw32 > >>> > >>>then > >>> /bin/x86_64-w64-mingw32-gcc -o foo foo.c > >>>works, just as if I had invoked > >>> x86_64-w64-mingw32-gcc -o foo foo.c > >>> > >>>I say this is a "bug" in quotes, because...well, I'm not sure it fits > >>>the definition. It's *our* fault we use a wacky mount structure on > >>>cygwin... > >>> > >>>-- > >>>Chuck > >>> > >> > >>So, if /usr/x86_64-w64-mingw32 actually exists, it works? > >> > >>This looks bad, nonetheless. > >> > >>Maybe we can fix cygwin by only redirecting known directories like, > >>/usr/bin and /usr/lib to those in /. > > > >Cygwin doesn't redirect any /usr dirs to /. There are default mount > >points for /usr/bin -> /bin and /usr/lib -> lib. That's all. The > >problematic path is generated in gcc itself. > > > > > >Corinna > > > > What do you suggest the fix should be? I really don't know, but it's certainly not a fix in Cygwin. The fact that /usr/bin is a mount point to /bin is nothing which wouldn't be allowed under Linux as well. There's a default mechanism in gcc which evaluates the paths to the tools, headers and libdb dirs by massaging the $prefix and $exec_prefix values in some way. I assume you can work around this issue by using slightly different values, but I'm not fluent enough with the path evaluationin gcc to suggest the correct solution, for a given value of "correct". Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 14 September 2010 11:40, JonY wrote: > On 9/14/2010 18:46, Andy Koppe wrote: >> >> On 14 September 2010 11:15, Marco Atzeri wrote: > > Is this to be expected? > > $ x86_64-w64-mingw32-gcc hello.c > [compiles fine] > > $ /bin/x86_64-w64-mingw32-gcc hello.c > /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler messages: > > /Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error: bad register name `%rbp' > > /Users/Andy/AppData/Local/Temp/cckcwv49.s:11: Error: bad register name `%rsp' > > /Users/Andy/AppData/Local/Temp/cckcwv49.s:12: Error: bad register name `%rsp' > > /Users/Andy/AppData/Local/Temp/cckcwv49.s:14: Error: bad register name `%rip)' > > It's obviously picking up the wrong assembler that way >> >>> Usually assuring the /usr/bin is before /bin in the path >>> solves the problems. >> >> /usr/bin is put before /bin in /etc/profile anyway, so it's not a >> critical issue. I just happened to try it with the /bin prefix first, >> probably because I was using tab completion on /bin to find the >> executable name of the compiler. >> > OK, so calling "x86_64-w64-mingw32-gcc" or "/usr/bin/x86_64-w64-mingw32-gcc" > in the shell usually works, but not "/bin/x86_64-w64-mingw32-gcc"? Exactly. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 18:46, Andy Koppe wrote: On 14 September 2010 11:15, Marco Atzeri wrote: Is this to be expected? $ x86_64-w64-mingw32-gcc hello.c [compiles fine] $ /bin/x86_64-w64-mingw32-gcc hello.c /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler messages: /Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error: bad register name `%rbp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:11: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:12: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:14: Error: bad register name `%rip)' It's obviously picking up the wrong assembler that way Usually assuring the /usr/bin is before /bin in the path solves the problems. /usr/bin is put before /bin in /etc/profile anyway, so it's not a critical issue. I just happened to try it with the /bin prefix first, probably because I was using tab completion on /bin to find the executable name of the compiler. Andy OK, so calling "x86_64-w64-mingw32-gcc" or "/usr/bin/x86_64-w64-mingw32-gcc" in the shell usually works, but not "/bin/x86_64-w64-mingw32-gcc"? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 14 September 2010 11:15, Marco Atzeri wrote: >> > Is this to be expected? >> > >> > $ x86_64-w64-mingw32-gcc hello.c >> > [compiles fine] >> > >> > $ /bin/x86_64-w64-mingw32-gcc hello.c >> > /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler >> messages: >> > /Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error: >> bad register name `%rbp' >> > /Users/Andy/AppData/Local/Temp/cckcwv49.s:11: Error: >> bad register name `%rsp' >> > /Users/Andy/AppData/Local/Temp/cckcwv49.s:12: Error: >> bad register name `%rsp' >> > /Users/Andy/AppData/Local/Temp/cckcwv49.s:14: Error: >> bad register name `%rip)' >> > >> > It's obviously picking up the wrong assembler that >> way > Usually assuring the /usr/bin is before /bin in the path > solves the problems. /usr/bin is put before /bin in /etc/profile anyway, so it's not a critical issue. I just happened to try it with the /bin prefix first, probably because I was using tab completion on /bin to find the executable name of the compiler. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 16:03, Corinna Vinschen wrote: On Sep 14 15:30, JonY wrote: On 9/14/2010 15:29, Charles Wilson wrote: I don't know about Andy, but I sure do -- and I can reproduce his problem. I suspect there is a "bug" in how the cross tool locates the /usr/x86_64-w64-mingw32/bin directory, given the mount structure: /usr/bin = /bin /usr/lib = /lib BUT /usr/x86_64-w64-mingw32 != /x86_64-w64-mingw32 because if I do THIS: mount -o bind /usr/x86_64-w64-mingw32 /x86_64-w64-mingw32 then /bin/x86_64-w64-mingw32-gcc -o foo foo.c works, just as if I had invoked x86_64-w64-mingw32-gcc -o foo foo.c I say this is a "bug" in quotes, because...well, I'm not sure it fits the definition. It's *our* fault we use a wacky mount structure on cygwin... -- Chuck So, if /usr/x86_64-w64-mingw32 actually exists, it works? This looks bad, nonetheless. Maybe we can fix cygwin by only redirecting known directories like, /usr/bin and /usr/lib to those in /. Cygwin doesn't redirect any /usr dirs to /. There are default mount points for /usr/bin -> /bin and /usr/lib -> lib. That's all. The problematic path is generated in gcc itself. Corinna What do you suggest the fix should be? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
--- Mar 14/9/10, ha scritto: > On 9/14/2010 13:11, Andy Koppe > wrote: > > On 14 September 2010 03:13, JonY wrote: > >> Version 4.5.1-1 of "mingw64-x86_64-gcc" has been > uploaded. > >> > >> mingw64-x86_64-gcc contains GCC sources used by > the 64bit target toolchain. > >> See mingw64-x86_64-gcc-core, > mingw64-x86_64-gcc-objc, > >> mingw64-x86_64-gcc-ada, mingw64-x86_64-gcc-g++ > and > >> mingw64-x86_64-gcc-fortran for binaries. > > > > Great stuff. > > > > First issue: Is this to be expected? > > > > $ x86_64-w64-mingw32-gcc hello.c > > [compiles fine] > > > > $ /bin/x86_64-w64-mingw32-gcc hello.c > > /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler > messages: > > /Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error: > bad register name `%rbp' > > /Users/Andy/AppData/Local/Temp/cckcwv49.s:11: Error: > bad register name `%rsp' > > /Users/Andy/AppData/Local/Temp/cckcwv49.s:12: Error: > bad register name `%rsp' > > /Users/Andy/AppData/Local/Temp/cckcwv49.s:14: Error: > bad register name `%rip)' > > > > It's obviously picking up the wrong assembler that > way. > > > > $ /bin/x86_64-w64-mingw32-gcc hello.c -v > > Using built-in specs. > > COLLECT_GCC=/bin/x86_64-w64-mingw32-gcc > > > COLLECT_LTO_WRAPPER=/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe > > > > Andy > > That is weird. > > Do you have mingw64 binutils installed? Somehow the cygwin > binutils was > used. > It is not so weird, I have already seen it in other programs that expect to be installed in /usr/bin and are unable to find the other portions if they are called from /bin Instead of /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe that doesn't work /usr/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe means /usr/lib/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe Usually assuring the /usr/bin is before /bin in the path solves the problems. For cygwin we could also remove /bin at all from the path. Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On Sep 14 15:30, JonY wrote: > On 9/14/2010 15:29, Charles Wilson wrote: > >I don't know about Andy, but I sure do -- and I can reproduce his > >problem. I suspect there is a "bug" in how the cross tool locates the > > /usr/x86_64-w64-mingw32/bin > >directory, given the mount structure: > > /usr/bin = /bin > > /usr/lib = /lib > >BUT > > /usr/x86_64-w64-mingw32 != /x86_64-w64-mingw32 > > > >because if I do THIS: > >mount -o bind /usr/x86_64-w64-mingw32 /x86_64-w64-mingw32 > > > >then > > /bin/x86_64-w64-mingw32-gcc -o foo foo.c > >works, just as if I had invoked > > x86_64-w64-mingw32-gcc -o foo foo.c > > > >I say this is a "bug" in quotes, because...well, I'm not sure it fits > >the definition. It's *our* fault we use a wacky mount structure on cygwin... > > > >-- > >Chuck > > > > So, if /usr/x86_64-w64-mingw32 actually exists, it works? > > This looks bad, nonetheless. > > Maybe we can fix cygwin by only redirecting known directories like, > /usr/bin and /usr/lib to those in /. Cygwin doesn't redirect any /usr dirs to /. There are default mount points for /usr/bin -> /bin and /usr/lib -> lib. That's all. The problematic path is generated in gcc itself. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 15:29, Charles Wilson wrote: On 9/14/2010 2:57 AM, JonY wrote: That is weird. Do you have mingw64 binutils installed? Somehow the cygwin binutils was used. I don't know about Andy, but I sure do -- and I can reproduce his problem. I suspect there is a "bug" in how the cross tool locates the /usr/x86_64-w64-mingw32/bin directory, given the mount structure: /usr/bin = /bin /usr/lib = /lib BUT /usr/x86_64-w64-mingw32 != /x86_64-w64-mingw32 because if I do THIS: mount -o bind /usr/x86_64-w64-mingw32 /x86_64-w64-mingw32 then /bin/x86_64-w64-mingw32-gcc -o foo foo.c works, just as if I had invoked x86_64-w64-mingw32-gcc -o foo foo.c I say this is a "bug" in quotes, because...well, I'm not sure it fits the definition. It's *our* fault we use a wacky mount structure on cygwin... -- Chuck So, if /usr/x86_64-w64-mingw32 actually exists, it works? This looks bad, nonetheless. Maybe we can fix cygwin by only redirecting known directories like, /usr/bin and /usr/lib to those in /. It would probably break third party apps, so its not entirely good either. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 2:57 AM, JonY wrote: > That is weird. > > Do you have mingw64 binutils installed? Somehow the cygwin binutils was > used. I don't know about Andy, but I sure do -- and I can reproduce his problem. I suspect there is a "bug" in how the cross tool locates the /usr/x86_64-w64-mingw32/bin directory, given the mount structure: /usr/bin = /bin /usr/lib = /lib BUT /usr/x86_64-w64-mingw32 != /x86_64-w64-mingw32 because if I do THIS: mount -o bind /usr/x86_64-w64-mingw32 /x86_64-w64-mingw32 then /bin/x86_64-w64-mingw32-gcc -o foo foo.c works, just as if I had invoked x86_64-w64-mingw32-gcc -o foo foo.c I say this is a "bug" in quotes, because...well, I'm not sure it fits the definition. It's *our* fault we use a wacky mount structure on cygwin... -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 13:11, Andy Koppe wrote: On 14 September 2010 03:13, JonY wrote: Version 4.5.1-1 of "mingw64-x86_64-gcc" has been uploaded. mingw64-x86_64-gcc contains GCC sources used by the 64bit target toolchain. See mingw64-x86_64-gcc-core, mingw64-x86_64-gcc-objc, mingw64-x86_64-gcc-ada, mingw64-x86_64-gcc-g++ and mingw64-x86_64-gcc-fortran for binaries. Great stuff. First issue: Is this to be expected? $ x86_64-w64-mingw32-gcc hello.c [compiles fine] $ /bin/x86_64-w64-mingw32-gcc hello.c /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler messages: /Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error: bad register name `%rbp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:11: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:12: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:14: Error: bad register name `%rip)' It's obviously picking up the wrong assembler that way. $ /bin/x86_64-w64-mingw32-gcc hello.c -v Using built-in specs. COLLECT_GCC=/bin/x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: /home/user/cygp6/mingw64-x86_64-gcc/mingw64-x86_64-gcc-4.5.1-1/src/gcc-4.5.1/configure --srcdir=/home/user/cygp6/mingw64-x86_64-gcc/mingw64-x86_64-gcc-4.5.1-1/src/gcc-4.5.1 -C --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/mingw64-x86_64-gcc --build=i686-pc-cygwin --host=i686-pc-cygwin --target=x86_64-w64-mingw32 --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --with-build-sysroot=/usr/x86_64-w64-mingw32/sys-root --disable-multilib --disable-win32-registry --enable-languages=c,ada,c++,fortran,objc,obj-c++ --enable-fully-dynamic-strings --enable-libgomp --enable-sjlj-exceptions --enable-version-specific-runtime-libs --with-dwarf2 --enable-decimal-float=bid --enable-lto Thread model: win32 gcc version 4.5.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/cc1.exe -quiet -v -iprefix /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/ hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o /Users/Andy/AppData/Local/Temp/ccLGdDIT.s GNU C (GCC) version 4.5.1 (x86_64-w64-mingw32) compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include" ignoring nonexistent directory "/usr/x86_64-w64-mingw32/sys-root/usr/local/include" ignoring duplicate directory "/bin/../lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.1/include" ignoring duplicate directory "/bin/../lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.1/include-fixed" ignoring nonexistent directory "/bin/../lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include" #include "..." search starts here: #include<...> search starts here: /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/include /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/include-fixed /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list. GNU C (GCC) version 4.5.1 (x86_64-w64-mingw32) compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 80e7a582a443f3cfd9d86919d58b0d54 COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' as -v -o /Users/Andy/AppData/Local/Temp/ccD8vdf5.o /Users/Andy/AppData/Local/Temp/ccLGdDIT.s GNU assembler version 2.20.51 (i686-cygwin) using BFD version (GNU Binutils) 2.20.51.20100410 /Users/Andy/AppData/Local/Temp/ccLGdDIT.s: Assembler messages: /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:10: Error: bad register name `%rbp' /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:11: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:12: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:14: Error: bad register name `%rip)' Andy That is weird. Do you have mingw64 binutils installed? Somehow the cygwin binutils was used. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 14 September 2010 03:13, JonY wrote: > Version 4.5.1-1 of "mingw64-x86_64-gcc" has been uploaded. > > mingw64-x86_64-gcc contains GCC sources used by the 64bit target toolchain. > See mingw64-x86_64-gcc-core, mingw64-x86_64-gcc-objc, > mingw64-x86_64-gcc-ada, mingw64-x86_64-gcc-g++ and > mingw64-x86_64-gcc-fortran for binaries. Great stuff. First issue: Is this to be expected? $ x86_64-w64-mingw32-gcc hello.c [compiles fine] $ /bin/x86_64-w64-mingw32-gcc hello.c /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler messages: /Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error: bad register name `%rbp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:11: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:12: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:14: Error: bad register name `%rip)' It's obviously picking up the wrong assembler that way. $ /bin/x86_64-w64-mingw32-gcc hello.c -v Using built-in specs. COLLECT_GCC=/bin/x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: /home/user/cygp6/mingw64-x86_64-gcc/mingw64-x86_64-gcc-4.5.1-1/src/gcc-4.5.1/configure --srcdir=/home/user/cygp6/mingw64-x86_64-gcc/mingw64-x86_64-gcc-4.5.1-1/src/gcc-4.5.1 -C --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/mingw64-x86_64-gcc --build=i686-pc-cygwin --host=i686-pc-cygwin --target=x86_64-w64-mingw32 --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --with-build-sysroot=/usr/x86_64-w64-mingw32/sys-root --disable-multilib --disable-win32-registry --enable-languages=c,ada,c++,fortran,objc,obj-c++ --enable-fully-dynamic-strings --enable-libgomp --enable-sjlj-exceptions --enable-version-specific-runtime-libs --with-dwarf2 --enable-decimal-float=bid --enable-lto Thread model: win32 gcc version 4.5.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/cc1.exe -quiet -v -iprefix /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/ hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o /Users/Andy/AppData/Local/Temp/ccLGdDIT.s GNU C (GCC) version 4.5.1 (x86_64-w64-mingw32) compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include" ignoring nonexistent directory "/usr/x86_64-w64-mingw32/sys-root/usr/local/include" ignoring duplicate directory "/bin/../lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.1/include" ignoring duplicate directory "/bin/../lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.1/include-fixed" ignoring nonexistent directory "/bin/../lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include" #include "..." search starts here: #include <...> search starts here: /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/include /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/include-fixed /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list. GNU C (GCC) version 4.5.1 (x86_64-w64-mingw32) compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 80e7a582a443f3cfd9d86919d58b0d54 COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' as -v -o /Users/Andy/AppData/Local/Temp/ccD8vdf5.o /Users/Andy/AppData/Local/Temp/ccLGdDIT.s GNU assembler version 2.20.51 (i686-cygwin) using BFD version (GNU Binutils) 2.20.51.20100410 /Users/Andy/AppData/Local/Temp/ccLGdDIT.s: Assembler messages: /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:10: Error: bad register name `%rbp' /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:11: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:12: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:14: Error: bad register name `%rip)' Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
Version 4.5.1-1 of "mingw64-x86_64-gcc" has been uploaded. mingw64-x86_64-gcc contains GCC sources used by the 64bit target toolchain. See mingw64-x86_64-gcc-core, mingw64-x86_64-gcc-objc, mingw64-x86_64-gcc-ada, mingw64-x86_64-gcc-g++ and mingw64-x86_64-gcc-fortran for binaries. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
