From: Kai T. <Kai...@on...> - 2006-09-22 09:48:25
Attachments:
gcc-4.1.1_x86_64-mingw64.diff.bz2
|
Hallo all, To ease the further discussion and, I append to this mail my prototype patch version of the x86_64-pc-mingw64 port for the gcc.4.1.1 . Of course it is all but not complete and more to treat as a suggestion, but it is allready useable to cross compile sources and to produce target executable applications in combination with the binutils for this new target. The patch includes the changes to the make-files and the gcc/config/i386 target-configuration files. In most places it reuses the pe & mingw-support allready present. The main difference are the usage of the x86_64 cpu code generation, definition of the "long long" type as 16 byte integer (in i386.c), the enforced usage of dwarf2 debugging information, some assembly translations (e.G. cygwin64.asm) , and the introduction of some new predefined macros I list below. Additionally the linker-spec and and STANDARD_INCLUDE_DIR are set to new values for this target to not interferre. The new predefined macros are __MINGW64__, _WIN64,_NATIVE_WCHAR_T_DEFINED,_WCHAR_T_DEFINED,_INTEGRAL_MAX_BITS=64,WIN64, and WINNT64. To build, it do the following steps. 1) Patch the gcc 4.1.1 2) Enter into the src dir and create a build-directory. 3) Enter into it and configure it via "../configure --target=x86_64-pc-mingw64 --disable-nls --without-headers --with-newlib" 4) Build it by using the command "make all-gcc". And then may install it by the command "make install-gcc" May this helps, Regrads, i.A. Kai Tietz |
From: Earnie B. <ea...@us...> - 2006-09-22 11:29:13
|
Quoting Kai Tietz <Kai...@on...>: > > To build, it do the following steps. > 1) Patch the gcc 4.1.1 > 2) Enter into the src dir and create a build-directory. > 3) Enter into it and configure it via "../configure > --target=x86_64-pc-mingw64 --disable-nls --without-headers --with-newlib" > 4) Build it by using the command "make all-gcc". And then may install it > by the command "make install-gcc" > Does this work with MSYS? If yes then perhaps a mingwPORT is in order to apply your patches and configure with your switches. Earnie Boyd -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** http://shop.siebunlimited.com http://www.thedeathofadsense.com/cgi-bin/go.cgi/5830 |
From: Kai T. <Kai...@on...> - 2006-09-22 12:19:25
|
Quoting Earnie Boyd <Earnie Boyd <ea...@us...>: > Does this work with MSYS? If yes then perhaps a mingwPORT is in order > to apply your patches and configure with your switches. Yes, for a mingw32 host it should work, as I saw in libiberty. Cheers, i.A. Kai Tietz |
From: Earnie B. <ea...@us...> - 2006-09-22 13:25:36
|
Quoting Kai Tietz <Kai...@on...>: > Quoting Earnie Boyd <Earnie Boyd <ea...@us...>: > >> Does this work with MSYS? If yes then perhaps a mingwPORT is in order >> to apply your patches and configure with your switches. > > Yes, for a mingw32 host it should work, as I saw in libiberty. > If you could checkout the portmaker from CVS then create a mingwPORT for mingw64-cross it would be useful. PPL have already been asking for 64 bit targets and I think this should help. Instruct the users via the README to report the bugs to the MinGW bug tracker and not to gcc proper since your patches have yet to be accepted by gcc maintainers. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** http://shop.siebunlimited.com http://www.thedeathofadsense.com/cgi-bin/go.cgi/5830 |
From: Keith M. <kei...@nt...> - 2006-09-22 18:51:55
|
On Friday 22 September 2006 2:25 pm, Earnie Boyd wrote: > Quoting Kai Tietz <Kai...@on...>: > > Quoting Earnie Boyd <Earnie Boyd <ea...@us...>: > >> Does this work with MSYS? If yes then perhaps a mingwPORT is in > >> order to apply your patches and configure with your switches. > > > > Yes, for a mingw32 host it should work, as I saw in libiberty. > > If you could checkout the portmaker from CVS then create a mingwPORT > for mingw64-cross it would be useful. PPL have already been asking for > 64 bit targets and I think this should help. I wonder if a pure mingwPORT, based on the current portmaker, is the best approach here. I've recently been looking at Michael's xmingw32 cross compiler build script, with a view to adapting it for convergence with the portmaker technology; perhaps a derivative of that may be more appropriate here. I've already mentioned privately to Michael, that we should consider bringing that cross compiler build script into CVS. I'd planned to hold off on that, until we get the structure better defined, but maybe we should bring it forward, even if still in embryonic form? If so, should we use the sourceforge repository, (which is where portmaker resides), or should we go for the sourceware repository? Regards, Keith. |