From: Bob R. <bob...@co...> - 2006-12-14 02:49:27
|
Hi, If I compile this, it fails with mingw, $ g++ --version g++.exe (GCC) 3.4.2 (mingw-special) #include <sstream> class logstream : public ::std::basic_ios<wchar_t> { public: logstream (); }; The error is, C:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/basic_ios.h: In instantiation o f `std::basic_ios<wchar_t, std::char_traits<wchar_t> >': main.cpp:3: instantiated from here C:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/basic_ios.h:67: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' After looking at this error for a while, I don't think it actually is an error. Changing the wchar_t to a char above does compile. This isn't my code, so I can't easily change it. On ubuntu linux, g++ version 3.3.6, 3.4.6, 4.0.4 20060630 and 4.1.2 20060928, both wchar_t and char work in the code above. Any suggestions? Thanks, Bob Rossi |
From: Brian D. <br...@de...> - 2006-12-14 03:33:12
|
Bob Rossi wrote: C:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/basic_ios.h:67: error: no type > named `pos_type' in `struct std::char_traits<wchar_t>' > > After looking at this error for a while, I don't think it actually is an > error. > > Changing the wchar_t to a char above does compile. This isn't my code, > so I can't easily change it. You'll notice that in bits/c++config.h the macro _GLIBCPP_USE_WCHAR_T is not defined, which means that libstdc++'s configure checks determined that the libc (MSVCRT in this case) was not up to snuff and so it's disabled support for wide character variants. I don't know if this is a bug of if MSVCRT just lacks some required functionality. It would be worthwhile to look at the config.log for the build of libstdc++ and see which checks passed and failed. Regardless of anything else, I don't think what you're trying to do will ever work until you get _GLIBCPP_USE_WCHAR_T defined to 1. The main macro responsible for this appears to be GLIBCXX_ENABLE_WCHAR_T in libstdc++/acinlude.m4. I don't know if MSVCRT's lack of iconv() has any bearing here at all, but _GLIBCXX_HAVE_ICONV is also unset. This means that there must not have been a standalone libiconv installed when libstdc++ was configured and built, as it appears that the configury checks for a standalone -liconv if it doesn't find it in -lc. That would be another thing to try, but it's unrealistic to expect the MinGW libstdc++ to be built this way given that it would require all users to have installed libiconv too. > On ubuntu linux, g++ version 3.3.6, 3.4.6, 4.0.4 20060630 and 4.1.2 20060928, > both wchar_t and char work in the code above. Of course it does, those systems have robust libc's. Remember that libstdc++ is based entirely on the libc already present on the system, so it inherits whatever limitations or problems are present there. Brian |
From: Brian D. <br...@de...> - 2006-12-14 06:38:06
|
Brian Dessent wrote: > Can anyone reproduce these failures, or is it just my MSYS that does > this? I did a little more testing and those failures seemed sporadic and random, they occured at various places in the libstdc++ configure, it's definitely some kind of race condition. I worked around it just be rerunning aclocal and autoconf in the libstdc++ dir, which copied in new versions of AC_TRY_COMPILE and AC_CHECK_FUNCS et cetera with updated versions that appear to work around whatever this race is. However, that is still not enough to satisfy libstdc++'s configure. It seems that in order to enable support for wchar_t, it requires: - C99 support (wchar.h wctype.h WCHAR_MIN/MAX WEOF wcslen wmemchr wmemcmp wmemcpy wmemmove wmemset btowc wctob fgetwc fgetws fputwc fputws fwide fwprintf fwscanf swprintf swscanf vfwprintf vswprintf vwprintf wprintf wscanf getwc getwchar mbsinit mbrlen mbrtowc mbsrtowcs wcsrtombs putwc putwchar ungetwc wcrtomb wcstod wcstol wcstoul wcscpy wcsncpy wcscat wcsncat wcscmp wcscoll wcsncmp wcsxfrm wcscspn wcsspn wcstok wcsftime wcschr wcspbrk wcsrchr wcsstr) - MSVCRT provides all these and checks pass - iconv support. Not in MSVCRT, but should be okay with standalone libiconv. However, I could not get the libstdc++ checks to pick up -liconv because the checks are braindead and try to link a bare "iconv ()" function without including iconv.h, which includes a "#define iconv libiconv" as the acutal exported names all begin with libiconv. So this could work, but currently doesn't. (But on a practical standpoint requiring that both users and developer have GNU libiconv installed for a functioning libstdc++ is a real pain.) - langinfo.h, nl_langinfo(). Not in MSVCRT, not in libiconv. Even if the above stuff was fixed this would still not exist, unless someone has written wrappers for this API against the native Windows NLS stuff. So it seems that wchar_t support in libstdc++ is only enabled if all of the above is present, which it is not. So no wchar_t until then. :( Brian |
From: Bob R. <bob...@co...> - 2006-12-14 15:12:11
|
On Wed, Dec 13, 2006 at 10:38:00PM -0800, Brian Dessent wrote: > Brian Dessent wrote: > > > Can anyone reproduce these failures, or is it just my MSYS that does > > this? > > I did a little more testing and those failures seemed sporadic and > random, they occured at various places in the libstdc++ configure, it's > definitely some kind of race condition. I worked around it just be > rerunning aclocal and autoconf in the libstdc++ dir, which copied in new > versions of AC_TRY_COMPILE and AC_CHECK_FUNCS et cetera with updated > versions that appear to work around whatever this race is. > > However, that is still not enough to satisfy libstdc++'s configure. It > seems that in order to enable support for wchar_t, it requires: > > - C99 support (wchar.h wctype.h WCHAR_MIN/MAX WEOF wcslen wmemchr > wmemcmp wmemcpy wmemmove wmemset btowc wctob fgetwc fgetws fputwc fputws > fwide fwprintf fwscanf swprintf swscanf vfwprintf vswprintf vwprintf > wprintf wscanf getwc getwchar mbsinit mbrlen mbrtowc mbsrtowcs wcsrtombs > putwc putwchar ungetwc wcrtomb wcstod wcstol wcstoul wcscpy wcsncpy > wcscat wcsncat wcscmp wcscoll wcsncmp wcsxfrm wcscspn wcsspn wcstok > wcsftime wcschr wcspbrk wcsrchr wcsstr) - MSVCRT provides all these and > checks pass > > - iconv support. Not in MSVCRT, but should be okay with standalone > libiconv. However, I could not get the libstdc++ checks to pick up > -liconv because the checks are braindead and try to link a bare "iconv > ()" function without including iconv.h, which includes a "#define iconv > libiconv" as the acutal exported names all begin with libiconv. So this > could work, but currently doesn't. (But on a practical standpoint > requiring that both users and developer have GNU libiconv installed for > a functioning libstdc++ is a real pain.) > > - langinfo.h, nl_langinfo(). Not in MSVCRT, not in libiconv. Even if > the above stuff was fixed this would still not exist, unless someone has > written wrappers for this API against the native Windows NLS stuff. > > So it seems that wchar_t support in libstdc++ is only enabled if all of > the above is present, which it is not. So no wchar_t until then. :( Hi Brian, Your information here is interesting, and slightly over my head. Is your conclusion that mingw can not support the wchar_t type in it's current state? Thanks, Bob Rossi |
From: Earnie B. <ea...@us...> - 2006-12-14 13:34:52
|
Quoting Brian Dessent <br...@de...>: > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission > denied > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission > denied > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission > denied > sed: can't read conftest.c: Permission denied > rm: cannot remove `conftest.c': Permission denied > no What version of MSYS and snapshot utilities are you executing (the output of ``uname -a'' will tell you and is what I need to see)? You'll need to upgrade your msys-1.0.dll to http://downloads.sf.net/mingw/MSYS-1.0.11-20060807.tar.bz2. 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. * ****************************************************************************** Toshiba Satellite P105-S6114 Notebook http://give-me-an-offer.com/offers/computers/laptop/toshiba PlayStation 3 Auctions http://give-me-an-offer.com/offers/auctions/au1 Samsung HP-S4253 42" High Definition Plasma TV http://give-me-an-offer.com/offers/tv/plasma |
From: Earnie B. <ea...@us...> - 2006-12-14 15:12:32
|
Quoting Bob Rossi <bob...@co...>: > > > I've upgraded, > > $ uname -a > MINGW32_NT-5.1 MOMS 1.0.11(0.46/3/2) 2006-08-07 12:54 i686 unknown > > I still can not compile the example shown. What would you like me to do > next? > Did you start with a fresh build environment and execute the configure script again with the same results? If yes, I'll take a look at what happens for me. 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. * ****************************************************************************** Toshiba Satellite P105-S6114 Notebook http://give-me-an-offer.com/offers/computers/laptop/toshiba PlayStation 3 Auctions http://give-me-an-offer.com/offers/auctions/au1 Samsung HP-S4253 42" High Definition Plasma TV http://give-me-an-offer.com/offers/tv/plasma |
From: Brian D. <br...@de...> - 2006-12-14 04:11:15
|
Brian Dessent wrote: > It would be > worthwhile to look at the config.log for the build of libstdc++ and see > which checks passed and failed. I just tried that, and here is the relevant output: checking for mbstate_t... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking wctype.h usability... yes checking wctype.h presence... ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied sed: can't read conftest.c: Permission denied rm: cannot remove `conftest.c': Permission denied no configure: WARNING: wctype.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: wctype.h: proceeding with the compiler's result checking for wctype.h... yes checking for WCHAR_MIN and WCHAR_MAX... ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied sed: can't read conftest.c: Permission denied rm: cannot remove `conftest.c': Permission denied no checking for WEOF... ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied sed: can't read conftest.c: Permission denied rm: cannot remove `conftest.c': Permission denied no checking for wcslen... ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied sed: can't read conftest.c: Permission denied rm: cannot remove `conftest.c': Permission denied no checking for wmemchr... ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission denied sed: can't read conftest.c: No such file or directory no checking for wmemcmp... yes checking for wmemcpy... yes checking for wmemmove... yes checking for wmemset... yes checking for btowc... yes checking for wctob... yes checking for fgetwc... yes checking for fgetws... yes checking for fputwc... yes checking for fputws... yes checking for fwide... yes checking for fwprintf... yes checking for fwscanf... yes checking for swprintf... yes checking for swscanf... yes checking for vfwprintf... yes checking for vswprintf... yes checking for vwprintf... yes checking for wprintf... yes checking for wscanf... yes checking for getwc... yes checking for getwchar... yes checking for mbsinit... yes checking for mbrlen... yes checking for mbrtowc... yes checking for mbsrtowcs... yes checking for wcsrtombs... yes checking for putwc... yes checking for putwchar... yes checking for ungetwc... yes checking for wcrtomb... yes checking for wcstod... yes checking for wcstol... yes checking for wcstoul... yes checking for wcscpy... yes checking for wcsncpy... yes checking for wcscat... yes checking for wcsncat... yes checking for wcscmp... yes checking for wcscoll... yes checking for wcsncmp... yes checking for wcsxfrm... yes checking for wcscspn... yes checking for wcsspn... yes checking for wcstok... yes checking for wcsftime... yes checking for wcschr... yes checking for wcspbrk... yes checking for wcsrchr... yes checking for wcsstr... yes checking for vfwscanf... yes checking for vswscanf... yes checking for vwscanf... yes checking for wcstof... yes checking for iswblank... no checking for ISO C99 wchar_t support... no checking iconv.h usability... no checking iconv.h presence... no checking for iconv.h... no checking langinfo.h usability... no checking langinfo.h presence... no checking for langinfo.h... no checking for iconv in -liconv... no checking for iconv_open... no checking for iconv_close... no checking for iconv... no checking for nl_langinfo... no checking for XPG2 wchar_t support... no checking for enabled wchar_t specializations... no So, something about those configuration checks is gumming up the works and causing spurious failures it seems, which results in the end product of wchar_t support not being enabled. For reference here is the m4 macro that does the above: dnl dnl Check to see if this target can enable the wchar_t parts. dnl If --disable-c-mbchar was given, no wchar_t stuff is enabled. (This dnl must have been previously checked.) By default, wide characters are dnl disabled. dnl dnl Defines: dnl HAVE_MBSTATE_T if mbstate_t is not in wchar.h dnl _GLIBCXX_USE_WCHAR_T if all the bits are found. dnl AC_DEFUN([GLIBCXX_CHECK_WCHAR_T_SUPPORT], [ # Test wchar.h for mbstate_t, which is needed for char_traits and # others even if wchar_t support is not on. AC_MSG_CHECKING([for mbstate_t]) AC_TRY_COMPILE([#include <wchar.h>], [mbstate_t teststate;], have_mbstate_t=yes, have_mbstate_t=no) AC_MSG_RESULT($have_mbstate_t) if test x"$have_mbstate_t" = xyes; then AC_DEFINE(HAVE_MBSTATE_T) fi # Sanity check for existence of ISO C99 headers for extended encoding. AC_CHECK_HEADERS(wchar.h, ac_has_wchar_h=yes, ac_has_wchar_h=no) AC_CHECK_HEADERS(wctype.h, ac_has_wctype_h=yes, ac_has_wctype_h=no) # Only continue checking if the ISO C99 headers exist and support is on. if test x"$ac_has_wchar_h" = xyes && test x"$ac_has_wctype_h" = xyes && test x"$enable_c_mbchar" != xno; then # Test wchar.h for WCHAR_MIN, WCHAR_MAX, which is needed before # numeric_limits can instantiate type_traits<wchar_t> AC_MSG_CHECKING([for WCHAR_MIN and WCHAR_MAX]) AC_TRY_COMPILE([#include <wchar.h>], [int i = WCHAR_MIN; int j = WCHAR_MAX;], has_wchar_minmax=yes, has_wchar_minmax=no) AC_MSG_RESULT($has_wchar_minmax) # Test wchar.h for WEOF, which is what we use to determine whether # to specialize for char_traits<wchar_t> or not. AC_MSG_CHECKING([for WEOF]) AC_TRY_COMPILE([ #include <wchar.h> #include <stddef.h>], [wint_t i = WEOF;], has_weof=yes, has_weof=no) AC_MSG_RESULT($has_weof) # Tests for wide character functions used in char_traits<wchar_t>. ac_wfuncs=yes AC_CHECK_FUNCS([wcslen wmemchr wmemcmp wmemcpy wmemmove wmemset], [],[ac_wfuncs=no]) # Checks for names injected into std:: by the c_std headers. AC_CHECK_FUNCS([btowc wctob fgetwc fgetws fputwc fputws fwide \ fwprintf fwscanf swprintf swscanf vfwprintf vswprintf \ vwprintf wprintf wscanf getwc getwchar mbsinit mbrlen mbrtowc \ mbsrtowcs wcsrtombs putwc putwchar ungetwc wcrtomb wcstod wcstol \ wcstoul wcscpy wcsncpy wcscat wcsncat wcscmp wcscoll wcsncmp wcsxfrm \ wcscspn wcsspn wcstok wcsftime wcschr wcspbrk wcsrchr wcsstr], [],[ac_wfuncs=no]) # Checks for wide character functions that are not required # for basic wchar_t support. Don't disable support if they are missing. # Injection of these is wrapped with guard macros. AC_CHECK_FUNCS([vfwscanf vswscanf vwscanf wcstof iswblank],[],[]) AC_MSG_CHECKING([for ISO C99 wchar_t support]) if test x"$has_weof" = xyes && test x"$has_wchar_minmax" = xyes && test x"$ac_wfuncs" = xyes; then ac_isoC99_wchar_t=yes else ac_isoC99_wchar_t=no fi AC_MSG_RESULT($ac_isoC99_wchar_t) # Use iconv for wchar_t to char conversions. As such, check for # X/Open Portability Guide, version 2 features (XPG2). AC_CHECK_HEADER(iconv.h, ac_has_iconv_h=yes, ac_has_iconv_h=no) AC_CHECK_HEADER(langinfo.h, ac_has_langinfo_h=yes, ac_has_langinfo_h=no) # Check for existence of libiconv.a providing XPG2 wchar_t support. AC_CHECK_LIB(iconv, iconv, libiconv="-liconv") ac_save_LIBS="$LIBS" LIBS="$LIBS $libiconv" AC_CHECK_FUNCS([iconv_open iconv_close iconv nl_langinfo], [ac_XPG2funcs=yes], [ac_XPG2funcs=no]) LIBS="$ac_save_LIBS" AC_MSG_CHECKING([for XPG2 wchar_t support]) if test x"$ac_has_iconv_h" = xyes && test x"$ac_has_langinfo_h" = xyes && test x"$ac_XPG2funcs" = xyes; then ac_XPG2_wchar_t=yes else ac_XPG2_wchar_t=no fi AC_MSG_RESULT($ac_XPG2_wchar_t) # At the moment, only enable wchar_t specializations if all the # above support is present. if test x"$ac_isoC99_wchar_t" = xyes && test x"$ac_XPG2_wchar_t" = xyes; then AC_DEFINE(_GLIBCXX_USE_WCHAR_T) enable_wchar_t=yes fi fi AC_MSG_CHECKING([for enabled wchar_t specializations]) AC_MSG_RESULT($enable_wchar_t) ]) It looks like there's some kind of race condition that causes configure to still have a handle open for conftest.c before spawning gcc, or something. I can't understand why these few handful of standard AC_TRY_COMPILE tests fail when the overall libstdc++ configure does dozens and dozens of such tests. The config.log output doesn't have any details. The failing WEOF test looks like just this: configure:28148: checking for WEOF configure:28168: gcc -c -g -O2 conftest.c >&5 gcc.exe: conftest.c: Permission denied gcc.exe: no input files configure:28174: $? = 1 configure: failed program was: configure:28197: result: no Can anyone reproduce these failures, or is it just my MSYS that does this? Brian |
From: Bob R. <bob...@co...> - 2006-12-14 13:52:45
|
On Thu, Dec 14, 2006 at 08:34:44AM -0500, Earnie Boyd wrote: > Quoting Brian Dessent <br...@de...>: > > > > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission > > denied > > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission > > denied > > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission > > denied > > sed: can't read conftest.c: Permission denied > > rm: cannot remove `conftest.c': Permission denied > > no > > What version of MSYS and snapshot utilities are you executing (the > output of ``uname -a'' will tell you and is what I need to see)? > You'll need to upgrade your msys-1.0.dll to > http://downloads.sf.net/mingw/MSYS-1.0.11-20060807.tar.bz2. > > Earnie Boyd Hi Earnie, $ uname -a MINGW32_NT-5.1 MOMS 1.0.11(0.46/3/2) 2004-04-30 18:55 i686 unknown Should I upgrade? Thanks, Bob Rossi |
From: Earnie B. <ea...@us...> - 2006-12-14 14:51:16
|
Quoting Bob Rossi <bob...@co...>: > On Thu, Dec 14, 2006 at 08:34:44AM -0500, Earnie Boyd wrote: >> Quoting Brian Dessent <br...@de...>: >> >> >> > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission >> > denied >> > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission >> > denied >> > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission >> > denied >> > sed: can't read conftest.c: Permission denied >> > rm: cannot remove `conftest.c': Permission denied >> > no >> >> What version of MSYS and snapshot utilities are you executing (the >> output of ``uname -a'' will tell you and is what I need to see)? >> You'll need to upgrade your msys-1.0.dll to >> http://downloads.sf.net/mingw/MSYS-1.0.11-20060807.tar.bz2. >> >> Earnie Boyd > > Hi Earnie, > > $ uname -a > MINGW32_NT-5.1 MOMS 1.0.11(0.46/3/2) 2004-04-30 18:55 i686 unknown > > Should I upgrade? > Yes. The changes made for 2004-04-30 caused a race condition that is exercised greatly in the configure scripts. I had to slowdown with a sleep the return from a function which is delivered in the file URI I've given you. This works for me but YMMV with a differing environment. The problem is that the file is marked for deletion and the OS is too slow in getting the file deleted or the handles to the file closed to allow the deletion. UNIX FS would just create a new inode and keep going. Windows FS is stupid. 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. * ****************************************************************************** Toshiba Satellite P105-S6114 Notebook http://give-me-an-offer.com/offers/computers/laptop/toshiba PlayStation 3 Auctions http://give-me-an-offer.com/offers/auctions/au1 Samsung HP-S4253 42" High Definition Plasma TV http://give-me-an-offer.com/offers/tv/plasma |
From: Bob R. <bob...@co...> - 2006-12-14 14:36:35
|
On Thu, Dec 14, 2006 at 08:52:36AM -0500, Bob Rossi wrote: > On Thu, Dec 14, 2006 at 08:34:44AM -0500, Earnie Boyd wrote: > > Quoting Brian Dessent <br...@de...>: > > > > > > > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission > > > denied > > > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission > > > denied > > > ../gcc-3.4.5-20060117-1/libstdc++-v3/configure: conftest.c: Permission > > > denied > > > sed: can't read conftest.c: Permission denied > > > rm: cannot remove `conftest.c': Permission denied > > > no > > > > What version of MSYS and snapshot utilities are you executing (the > > output of ``uname -a'' will tell you and is what I need to see)? > > You'll need to upgrade your msys-1.0.dll to > > http://downloads.sf.net/mingw/MSYS-1.0.11-20060807.tar.bz2. > > > > Earnie Boyd > > Hi Earnie, > > $ uname -a > MINGW32_NT-5.1 MOMS 1.0.11(0.46/3/2) 2004-04-30 18:55 i686 unknown > > Should I upgrade? I've upgraded, $ uname -a MINGW32_NT-5.1 MOMS 1.0.11(0.46/3/2) 2006-08-07 12:54 i686 unknown I still can not compile the example shown. What would you like me to do next? Thanks, Bob Rossi |
From: Keith M. <kei...@to...> - 2006-12-14 15:25:54
|
Bob Rossi wrote: > I've upgraded, > > $ uname -a > MINGW32_NT-5.1 MOMS 1.0.11(0.46/3/2) 2006-08-07 12:54 i686 unknown > > I still can not compile the example shown. What would you like me to > do next? Brian (Dessent) has already explained why that is. Your example needs wide character support in libstdc++, which requires features that aren't provided by MSVCRT; why would you expect upgrading the msys-1.0.dll to magically make the M$ library give you what it lacks? Brian Dessent wrote: > However, that is still not enough to satisfy libstdc++'s configure. > It seems that in order to enable support for wchar_t, it requires: > > - C99 support (wchar.h wctype.h [...]) - MSVCRT provides all these > and checks pass > > - iconv support. Not in MSVCRT, but should be okay with standalone > libiconv. However, I could not get the libstdc++ checks to pick up > -liconv because the checks are braindead ... So, some GCC autoconfigury hacking needed, to get this working. > - langinfo.h, nl_langinfo(). Not in MSVCRT, not in libiconv. > Even if the above stuff was fixed this would still not exist, unless > someone has written wrappers for this API against the native Windows > NLS stuff. FWIW, I've got a *very* rudimentary implementation, (just enough to let `nl_langinfo( CODESET )' return the active codepage). Probably isn't enough for wchar_t support in libstdc++ would require, but if anyone would like to help me develop it further, please contact me off list. > So it seems that wchar_t support in libstdc++ is only enabled if all > of the above is present, which it is not. So no wchar_t until then. Regards, Keith. |
From: Danny S. <dan...@cl...> - 2006-12-14 17:51:47
|
Keith MARSHALL Friday, 15 December 2006 4:23 a.m. > > > - iconv support. Not in MSVCRT, but should be okay with standalone > > libiconv. However, I could not get the libstdc++ checks to pick up > > -liconv because the checks are braindead ... > > So, some GCC autoconfigury hacking needed, to get this working. Already works in GCC 4.x > > > - langinfo.h, nl_langinfo(). Not in MSVCRT, not in libiconv. > > Even if the above stuff was fixed this would still not exist, unless > > someone has written wrappers for this API against the native Windows > > NLS stuff. > Not needed foe wchar_t support in 4.x. Something like nl_langifo needed for locale support. Better option would be to interface directly with w32api, which IMO has cleanner locale model than POSIX anyway. > FWIW, I've got a *very* rudimentary implementation, (just enough to > let `nl_langinfo( CODESET )' return the active codepage). Probably > isn't enough for wchar_t support in libstdc++ would require, but if > anyone would like to help me develop it further, please contact me > off list. > > > So it seems that wchar_t support in libstdc++ is only enabled if all > > of the above is present, which it is not. So no wchar_t until then. Get it now with 4.x. Danny > > Regards, > Keith. > > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge &CID=DEVDEV _______________________________________________ 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: Bob R. <bob...@co...> - 2006-12-14 20:57:35
|
On Fri, Dec 15, 2006 at 06:51:53AM +1300, Danny Smith wrote: > > Keith MARSHALL > Friday, 15 December 2006 4:23 a.m. > > > > > - iconv support. Not in MSVCRT, but should be okay with standalone > > > libiconv. However, I could not get the libstdc++ checks to pick up > > > -liconv because the checks are braindead ... > > > > So, some GCC autoconfigury hacking needed, to get this working. > > Already works in GCC 4.x > > > > > - langinfo.h, nl_langinfo(). Not in MSVCRT, not in libiconv. > > > Even if the above stuff was fixed this would still not exist, unless > > > someone has written wrappers for this API against the native Windows > > > NLS stuff. > > > Not needed foe wchar_t support in 4.x. Something like nl_langifo needed > for locale support. > Better option would be to interface directly with w32api, which IMO has > cleanner locale model than POSIX anyway. > > > FWIW, I've got a *very* rudimentary implementation, (just enough to > > let `nl_langinfo( CODESET )' return the active codepage). Probably > > isn't enough for wchar_t support in libstdc++ would require, but if > > anyone would like to help me develop it further, please contact me > > off list. > > > > > So it seems that wchar_t support in libstdc++ is only enabled if all > > > of the above is present, which it is not. So no wchar_t until then. > > Get it now with 4.x. > > Danny Hi Danny, I'm sort of a mingw noob. Are you saying that if I simply compile GCC 4.x, then this will all magically work? Is there anything special that is done to compile GCC for mingw, or is it simply like doing in on Linux? Does mingw keep patches to GCC? Thanks, Bob Rossi |
From: Earnie B. <ea...@us...> - 2006-12-15 20:30:12
|
Quoting Bob Rossi <bob...@co...>: > > My question is, is there a way that I can build g++ and install it on my > machine so that it doesn't overwrite any of the g++ files that are > already installed? > cp -a /c/mingw /c/mingw-dev cd /build/gcc-4.1 make install prefix=/c/mingw-dev PATH=/c/mingw-dev/bin:$PATH g++ --version > The second question is, is there a standard way of building g++ so that > I can tar it up, and allow someone else to untar it anywhere, and have > it work for them? I'm assumming when you untar it in a directory other > than the one given with --prefix=, it's going to be mad. > cd /build/gcc-4.1 make install prefix=`pwd`/depot cd depot tar -zcf ../gcc-4.1.tar.gz * The only thing that you need is to have the mingw include and lib directory in the same parent as the gcc bin directory because the default search is relative to bin/gcc.exe. 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. * ****************************************************************************** Toshiba Satellite P105-S6114 Notebook http://give-me-an-offer.com/offers/computers/laptop/toshiba PlayStation 3 Auctions http://give-me-an-offer.com/offers/auctions/au1 Samsung HP-S4253 42" High Definition Plasma TV http://give-me-an-offer.com/offers/tv/plasma |
From: Bob R. <bob...@co...> - 2006-12-15 20:34:31
|
On Fri, Dec 15, 2006 at 03:29:56PM -0500, Earnie Boyd wrote: > Quoting Bob Rossi <bob...@co...>: > > > > > My question is, is there a way that I can build g++ and install it on my > > machine so that it doesn't overwrite any of the g++ files that are > > already installed? > > > > cp -a /c/mingw /c/mingw-dev > cd /build/gcc-4.1 > make install prefix=/c/mingw-dev > > PATH=/c/mingw-dev/bin:$PATH g++ --version Wow, I didn't know you could give the prefix rule during the 'make install' step. What happens if g++ has compiled into the prefix=... directory from the ./configure step? > > The second question is, is there a standard way of building g++ so that > > I can tar it up, and allow someone else to untar it anywhere, and have > > it work for them? I'm assumming when you untar it in a directory other > > than the one given with --prefix=, it's going to be mad. > > > > cd /build/gcc-4.1 > make install prefix=`pwd`/depot > cd depot > tar -zcf ../gcc-4.1.tar.gz * > > The only thing that you need is to have the mingw include and lib > directory in the same parent as the gcc bin directory because the > default search is relative to bin/gcc.exe. Wow, that's interesting to. I always thought that the prefix dir was sometimes compiled into the applications, and they depended on them being there. Is this not the case? Bob Rossi |
From: Earnie B. <ea...@us...> - 2006-12-15 23:08:43
|
Quoting Bob Rossi <bob...@co...>: > On Fri, Dec 15, 2006 at 03:29:56PM -0500, Earnie Boyd wrote: >> Quoting Bob Rossi <bob...@co...>: >> >> > >> > My question is, is there a way that I can build g++ and install it on my >> > machine so that it doesn't overwrite any of the g++ files that are >> > already installed? >> > >> >> cp -a /c/mingw /c/mingw-dev >> cd /build/gcc-4.1 >> make install prefix=/c/mingw-dev >> >> PATH=/c/mingw-dev/bin:$PATH g++ --version > > Wow, I didn't know you could give the prefix rule during the 'make > install' step. What happens if g++ has compiled into the prefix=... > directory from the ./configure step? > GCC and friends have never done that in the past that I am aware of. >> > The second question is, is there a standard way of building g++ so that >> > I can tar it up, and allow someone else to untar it anywhere, and have >> > it work for them? I'm assumming when you untar it in a directory other >> > than the one given with --prefix=, it's going to be mad. >> > >> >> cd /build/gcc-4.1 >> make install prefix=`pwd`/depot >> cd depot >> tar -zcf ../gcc-4.1.tar.gz * >> >> The only thing that you need is to have the mingw include and lib >> directory in the same parent as the gcc bin directory because the >> default search is relative to bin/gcc.exe. > > Wow, that's interesting to. I always thought that the prefix dir was > sometimes compiled into the applications, and they depended on them > being there. Is this not the case? > Yes, sometimes. I do consider these broken but most will let you set an environment variable to overcome issues. The files I have built have never shown an issue with this method. You will find issues with the make install prefix=/some/other/prefix method if you also specify other variables that are normally dependent on $prefix during configure because the Makefile will end up hard coded. DESTDIR was created because of hand specifying the variables on the command line at the time of configure. 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. * ****************************************************************************** Toshiba Satellite P105-S6114 Notebook http://give-me-an-offer.com/offers/computers/laptop/toshiba PlayStation 3 Auctions http://give-me-an-offer.com/offers/auctions/au1 Samsung HP-S4253 42" High Definition Plasma TV http://give-me-an-offer.com/offers/tv/plasma |
From: Brian D. <br...@de...> - 2006-12-15 20:38:46
|
Bob Rossi wrote: > > cp -a /c/mingw /c/mingw-dev > > cd /build/gcc-4.1 > > make install prefix=/c/mingw-dev > > > > PATH=/c/mingw-dev/bin:$PATH g++ --version > > Wow, I didn't know you could give the prefix rule during the 'make > install' step. What happens if g++ has compiled into the prefix=... > directory from the ./configure step? The proper way (or at least, the way the gcc configury is designed and as specified in the GNU coding standards) is with DESTDIR and not by overriding prefix. Brian |
From: Earnie B. <ea...@us...> - 2006-12-15 22:56:52
|
Quoting Brian Dessent <br...@de...>: > Bob Rossi wrote: > >> > cp -a /c/mingw /c/mingw-dev >> > cd /build/gcc-4.1 >> > make install prefix=/c/mingw-dev >> > >> > PATH=/c/mingw-dev/bin:$PATH g++ --version >> >> Wow, I didn't know you could give the prefix rule during the 'make >> install' step. What happens if g++ has compiled into the prefix=... >> directory from the ./configure step? > > The proper way (or at least, the way the gcc configury is designed and > as specified in the GNU coding standards) is with DESTDIR and not by > overriding prefix. > No that is *NOT* the proper way based on the GNU coding standard. The coding standard states that for a package that has completely executed the make process that make install prefix=/some/other/prefix isn't allowed to change the build. Therefore make install prefix=/some/other/prefix only affects the install. Note that I use this method as a matter of practice and refuse to use DESTDIR and will repair packages that are broken with this regard. 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. * ****************************************************************************** Toshiba Satellite P105-S6114 Notebook http://give-me-an-offer.com/offers/computers/laptop/toshiba PlayStation 3 Auctions http://give-me-an-offer.com/offers/auctions/au1 Samsung HP-S4253 42" High Definition Plasma TV http://give-me-an-offer.com/offers/tv/plasma |
From: Tor L. <tm...@ik...> - 2006-12-15 23:06:40
|
> >> Wow, I didn't know you could give the prefix rule during the 'make > >> install' step. What happens if g++ has compiled into the prefix=... > >> directory from the ./configure step? Obviously, as end-users are allowed to install mingw anywhere they like and it still works and finds its headers and libraries etc, no configure-time paths are compiled into the binaries. (Or if they are, they aren't actually used at run-time.) Or did I misunderstand your question? --tml |
From: Danny S. <dan...@cl...> - 2006-12-16 00:37:00
|
> > The proper way (or at least, the way the gcc configury is > designed and > > as specified in the GNU coding standards) is with DESTDIR and not by > > overriding prefix. > > > > No that is *NOT* the proper way based on the GNU coding > standard. The > coding standard states that for a package that has completely > executed > the make process that make install prefix=/some/other/prefix isn't > allowed to change the build. Therefore make install > prefix=/some/other/prefix only affects the install. Note that I use > this method as a matter of practice and refuse to use DESTDIR > and will > repair packages that are broken with this regard. > You will need to repair GCC then. 'make prefix=/my_new_prefix install' will cause a a rebuild (a re-bootstrap by default on native) so that configured prefix gets hardcoded into the binary. Its been that way since 4.0, DESTDIR does the right thing. Danny |
From: Bob R. <bob...@co...> - 2006-12-16 02:12:41
|
On Sat, Dec 16, 2006 at 01:37:12PM +1300, Danny Smith wrote: > > > The proper way (or at least, the way the gcc configury is > > designed and > > > as specified in the GNU coding standards) is with DESTDIR and not by > > > overriding prefix. > > > > > > > No that is *NOT* the proper way based on the GNU coding > > standard. The > > coding standard states that for a package that has completely > > executed > > the make process that make install prefix=/some/other/prefix isn't > > allowed to change the build. Therefore make install > > prefix=/some/other/prefix only affects the install. Note that I use > > this method as a matter of practice and refuse to use DESTDIR > > and will > > repair packages that are broken with this regard. > > > > You will need to repair GCC then. > 'make prefix=/my_new_prefix install' > will cause a a rebuild (a re-bootstrap by default on native) so that > configured prefix gets hardcoded into the binary. > Its been that way since 4.0, > DESTDIR does the right thing. > Danny Danny, you package gcc up for mingw right? How do you build a relocatable gcc? Do you do the same thing that ernie posted earlier? Thanks, Bob Rossi |
From: Brian D. <br...@de...> - 2006-12-15 23:48:19
|
Earnie Boyd wrote: > No that is *NOT* the proper way based on the GNU coding standard. The I don't know what GNU coding standard you're reading but the one I am reading clearly states in section 7.2.4 that "we strongly recommend GNU packages support DESTDIR, though it is not an absolute requirement." http://www.gnu.org/prep/standards/standards.html#DESTDIR You say DESTDIR is broken, I say overloading "prefix" by having it take on two conceptually different and unrelated values is broken. Obviously, this is going nowhere useful so I will just stop there. Brian |
From: Earnie B. <ea...@us...> - 2006-12-20 13:12:41
|
Quoting Brian Dessent <br...@de...>: > Earnie Boyd wrote: > >> No that is *NOT* the proper way based on the GNU coding standard. The > > I don't know what GNU coding standard you're reading but the one I am > reading clearly states in section 7.2.4 that "we strongly recommend GNU > packages support DESTDIR, though it is not an absolute requirement." > > http://www.gnu.org/prep/standards/standards.html#DESTDIR > > You say DESTDIR is broken, I say overloading "prefix" by having it take > on two conceptually different and unrelated values is broken. > Obviously, this is going nowhere useful so I will just stop there. > I read the same document you are viz http://www.gnu.org/prep/standards/standards.html#Directory-Variables which says that make install prefix=/any/other/prefix isn't allowed to rebuild the package. <quote> Running ?make install? with a different value of prefix from the one used to build the program should not recompile the program. </quote> Now if you configure using destination switches other than --prefix then DESTDIR has value. The DESTDIR in the GNU Coding Standards document is a more recent entry. DESTDIR helps the installer packages (such as RPM) which by default specify the destination switch values for multiple directories. However, if you do for instance ``configure --prefix=/mingw --exec_prefix=/mingw/sbin && make'' and then do ``make install prefix=/depot/mingw exec_prefix=/depot/mingw/sbin'' you should have the same effect as ``make install DESTDIR=/depot''. This isn't what I usually want when I ready the binary package though. I would typically build the package only specifying --prefix in the configure and then specifying prefix in the make install. If I used DESTDIR then the --prefix value becomes a part of the installation where as if I used prefix then the new value of prefix is used to install into my depot directory. E.G.: configure --prefix=/mingw && make make install prefix=/depot Would install: /depot/bin /depot/include /depot/share ... etc configure --prefix=/mingw && make make install DESTDIR=/depot Would install: /depot/mingw/bin /depot/mingw/include /depot/mingw/share I will have to revise my statements toward DESTDIR with the addition of it in the standards document however packages that rebuild by supplying a different value of prefix or any other destination variable is, by described coding standards definition, broken. 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. |
From: Keith M. <kei...@to...> - 2006-12-20 14:29:13
|
Earnie Boyd wrote, quoting Brian Dessent: >> You say DESTDIR is broken, I say overloading "prefix" by having it >> take on two conceptually different and unrelated values is broken. It has nothing whatsoever to do with *overloading*; it is *overriding*, plain and simple. Ok. So, I've configured for a *native* Win32 build, with a correctly specified `--prefix=c:/mingw'. Now you would have me relocate, after the initial build, by saying: make DESTDIR=/foo/ install which results in trying to install binaries into `/foo/c:/mingw/bin'. Perhaps you, Brian, would care to explain how that could possibly be considered to be anything *other* than broken. Then again, perhaps you wouldn't, for there is clearly no other way to describe it. > I read the same document you are viz > http://www.gnu.org/prep/standards/standards.html#Directory-Variables > which says that make install prefix=/any/other/prefix isn't allowed > to rebuild the package. > > <quote> > Running ?make install? with a different value of prefix from the one > used to build the program should not recompile the program. > </quote> And this is as it has been, for as long as I can remember; this is in section 7.2.5, accessed via the above URI, and that statement alone means that, if GCC will force a rebuild as Danny (Smith) has suggested, when using a different prefix at install time from that specified at configuration time, then GCC itself is in breach of the GNU Coding Standards :-( Furthermore... > I will have to revise my statements toward DESTDIR with the > addition of it in the standards document however packages that > rebuild by supplying a different value of prefix or any other > destination variable is, by described coding standards > definition, broken. I must respectfully disagree with this statement; in the very same section 7.2.5 of the standards, just a paragraph or two *before* the previous quote, I see: <quote> Installers are expected to override these values when calling make (e.g., make prefix=/usr install) or configure (e.g., configure --prefix=/usr). </quote> and reading that in context with the preceding quote, IMO it remains *mandatory* to support overriding prefix at install time, and this is the *only* mandatory mechanism for relocation at install time; (do note that, while to their eternal shame, the GNU Standards Committee have now, as recently as 15-Nov-2006, adopted the DESTDIR horror into the standards, supporting it remains *optional*). Thus, IMO there is no way that continuing to follow the mandatorily supported practice of overriding prefix at install time could *ever* be described as broken. For entirely practical reasons, I shall continue to employ this mechanism, and consider the use of DESTDIR to be broken. Regards, Keith. |
From: Bob R. <bob...@co...> - 2006-12-20 14:34:46
|
On Wed, Dec 20, 2006 at 02:28:04PM +0000, Keith MARSHALL wrote: > Earnie Boyd wrote, quoting Brian Dessent: > >> You say DESTDIR is broken, I say overloading "prefix" by having it > >> take on two conceptually different and unrelated values is broken. > > It has nothing whatsoever to do with *overloading*; it is *overriding*, > plain and simple. > > Ok. So, I've configured for a *native* Win32 build, with a correctly > specified `--prefix=c:/mingw'. Now you would have me relocate, after > the initial build, by saying: > > make DESTDIR=/foo/ install > > which results in trying to install binaries into `/foo/c:/mingw/bin'. > Perhaps you, Brian, would care to explain how that could possibly be > considered to be anything *other* than broken. Then again, perhaps > you wouldn't, for there is clearly no other way to describe it. Keith, do you actually do --prefix=C:/mingw, or --prefix=/mingw? Thanks, Bob Rossi |