Steve Petrie wrote:
Greetings,
I am trying to build stdcxx-4.2.1 on Windows XP (SP2), using the
MinGW(3.4.5) + MSYS(1.0.10) + (with gcc, g++, etc.) operating environment.
Running make from an MSYS console.
I have no experience with building stdcxx on MinGW and don't have
access to the environment but I believe one of our developers has
ported stdcxx there so he should be able to answer some of your
questions. Farid, do you have any insight into Steve's problems?
Btw., it might be helpful to know the build type/mode you chose
for stdcxx, or if none, to try to explicitly specify a debug one
to see what happens. For example, to build an archive library
with debugging info, define BUILDTYPE=11s (alternatively,
BUILDMODE=debug) on the command line when invoking make.
In the meantime, let me try to answer some of the questions that
I think I might be able to help with.
[...]
** GNUmakefile / MinGW+MSYS Incompatibility #3 **
[...]
I believe they fail because the directory /stdcxx-4.2.1/build/bin/ defined
by the BINDIR variable BINDIR = $(buildpath)/bin contains no file called
<exec> at the time that the ls commands execute.
This problem I just ignored for the time being, because I didn't know what
the file <exec> is supposed to contain.
Exec is a utility program that stdcxx uses to run its tests and
example programs in batch testing. It's only useful if you're
maintaining the project.
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #4 **
[...]
Lines 38..40 of file /stdcxx-4.2.1/build/include/vars.sh are:
...
BUILDTAG= ; export BUILDTAG
PLATFORM=mingw32_nt-5.1-1.0.10(0.46-3-2)-i86 ; export PLATFORM
DEFAULT_SHROBJ= ; export DEFAULT_SHROBJ
...
It appears that the make config process does not like the parentheses in the
PLATFORM variable.
Right.
PLATFORM := mingw32_nt-5.1-1.0.10(0.46-3-2)-i86
I fixed the problem by adjusting the relevant statement in the GNUmakefile
to read:
PLATFORM := mingw32_nt-5.1-1.0.10-0.46-3-2--i86
changing the "(" and ")" to "-".
The right fix is to do something similar to what we do for Cygwin.
The above syntax error problem is fixed, but what about all the "no"
messages, and the "--" message(s) I am seeing on the MSYS console? Are they
normal or do they indicate an invalid build?
The "no" messages are expected. There should be no "--" messages.
They usually indicate a configuration problem.
Could you post here the config.h and config.log files from the
$BUILDDIR/include directory?
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #5 **
[...]
The error:
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/../include/wchar.h:204:
error: previous declaration `wchar_t* wcschr(const wchar_t*, wchar_t)' here
is puzzling. Why is the stdcxx-4.2.1 build examining the MinGW
/MinGW/include/ library?
The stdcxx C++ headers "expose" symbols declared in the underlying
C library (like printf() or wcschr()). Not all the symbols defined
in the C library are always declared in the C library headers. The
stdcxx configuration machinery tries to detect this so that our
headers can declare the symbols. When the configuration tests fail
for a reason other than the one they're designed to fail for as
may be the case here (not because the symbol isn't declared but
because it's declared wrong), the library still tries to declare
the symbol the "right way" and the right declaration in stdcxx
conflicts with the wrong one. It's a limitation/bug in stdcxx.
I temporarily worked around this problem by changing line 204 of the the
MinGW wchar.h file to conform with the /stdcxx-4.2.1/include/ansi/cwchar
declaration of the C function `wchar_t* wcschr(wchar_t*, wchar_t), and this
eliminated the error message.
The error:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:725: error: expected
nested-name-specifier before "wcscspn"
seemed legitimate, as the "::" qualifier before the "wcscspn" was missing.
So I added the "::" qualifier to the line 725 in the
/stdcxx-4.2.1/include/ansi/cwchar file.
That looks like the right fix. We made the same change in 4.2.2
to resolve STDCXX-663:
https://issues.apache.org/jira/browse/STDCXX-663
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #6 **
With the above-mentioned fixes in place, the build failed further on, with a
bunch of additional errors:
[...]
There's another conflict with file wchar.h in the MinGW /MinGW/include/
library:
It seems the <wchar.h> header on MinGW is non-conforming in a way
that we're not prepared to deal with (we normally try to adjust to
these kinds of things but the machinery isn't perfect).
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/../include/wchar.h:217:
error: previous declaration `wchar_t* wcsrchr(const wchar_t*, wchar_t)' here
i:/apps/stdcxx-4.2.1/include/ansi/cwchar: In function `wchar_t*
wcsrchr(wchar_t*, wchar_t)':
Also, it looks like there's an extern "C" { missing before the declaration
of function wcsrchr on line 951 of file cwchar:
No, that function is a C++ overload of the C function. It can't
be extern "C" (C doesn't allow overloading).
inline const wchar_t* wcsrchr (const wchar_t *__s, wchar_t __c)
Finally, there are a whole bunch of macro errors, in several files like:
...
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:919:1: unterminated #else
...
i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:131:1: unterminated #else
...
i:/apps/stdcxx-4.2.1/include/rw/_traits.h:39:1: unterminated #ifndef
...
i:/apps/stdcxx-4.2.1/include/rw/_strref.h:47:1: unterminated #ifndef
...
i:/apps/stdcxx-4.2.1/include/string:30:1: unterminated #ifndef
...
i:/apps/stdcxx-4.2.1/include/bitset:30:1: unterminated #ifndef
They're probably all fallout from a single unterminated preprocessor
directive, quite possibly the first one in <cwchar>.
* * *
* * *
At this point, I decided that I must be doing something VERY WRONG in
running the build, so I backed out the changes I made to the two source
files:
/MinGW/include/wchar.h
/stdcxx-4.2.1/include/ansi/cwchar
and decided to post a message to stdcxx-user.
Any suggestions would be most welcome.
I wonder if there are other problems or if <wchar.h> is the only one.
One way to find out while you're waiting for Farid's input might be
to apply the change below to see haw much further you can get in the
build. Alternatively, try a debug build where, AFAIK, stdcxx doesn't
#include <cwchar> anywhere.
--- cwchar 2008-11-25 18:33:27.000000000 -0700
+++ cwchar.1 2008-11-25 18:33:47.000000000 -0700
@@ -29,7 +29,7 @@
#include <rw/_defs.h>
-#ifndef _RWSTD_NO_PURE_C_HEADERS
+#if 1 // ndef _RWSTD_NO_PURE_C_HEADERS
# include <ansi/_cwchar.h>
#else
Martin
