From: François D. <fra...@fr...> - 2008-11-06 21:12:15
|
Hi I would like to help MinGW to get a better localization support. To do so I first need to be able to build libstdc++ and associated unit tests coming from SVN trunk or 4.3 branch. Has anyone already do something like that ? How the configure script should be invoked ? Thanks |
From: Roumen P. <bug...@ro...> - 2008-11-06 22:46:03
|
François Dumont wrote: > Hi > > I would like to help MinGW to get a better localization support. To > do so I first need to be able to build libstdc++ and associated unit > tests coming from SVN trunk or 4.3 branch. Has anyone already do > something like that ? How the configure script should be invoked ? > > Thanks With locales, mingw - yes. But with libstdc++ no. I guess that libstdc++ call function setlocale(). Since this function on win platform support limited number of languages/countries (about 20-30) so I'm not interesting. The win-platform itself support about 140-160 languages/countries but when is used winapi. Before three months I port libxslt locale support to use winapi. Roumen |
From: François D. <fra...@fr...> - 2008-11-07 22:07:52
|
I know that for the moment the MinGW libstdc++ package is limited to the "C" locale, this is what I would like to improve. I have already do so for STLport and would like to help MinGW now. But I won't try to do anything if I am not able to build an SVN version of libstdc++ and the associated test suite. For the moment I have checkout SVN trunk and 4.3 branch and when I call the configure script in any branch I have: configure: error: cannot find install-sh or install.sh in . ./.. ./../.. Any hint ? Bests Roumen Petrov wrote: > François Dumont wrote: > >> Hi >> >> I would like to help MinGW to get a better localization support. To >> do so I first need to be able to build libstdc++ and associated unit >> tests coming from SVN trunk or 4.3 branch. Has anyone already do >> something like that ? How the configure script should be invoked ? >> >> Thanks >> > > With locales, mingw - yes. But with libstdc++ no. > > I guess that libstdc++ call function setlocale(). Since this function on > win platform support limited number of languages/countries (about > 20-30) so I'm not interesting. > > The win-platform itself support about 140-160 languages/countries but > when is used winapi. Before three months I port libxslt locale support > to use winapi. > > Roumen > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Vincent T. <vt...@un...> - 2008-11-07 22:30:41
|
On Fri, 7 Nov 2008, François Dumont wrote: > I know that for the moment the MinGW libstdc++ package is limited to > the "C" locale, this is what I would like to improve. I have already do > so for STLport and would like to help MinGW now. But I won't try to do > anything if I am not able to build an SVN version of libstdc++ and the > associated test suite. > > For the moment I have checkout SVN trunk and 4.3 branch and when I > call the configure script in any branch I have: > > configure: error: cannot find install-sh or install.sh in . ./.. ./../.. If I'm not mistaken, install.sh is installed by automake. Maybe you can try to launch 'autoreconf -f -i' to regenerate all the needed files Vincent |
From: Brian D. <br...@de...> - 2008-11-08 01:41:56
|
François Dumont wrote: > For the moment I have checkout SVN trunk and 4.3 branch and when I > call the configure script in any branch I have: > > configure: error: cannot find install-sh or install.sh in . ./.. ./../.. libstdc++ is not a separate entity from gcc, you cannot build it in isolation -- they are very closely coupled. It sounds like you're checking out just part of the gcc tree and running the configure script of a sub-directory. That won't work. You have to run the top-level configure script. As long as you have enabled the C++ language, libstdc++ will be built. You can limit it to --enable-languages=c,c++ if you don't want to build the other default languages like gfortran. If that doesn't describe the problem then please state exactly what it is you've tried, i.e. the exact commands. Brian |
From: Roumen P. <bug...@ro...> - 2008-11-08 15:08:34
|
Brian Dessent wrote: > François Dumont wrote: > >> For the moment I have checkout SVN trunk and 4.3 branch and when I >> call the configure script in any branch I have: >> >> configure: error: cannot find install-sh or install.sh in . ./.. ./../.. > > libstdc++ is not a separate entity from gcc, you cannot build it in > isolation -- they are very closely coupled. It sounds like you're > checking out just part of the gcc tree and running the configure script > of a sub-directory. That won't work. You have to run the top-level > configure script. [SNIP] If subdirectory configure scripts don't work project has to remove it or to fix problem. Otherwise is expected scripts to work and is normal user to use them. The configure script in a subdirectory mean that project use independent package - see autoconf macro AC_CONFIG_SUBDIRS. Roumen |
From: John E. / T. <td...@td...> - 2008-11-08 17:09:47
|
Brian Dessent wrote: > François Dumont wrote: > > >> For the moment I have checkout SVN trunk and 4.3 branch and when I >> call the configure script in any branch I have: >> >> configure: error: cannot find install-sh or install.sh in . ./.. ./../.. >> > > libstdc++ is not a separate entity from gcc, you cannot build it in > isolation -- they are very closely coupled. It sounds like you're > checking out just part of the gcc tree and running the configure script > of a sub-directory. That won't work. You have to run the top-level > configure script. As long as you have enabled the C++ language, > libstdc++ will be built. You can limit it to --enable-languages=c,c++ > if you don't want to build the other default languages like gfortran. > Brian is correct; libstdc++ is designed to build with a just-built version of GCC. Here are the commands I would use: (Always from a directory outside the GCC source tree!) ../gcc-4.3/configure --prefix=/mingw --build=mingw32 \ --enable-languages=c,c++ --enable-sjlj-exceptions \ --disable-werror --disable-bootstrap make make install DESTDIR=<staging area> You should be able to do this with any of MinGW's recent GCC releases in PATH, but I've only done it recently with a custom 4.3.2 build. You *must* build GMP and MPFR (or obtain pre-built versions); I like to use the C_INCLUDE_PATH and LIBRARY_PATH environment variables to make GCC aware of them without having to include their paths on the configure line. -John E. / TDM |
From: François D. <fra...@fr...> - 2008-11-16 21:28:44
|
Hi I am sorry to insist on this point but I really think that a good localization support would be a great enhancement for MinGW. So here are the last lines I have when I run make to build the complete gcc package for C and C++ language using the configure command advised in this thread: No need to remake target `cpp.exe'. Considering target file `specs'. File `specs' does not exist. Pruning file `xgcc.exe'. Finished prerequisites of target file `specs'. Must remake target `specs'. c;C:\Utils\msys\1.0\Utils\gcc-build\gcc\xgcc -Bc;C:\Utils\msys\1.0\Utils\gcc-build\gcc\ -Lc;C:\Utils\msys\1.0\Utils\gcc-build\mingw32\winsup\mingw -Lc;C:\Utils\msys\1.0\Utils\gcc-build\mingw32\winsup\w32api\lib -isystem c;C:\Utils\msys\1.0\Utils\gcc\trunk\winsup\mingw\include -isystem c;C:\Utils\msys\1.0\Utils\gcc\trunk\winsup\w32api\include -BC;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\bin\ -BC;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\lib\ -isystem C;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\include -isystem C;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\sys-include -dumpspecs > tmp-specs CreateProcess(C:\Utils\msys\1.0\bin\sh.exe,C:/Utils/msys/1.0/bin/sh.exe -c "c;C:\Utils\msys\1.0\Utils\gcc-build\gcc\xgcc -Bc;C:\Utils\msys\1.0\Utils\gcc-build\gcc\ -Lc;C:\Utils\msys\1.0\Utils\gcc-build\mingw32\winsup\mingw -Lc;C:\Utils\msys\1.0\Utils\gcc-build\mingw32\winsup\w32api\lib -isystem c;C:\Utils\msys\1.0\Utils\gcc\trunk\winsup\mingw\include -isystem c;C:\Utils\msys\1.0\Utils\gcc\trunk\winsup\w32api\include -BC;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\bin\ -BC;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\lib\ -isystem C;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\include -isystem C;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\sys-include -dumpspecs > tmp-specs",...) Putting child 0x00fb37f8 (specs) PID 16505408 on the chain. Live child 0x00fb37f8 (specs) PID 16505408 /usr/bin/sh: c: command not found /usr/bin/sh: C:Utilsmsys1.0Utilsgcc-buildgccxgcc: command not found /usr/bin/sh: C:Utilsmsys1.0Utilsgcc-buildgcc -Lc: command not found The build script is generating a really weird command. I guess there must be some trouble with management of '/' or '\' or with the C: problem exposed in this thread too. Do you know how I can debug this problem ? Thanks John E. / TDM wrote: > Brian Dessent wrote: > >> François Dumont wrote: >> >> >> >>> For the moment I have checkout SVN trunk and 4.3 branch and when I >>> call the configure script in any branch I have: >>> >>> configure: error: cannot find install-sh or install.sh in . ./.. ./../.. >>> >>> >> libstdc++ is not a separate entity from gcc, you cannot build it in >> isolation -- they are very closely coupled. It sounds like you're >> checking out just part of the gcc tree and running the configure script >> of a sub-directory. That won't work. You have to run the top-level >> configure script. As long as you have enabled the C++ language, >> libstdc++ will be built. You can limit it to --enable-languages=c,c++ >> if you don't want to build the other default languages like gfortran. >> >> > > Brian is correct; libstdc++ is designed to build with a just-built > version of GCC. > > Here are the commands I would use: (Always from a directory outside the > GCC source tree!) > > ../gcc-4.3/configure --prefix=/mingw --build=mingw32 \ > --enable-languages=c,c++ --enable-sjlj-exceptions \ > --disable-werror --disable-bootstrap > > make > > make install DESTDIR=<staging area> > > > You should be able to do this with any of MinGW's recent GCC releases in > PATH, but I've only done it recently with a custom 4.3.2 build. You > *must* build GMP and MPFR (or obtain pre-built versions); I like to use > the C_INCLUDE_PATH and LIBRARY_PATH environment variables to make GCC > aware of them without having to include their paths on the configure line. > > -John E. / TDM > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > > |
From: John E. / T. <td...@td...> - 2008-11-16 21:43:39
|
François Dumont wrote: > Hi > > I am sorry to insist on this point but I really think that a good > localization support would be a great enhancement for MinGW. I absolutely concur. > So here are > the last lines I have when I run make to build the complete gcc package > for C and C++ language using the configure command advised in this thread: > > No need to remake target `cpp.exe'. > Considering target file `specs'. > File `specs' does not exist. > Pruning file `xgcc.exe'. > Finished prerequisites of target file `specs'. > Must remake target `specs'. > c;C:\Utils\msys\1.0\Utils\gcc-build\gcc\xgcc > -Bc;C:\Utils\msys\1.0\Utils\gcc-build\gcc\ > -Lc;C:\Utils\msys\1.0\Utils\gcc-build\mingw32\winsup\mingw > -Lc;C:\Utils\msys\1.0\Utils\gcc-build\mingw32\winsup\w32api\lib -isystem > c;C:\Utils\msys\1.0\Utils\gcc\trunk\winsup\mingw\include -isystem > c;C:\Utils\msys\1.0\Utils\gcc\trunk\winsup\w32api\include > -BC;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\bin\ > -BC;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\lib\ -isystem > C;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\include -isystem > C;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\sys-include -dumpspecs > >> tmp-specs >> > CreateProcess(C:\Utils\msys\1.0\bin\sh.exe,C:/Utils/msys/1.0/bin/sh.exe > -c "c;C:\Utils\msys\1.0\Utils\gcc-build\gcc\xgcc > -Bc;C:\Utils\msys\1.0\Utils\gcc-build\gcc\ > -Lc;C:\Utils\msys\1.0\Utils\gcc-build\mingw32\winsup\mingw > -Lc;C:\Utils\msys\1.0\Utils\gcc-build\mingw32\winsup\w32api\lib -isystem > c;C:\Utils\msys\1.0\Utils\gcc\trunk\winsup\mingw\include -isystem > c;C:\Utils\msys\1.0\Utils\gcc\trunk\winsup\w32api\include > -BC;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\bin\ > -BC;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\lib\ -isystem > C;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\include -isystem > C;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\sys-include -dumpspecs > >> tmp-specs",...) >> > Putting child 0x00fb37f8 (specs) PID 16505408 on the chain. > Live child 0x00fb37f8 (specs) PID 16505408 > /usr/bin/sh: c: command not found > /usr/bin/sh: C:Utilsmsys1.0Utilsgcc-buildgccxgcc: command not found > /usr/bin/sh: C:Utilsmsys1.0Utilsgcc-buildgcc -Lc: command not found > > The build script is generating a really weird command. I guess there > must be some trouble with management of '/' or '\' or with the C: > problem exposed in this thread too. Do you know how I > can debug this problem ? > Unfortunately, I've never seen that before and none of it is at all meaningful to me. What versions of the MSYS runtime, make, and GCC binaries are you using, and where is each installed? What is your environment? Are you trying to do this in the MSYS self-development mode? (You shouldn't be.) -John E. |
From: François D. <fra...@fr...> - 2008-11-18 21:00:39
|
John E. / TDM wrote: >> Unfortunately, I've never seen that before and none of it is at all >> meaningful to me. >> >> What versions of the MSYS runtime, make, and GCC binaries are you using, >> and where is each installed? What is your environment? Are you trying to >> do this in the MSYS self-development mode? (You shouldn't be.) >> I haven't upgrade MSys for a rather long time so I guess I must be using version 1.10.0, how do I know otherwise ? make --version GNU Make 3.81 gcc --version gcc.exe (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502 I haven't try with official release but I try to build it using Cygwin gcc 3.4.4 and it is not enough, build of gcc trunk is using a special gcc option no available in this version. Is there any gcc version requirement to build gcc ? What is the MSys self-development mode ? I run the configure and make command in MSys. Am I supposed to run it in a simple Windows Cmd shell ? Thanks for your help. |
From: Earnie B. <ea...@us...> - 2008-11-19 13:25:41
|
Quoting François Dumont <fra...@fr...>: > I haven't upgrade MSys for a rather long time so I guess I must be using > version 1.10.0, how do I know otherwise ? > Issuing the command ``uname -a'' will give you the MSYS version and build date. Earnie |
From: NS <nig...@gm...> - 2008-11-19 14:22:22
|
François Dumont wrote: > John E. / TDM wrote: > >>> Unfortunately, I've never seen that before and none of it is at all >>> meaningful to me. >>> >>> What versions of the MSYS runtime, make, and GCC binaries are you using, >>> and where is each installed? What is your environment? Are you trying to >>> do this in the MSYS self-development mode? (You shouldn't be.) >>> >>> > I haven't upgrade MSys for a rather long time so I guess I must be using > version 1.10.0, how do I know otherwise ? > > make --version > GNU Make 3.81 > > gcc --version > gcc.exe (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502 > > I haven't try with official release but I try to build it using Cygwin > gcc 3.4.4 and it is not enough, build of gcc trunk is using a special > gcc option no available in this version. Is there any gcc version > requirement to build gcc ? > If you are trying to build gcc/libstdc++ for mingw32 with gcc's svn trunk, you can't use anything prior to revision 141965. There was an issue on the trunk that broke the build for about two months. It was fixed yesterday/this morning. See gcc PR38130: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130 |
From: François D. <fra...@fr...> - 2008-11-19 22:04:51
|
uname -a MINGW32_NT-5.1 PORTABLE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown I just update SVN trunk and rebuild all from start with the same result. I have downloaded make manual to try to understand what is happening. However I wonder who built the gcc packages offered on MinGW download page ? Is it always so complicated to do so or is it simply that I am a victim of the usual trunk version instability ? Bests NS wrote: > François Dumont wrote: > >> John E. / TDM wrote: >> >> >>>> Unfortunately, I've never seen that before and none of it is at all >>>> meaningful to me. >>>> >>>> What versions of the MSYS runtime, make, and GCC binaries are you using, >>>> and where is each installed? What is your environment? Are you trying to >>>> do this in the MSYS self-development mode? (You shouldn't be.) >>>> >>>> >>>> >> I haven't upgrade MSys for a rather long time so I guess I must be using >> version 1.10.0, how do I know otherwise ? >> >> make --version >> GNU Make 3.81 >> >> gcc --version >> gcc.exe (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502 >> >> I haven't try with official release but I try to build it using Cygwin >> gcc 3.4.4 and it is not enough, build of gcc trunk is using a special >> gcc option no available in this version. Is there any gcc version >> requirement to build gcc ? >> >> > If you are trying to build gcc/libstdc++ for mingw32 with gcc's svn > trunk, you can't use anything prior to revision 141965. There was an > issue on the trunk that broke the build for about two months. It was > fixed yesterday/this morning. See gcc PR38130: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130 > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > > |
From: NS <nig...@gm...> - 2008-11-20 15:28:48
|
François Dumont wrote: > uname -a > MINGW32_NT-5.1 PORTABLE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown > > I just update SVN trunk and rebuild all from start with the same result. > > I have downloaded make manual to try to understand what is happening. > > However I wonder who built the gcc packages offered on MinGW download > page ? Is it always so complicated to do so or is it simply that I am a > victim of the usual trunk version instability ? > > Bests > > NS wrote: > >> François Dumont wrote: >> >> >>> John E. / TDM wrote: >>> >>> >>> >>>>> Unfortunately, I've never seen that before and none of it is at all >>>>> meaningful to me. >>>>> >>>>> What versions of the MSYS runtime, make, and GCC binaries are you using, >>>>> and where is each installed? What is your environment? Are you trying to >>>>> do this in the MSYS self-development mode? (You shouldn't be.) >>>>> >>>>> >>>>> >>>>> >>> I haven't upgrade MSys for a rather long time so I guess I must be using >>> version 1.10.0, how do I know otherwise ? >>> >>> make --version >>> GNU Make 3.81 >>> >>> gcc --version >>> gcc.exe (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502 >>> >>> I haven't try with official release but I try to build it using Cygwin >>> gcc 3.4.4 and it is not enough, build of gcc trunk is using a special >>> gcc option no available in this version. Is there any gcc version >>> requirement to build gcc ? >>> >>> >>> >> If you are trying to build gcc/libstdc++ for mingw32 with gcc's svn >> trunk, you can't use anything prior to revision 141965. There was an >> issue on the trunk that broke the build for about two months. It was >> fixed yesterday/this morning. See gcc PR38130: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130 >> > uname -a > MINGW32_NT-5.1 PORTABLE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown > > I just update SVN trunk and rebuild all from start with the same result. > > I have downloaded make manual to try to understand what is happening. > > However I wonder who built the gcc packages offered on MinGW download > page ? Is it always so complicated to do so or is it simply that I am a > victim of the usual trunk version instability ? > Aaron built them, and he disappeared for a bit after the hurricane hit his town. Kai has worked tirelessly to make the build much easier, and right now, you don't need to do that much, even for 32-bit windows. I guess it might be harder to build it in msys, simply because msys isn't trivial to use and have working properly. However, the gcc build itself is easy. To get around the current issues on gcc svn trunk with mingw, disable c++ for now. Add to your configure line "--enable-languages=c". |
From: Kai T. <Kai...@on...> - 2008-11-21 07:14:48
|
NS <nig...@gm...> wrote on 20.11.2008 16:28:33: > François Dumont wrote: > > uname -a > > MINGW32_NT-5.1 PORTABLE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown > > > > I just update SVN trunk and rebuild all from start with the same result. > > > > I have downloaded make manual to try to understand what is happening. > > > > However I wonder who built the gcc packages offered on MinGW download > > page ? Is it always so complicated to do so or is it simply that I am a > > victim of the usual trunk version instability ? > > > > Bests > > > > NS wrote: > > > >> François Dumont wrote: > >> > >> > >>> John E. / TDM wrote: > >>> > >>> > >>> > >>>>> Unfortunately, I've never seen that before and none of it is at all > >>>>> meaningful to me. > >>>>> > >>>>> What versions of the MSYS runtime, make, and GCC binaries are > you using, > >>>>> and where is each installed? What is your environment? Are youtrying to > >>>>> do this in the MSYS self-development mode? (You shouldn't be.) > >>>>> > >>>>> > >>>>> > >>>>> > >>> I haven't upgrade MSys for a rather long time so I guess I must be using > >>> version 1.10.0, how do I know otherwise ? > >>> > >>> make --version > >>> GNU Make 3.81 > >>> > >>> gcc --version > >>> gcc.exe (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502 > >>> > >>> I haven't try with official release but I try to build it using Cygwin > >>> gcc 3.4.4 and it is not enough, build of gcc trunk is using a special > >>> gcc option no available in this version. Is there any gcc version > >>> requirement to build gcc ? > >>> > >>> > >>> > >> If you are trying to build gcc/libstdc++ for mingw32 with gcc's svn > >> trunk, you can't use anything prior to revision 141965. There was an > >> issue on the trunk that broke the build for about two months. It was > >> fixed yesterday/this morning. See gcc PR38130: > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130 > >> > > uname -a > > MINGW32_NT-5.1 PORTABLE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown > > > > I just update SVN trunk and rebuild all from start with the same result. > > > > I have downloaded make manual to try to understand what is happening. > > > > However I wonder who built the gcc packages offered on MinGW download > > page ? Is it always so complicated to do so or is it simply that I am a > > victim of the usual trunk version instability ? > > > > Aaron built them, and he disappeared for a bit after the hurricane hit > his town. Kai has worked tirelessly to make the build much easier, and > right now, you don't need to do that much, even for 32-bit windows. I > guess it might be harder to build it in msys, simply because msys isn't > trivial to use and have working properly. However, the gcc build itself > is easy. > > To get around the current issues on gcc svn trunk with mingw, disable > c++ for now. Add to your configure line "--enable-languages=c". I found the issue about mingw and libstdc++. You have to have in gcc-root directory the folder(or link) named "winsup" for building libstdc++. Within this "winsup" folder, there must be a "mingw" folder. And within this "mingw" folder the crt "include" and "lib" folder have to be placed. If you building with-sysroot, then you can add in gcc-root the link "winsup" pointing to your root folder. In your sysroot folder you have to add the link "mingw" pointing to the "i686-pc-mingw32" folder. When you are doing this, gcc libstdc++ build will be successful. Cheers, Kai | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | (")_(") world domination. |
From: Brian D. <br...@de...> - 2008-11-19 22:48:22
|
François Dumont wrote: > c;C:\Utils\msys\1.0\Utils\gcc-build\gcc\xgcc > -Bc;C:\Utils\msys\1.0\Utils\gcc-build\gcc\ > -Lc;C:\Utils\msys\1.0\Utils\gcc-build\mingw32\winsup\mingw > -Lc;C:\Utils\msys\1.0\Utils\gcc-build\mingw32\winsup\w32api\lib -isystem > c;C:\Utils\msys\1.0\Utils\gcc\trunk\winsup\mingw\include -isystem > c;C:\Utils\msys\1.0\Utils\gcc\trunk\winsup\w32api\include > -BC;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\bin\ > -BC;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\lib\ -isystem > C;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\include -isystem > C;C:\Utils\msys\1.0\Utils\msys\1.0\local\mingw32\sys-include -dumpspecs > > tmp-specs This kind of path mangling means that something is incorrectly treating Win32 paths as POSIX paths and is doing a double-conversion. If you treat c:/foo/bar as a POSIX style colon-delimited PATH and you try to convert it to a semicolon-delimited Win32 PATH, you end up with the above. There are two possible causes that come to mind. First, are you using the MinGW or MSYS version of 'make'? Second, are you using an absolute or relative path to configure, i.e. what is $srcdir getting set to? If I recall you need to use MinGW make and a relative path. Brian |
From: John E. / T. <td...@td...> - 2008-11-19 22:28:28
|
Quoting François Dumont <fra...@fr...>: > uname -a > MINGW32_NT-5.1 PORTABLE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown I'm using MSYS 1.0.11, but last time I looked the process of getting there wasn't very obvious to a beginner. Nevertheless, I'd reinstall everything and make sure there aren't any Cygwin tools or old versions of tools cluttering up the environment. > I just update SVN trunk and rebuild all from start with the same result. What you really need to do is run configure, examine the output to make sure everything necessary was detected and everything configured was configured correctly, then run make and examine the output starting at the beginning to make sure no important errors are getting skipped over. If things still don't work, you might try doing a bootstrap from the 3.4.5 MinGW release of GCC (get rid of "--disable-bootstrap" on the configure line and run "make bootstrap" instead of just "make"). > However I wonder who built the gcc packages offered on MinGW download > page ? Is it always so complicated to do so or is it simply that I am a > victim of the usual trunk version instability ? I haven't tried building GCC 4.4 (trunk) yet; 4.3 hasn't given me any particular problems that I recall. When I first tried building GCC for the mingw32 target, it took me a LOT of trial and error to get a correct build; but I attribute that to having followed over-complicated and in many cases inaccurate instructions. For a native build, it really shouldn't be any more complicated than making sure binutils (binaries), w32api and mingw-runtime are in /mingw, making sure a MinGW build of GCC is in PATH, making sure GMP and MPFR are built and specified either on the configure line or in a GCC default path or environment variable, and then running configure and make as previously indicated. Finally, please stop top posting. -John E. |
From: Earnie B. <ea...@us...> - 2008-11-20 12:22:40
|
Quoting "John E. / TDM" <td...@td...>: > Quoting François Dumont <fra...@fr...>: >> uname -a >> MINGW32_NT-5.1 PORTABLE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown > > I'm using MSYS 1.0.11, but last time I looked the process of getting I suspect that some problems will disappear by going to MSYS 1.0.11. You just need the msysCORE file. http://downloads.sourceforge.net/mingw/msysCORE-1.0.11-20080826.tar.gz?use_mirror= You'll need to create a new folder to put it in because you'll not be able to overwrite the open msys-1.0.dll file. Then from the existing /etc copy the fstab file to the new /etc. Caution, do not change directory to the new /bin directory from within the old version of MSYS. You'll lock up the process and/or system and may require a reboot but will at least need to kill the processes from the task manager. Earnie |
From: Earnie B. <ea...@us...> - 2008-11-08 17:38:28
|
Quoting "John E. / TDM" <td...@td...>: > > make install DESTDIR=<staging area> > DESTDIR doesn't work on windows. You must use make install prefix=<staging area> Earnie |
From: John E. / T. <td...@td...> - 2008-11-08 17:49:01
|
Earnie Boyd wrote: > Quoting "John E. / TDM" <td...@td...>: > > >> make install DESTDIR=<staging area> >> >> > > DESTDIR doesn't work on windows. You must use > > make install prefix=<staging area> > Um, yes, it does...I've been using it quite frequently for the past couple of years. "prefix=..." may be the "right" way to do it, but until DESTDIR is removed from the makefile they'll both work in the exact same way. -John E. |
From: Roumen P. <bug...@ro...> - 2008-11-08 20:39:27
|
Earnie Boyd wrote: > Quoting "John E. / TDM" <td...@td...>: > >> make install DESTDIR=<staging area> >> > > DESTDIR doesn't work on windows. You must use > > make install prefix=<staging area> > > Earnie Please explain why DESTDIR doesn't work on windows. It is a bug in project makefiles ? Roumen. |
From: Brian D. <br...@de...> - 2008-11-09 06:04:20
|
Roumen Petrov wrote: > Please explain why DESTDIR doesn't work on windows. > It is a bug in project makefiles ? It doesn't work because you can't prepend a string to a Win32 path with a drive letter to form a valid path. If prefix is c:/foo and DESTDIR is d:/bar then the resulting install line will contain something like d:/bar/c:/foo which is nonsense. However I suspect it works for John because he uses the "identity mount" setup which is required for building a gcc that is relocatable. The result of such a setup is a prefix that is not translated by MSYS into a Win32 path with a drive letter, and so the result of prepending DESTDIR remains a valid path. <http://lists.puremagic.com/pipermail/d.gnu/2006-December/000582.html> Brian |