You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@stdcxx.apache.org by Steve Petrie <ap...@attglobal.net> on 2008/11/25 01:09:11 UTC
Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
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.
The MinGW + MSYS, etc. seems to be working OK, when used by the NetBeans 6.5
IDE C/C++ plugin. Using NetBeans 6.5 I have successfully compiled, linked
and tested a couple of simple programs, that use cin and cout from the
standard library shipped with the g++ that comes with MinGW.
I have never tried to build anything directly with make before, let alone
anything as complicated as the Apache C++ Standard Library. I've always used
make through the intermediation of an IDE:
Metrowerks CodeWarrior
Microsoft VC++ 2005 Express
NetBeans 6.5 C/C++
* * *
* * *
(
I have searched the Apache archive without success, for tips on building
stdcxx-4.2.1 Using MinGW+MSYS, so I'm posting here.
There was one page I found:
http://mail-archives.apache.org/mod_mbox/xerces-c-dev/200708.mbox/%3C46CC9F94.60603@perforce.com%3E
...
> Hi Charles,
>
> Charles McLouth <cm...@perforce.com> writes:
>
>> As an FYI I tested the zip file with mingw-msys on windows and all
built
>> correctly and linked with the samples. Below is the specific
configure
>> options I used (even testing the new static option):
>> runConfigure -p mingw-msys -c gcc -x g++ -m inmem -n winsock -t Win32
>> runConfigure -p mingw-msys -d -c gcc -x g++ -m inmem -n winsock -t
Win32
>> runConfigure -p mingw-msys -s -c gcc -x g++ -m inmem -n winsock -t
Win32
>> runConfigure -p mingw-msys -d -s -c gcc -x g++ -m inmem -n winsock -t
Win32
>
...
But so far as I can tell, this is referring to the ability of the Cygwin
tools to generate mingw-msys compatible libraries, and not what I'm trying
to do, which is to build stdcxx-4.2.1 using MinGW+MSYS On Windows XP.
)
* * *
* * *
I'm running just plain make (with no command line parameters) at the MSYS
console prompt, in $TOPDIR, which is /i/apps/stdcxx-4.2.1/ in MSYS (mapped
from I:\APPS\stdcxx-4.2.1\ in Windows).
So far I have found and worked around some incompatibilities between: (A)
the GNUmakefile (616588 2008-01-30 02:10:55Z) shipped in stdcxx-4.2.1.tar.gz
and (B) the "POSIX" environment emulated by MinGW+MSYS. Please see the
sections below:
** GNUmakefile / MinGW+MSYS Incompatibility #1 **
thru
** GNUmakefile / MinGW+MSYS Incompatibility #5 **
for the fixes I have tried.
At section:
** GNUmakefile / MinGW+MSYS Incompatibility #6 **
below, I decided that, given my inexperience with the exciting world of make
and Standard Library building, I'd better get in touch with the experts who
programmed the Apache C++ Standard Library library, and who have already
successfully built it a few thoussand times.
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #1 **
The last line of the following code snippet from GNUmakefile (lines
542..546) fails:
# harmonize all the different Intel IA32 chips
PLATFORM := $(subst i486,i86,$(PLATFORM))
PLATFORM := $(subst i586,i86,$(PLATFORM))
PLATFORM := $(subst i686,i86,$(PLATFORM))
PLATFORM := $(shell echo $(PLATFORM) | tr "[:upper:]" "[:lower:]")
so I commented the lines out and forced:
PLATFORM := mingw32_nt-5.1-1.0.10(0.46-3-2)-i86
(On my MSYS, the uname command prints: MINGW32_NT-5.1).
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #2 **
In the make-builddir function (lines 574..599) from GNUmakefile, the
following snippet:
ln -sf $(TOPDIR)/GNUmakefile $(buildpath);
\ **
ln -sf $(ETCDIR)/GNUmakefile.cfg $(buildpath)/include/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.lib $(LIBDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.rwt $(buildpath)/rwtest/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.exm $(EXMDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.tst $(TSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.ph $(PHTSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.bin $(BINDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/makefile.common $(buildpath);
\ **
ln -sf $(ETCDIR)/makefile.rules $(buildpath);
\ **
ln -sf $(ETCDIR)/configure.sh $(buildpath)/include/configure;
\
ln -sf $(BINDIR)/exec $(buildpath)/run;
\
ln -sf $(BINDIR)/exec $(BINDIR)/run;
\
ln -sf $(ETCDIR)/run_locale_utils.sh $(BINDIR)/run_utils;
\
ln -sf $(BINDIR)/exec $(TSTDIR)/run;
\
ln -sf $(BINDIR)/exec $(PHTSTDIR)/run;
\
ln -sf $(BINDIR)/exec $(EXMDIR)/run
has 3 ls commands (marked ** above) that specify a directory (i.e. that do
not specify a file). These commands are of the form:
ls -sf file dir
and according to my UNIX book, for this form of the ls command: "ls creates
a link in <dir> to <file>. However, MSYS does NOT create a link IN <dir> but
REPLACES <dir> with a link to <file>, naming the link the same as <dir>.
So when the above snippet in function make-builddir has finished executing,
DIRECTORY /stdcxx-4.2.1/build/ has been replaced by a FILE
/stdcxx-4.2.1/build linked to file /stdcxx-4.2.1/etc/config/makefile.rules
I worked around this problem, by changing the 3 ls commands (marked **
above) so that they are of the form:
ln -sf $(TOPDIR)/GNUmakefile $(buildpath)/GNUmakefile;
\
...
ln -sf $(ETCDIR)/makefile.common $(buildpath)/makefile.common;
\
ln -sf $(ETCDIR)/makefile.rules $(buildpath)/makefile.rules;
\
...
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #3 **
In the same make-builddir function (lines 574..599) as above, in the same
snippet:
ln -sf $(TOPDIR)/GNUmakefile $(buildpath);
\
ln -sf $(ETCDIR)/GNUmakefile.cfg $(buildpath)/include/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.lib $(LIBDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.rwt $(buildpath)/rwtest/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.exm $(EXMDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.tst $(TSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.ph $(PHTSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.bin $(BINDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/makefile.common $(buildpath);
\
ln -sf $(ETCDIR)/makefile.rules $(buildpath);
\
ln -sf $(ETCDIR)/configure.sh $(buildpath)/include/configure;
\
ln -sf $(BINDIR)/exec $(buildpath)/run;
\ **
ln -sf $(BINDIR)/exec $(BINDIR)/run;
\ **
ln -sf $(ETCDIR)/run_locale_utils.sh $(BINDIR)/run_utils;
\
ln -sf $(BINDIR)/exec $(TSTDIR)/run;
\ **
ln -sf $(BINDIR)/exec $(PHTSTDIR)/run;
\ **
ln -sf $(BINDIR)/exec $(EXMDIR)/run
**
when the make-builddir function executes, the 5 ls commands (marked **
above) fail and display the following on the MSYS console:
creating BUILDDIR=/stdcxx-4.2.1/build
ln: creating symbolic link `/stdcxx-4.2.1/build/run' to
`/stdcxx-4.2.1/build/bin/exec': No such file or directory
ln: creating symbolic link `/stdcxx-4.2.1/build/bin/run' to
`/stdcxx-4.2.1/build/bin/exec': No such file or directory
ln: creating symbolic link `/stdcxx-4.2.1/build/tests/run' to
`/stdcxx-4.2.1/build/bin/exec': No such file or directory
ln: creating symbolic link `/stdcxx-4.2.1/build/plumhall/run' to
`/stdcxx-4.2.1/build/bin/exec': No such file or directory
ln: creating symbolic link `/stdcxx-4.2.1/build/examples/run' to
`/stdcxx-4.2.1/build/bin/exec': No such file or directory
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.
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #4 **
In what appears to me to be another iteration of the GNUmakefile during its
ececution, the following is displayed on the MSYS console:
...
make[2]: Entering directory `/stdcxx-4.2.1/build/include'
make config
make[3]: Entering directory `/stdcxx-4.2.1/build/include'
configuring stdcxx 4.2.1 for gcc-3.4.5 on
mingw32_nt-5.1-1.0.10(0.46-3-2)-i86
checking if the compiler is sane ok (invoked with gcc)
checking if the linker is sane ok (invoked with gcc)
checking system architecture ILP32 little endian
/stdcxx-4.2.1/etc/config/src/libc_decl.sh: ./vars.sh: line 39: syntax
error near unexpected token `PLATFORM=mingw32_nt-5.1-1.0.10(0'
/stdcxx-4.2.1/etc/config/src/libc_decl.sh: ./vars.sh: line 39:
`PLATFORM=mingw32_nt-5.1-1.0.10(0.46-3-2)-i86 ; export PLATFORM'
checking for <cassert> no (_RWSTD_NO_CASSERT)
checking for <assert.h> ok
("i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/assert.h")
checking for <cctype> no (_RWSTD_NO_CCTYPE)
checking for <ctype.h> ok
("i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ctype.h")
checking for <cerrno> no (_RWSTD_NO_CERRNO)
checking for <errno.h> ok
("i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/errno.h")
...
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.
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 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?
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #5 **
Further along in the build proces, with all the above-mentioned fixes in
place, the build terminated with the following displayed on the MSYS
console:
generating dependencies for $(TOPDIR)/src/assert.cpp
gcc -M -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/assert.cpp
make[2]: Leaving directory `/stdcxx-4.2.1/build/lib'
make[2]: Entering directory `/stdcxx-4.2.1/build/lib'
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/assert.cpp
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/atomic-cxx.S
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/bitset.cpp
In file included from i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:195,
from i:/apps/stdcxx-4.2.1/include/rw/_traits.h:40,
from i:/apps/stdcxx-4.2.1/include/rw/_strref.h:48,
from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar: In function `wchar_t*
wcschr(wchar_t*, wchar_t)':
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:613: error: declaration of C
function `wchar_t* wcschr(wchar_t*, wchar_t)' conflicts with
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
i:/apps/stdcxx-4.2.1/include/ansi/cwchar: At global scope:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:725: error: expected
nested-name-specifier before "wcscspn"
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:725: confused by earlier errors,
bailing out
make[2]: *** [bitset.o] Error 1
make[2]: Leaving directory `/stdcxx-4.2.1/build/lib'
make[1]: *** [lib] Error 2
make[1]: Leaving directory `/stdcxx-4.2.1/build'
make: *** [libstd] Error 2
SteveP@DELL /stdcxx-4.2.1
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?
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.
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #6 **
With the above-mentioned fixes in place, the build failed further on, with a
bunch of additional errors:
generating dependencies for $(TOPDIR)/src/assert.cpp
gcc -M -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/assert.cpp
make[2]: Leaving directory `/stdcxx-4.2.1/build/lib'
make[2]: Entering directory `/stdcxx-4.2.1/build/lib'
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/assert.cpp
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/atomic-cxx.S
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/bitset.cpp
In file included from i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:195,
from i:/apps/stdcxx-4.2.1/include/rw/_traits.h:40,
from i:/apps/stdcxx-4.2.1/include/rw/_strref.h:48,
from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar: In function `wchar_t*
wcsrchr(wchar_t*, wchar_t)':
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:944: error: declaration of C
function `wchar_t* wcsrchr(wchar_t*, wchar_t)' conflicts with
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)':
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:948: error: invalid conversion
from `const wchar_t*' to `wchar_t*'
i:/apps/stdcxx-4.2.1/include/ansi/cwchar: At global scope:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:958: error: expected declaration
before '}' token
In file included from i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:195,
from i:/apps/stdcxx-4.2.1/include/rw/_traits.h:40,
from i:/apps/stdcxx-4.2.1/include/rw/_strref.h:48,
from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:919:1: unterminated #else
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:99:1: unterminated #if
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:87:1: unterminated #if
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:65:1: unterminated #ifndef
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:36:1: unterminated #else
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:32:1: unterminated #else
In file included from i:/apps/stdcxx-4.2.1/include/rw/_traits.h:40,
from i:/apps/stdcxx-4.2.1/include/rw/_strref.h:48,
from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:131:1: unterminated #else
i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:40:1: unterminated #elif
i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:32:1: unterminated #ifndef
In file included from i:/apps/stdcxx-4.2.1/include/rw/_strref.h:48,
from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/rw/_traits.h:39:1: unterminated #ifndef
i:/apps/stdcxx-4.2.1/include/rw/_traits.h:32:1: unterminated #ifndef
In file included from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/rw/_strref.h:47:1: unterminated #ifndef
i:/apps/stdcxx-4.2.1/include/rw/_strref.h:32:1: unterminated #ifndef
In file included from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/string:30:1: unterminated #ifndef
In file included from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/bitset:30:1: unterminated #ifndef
make[2]: *** [bitset.o] Error 1
make[2]: Leaving directory `/stdcxx-4.2.1/build/lib'
make[1]: *** [lib] Error 2
make[1]: Leaving directory `/stdcxx-4.2.1/build'
make: *** [libstd] Error 2
SteveP@DELL /stdcxx-4.2.1
There's another conflict with file wchar.h in the MinGW /MinGW/include/
library:
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:
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
* * *
* * *
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.
--
View this message in context: http://www.nabble.com/Building-stdcxx-4.2.1-Using-MinGW%2BMSYS-On-Windows-XP-%28SP2%29-tp20672758p20672758.html
Sent from the stdcxx-user mailing list archive at Nabble.com.
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by "Steve Petrie, P.Eng." <ap...@attglobal.net>.
Hi Farid,
Thanks for your response -- excellent news!
Please feel free to delete, from the stdcxx-user Nabble forum, my two latest
postings:
Steve Petrie Nov 26, 2008; 01:11am
Steve Petrie Nov 26, 2008; 12:27am
As they relate to further work I did on stdcxx-4.2.1, following up on
Martin's suggestions, before I received your email.
* * *
* * *
I will proceed to get stdcxx-4.2.2, apply the MinGW patch, and post the
results I get from a build, on the stdcxx-user Nabble forum.
Steve
----- Original Message -----
From: "Farid Zaripov" <Fa...@epam.com>
To: <us...@stdcxx.apache.org>
Sent: Wednesday, November 26, 2008 7:18 AM
Subject: RE: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Hi Steve.
> 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.
The 4.2.1 version of the stdcxx isn't ported to MinGW.
You need to get (yet unreleased) 4.2.2 version from svn, i.e.:
svn co http://svn.apache.org/repos/asf/stdcxx/branches/4.2.x stdcxx-4.2.2
Then apply this patch: http://people.apache.org/~faridz/mingw.patch
Farid.
RE: Building stdcxx-4.2.2 Using MinGW+MSYS On Windows XP (SP2)
Posted by Steve Petrie <ap...@attglobal.net>.
Hi Farid,
I got stdcxx-4.2.2 from svn and applied the mingw.patch you provided.
I assume that you are building stdcxx-4.2.2 using Cygwin, and targeting
MinGW. My objective is to build stdcxx-4.2.2 using MinGW. I don't use Cygwin
and I don't plan to use it.
There were two fixes I had to make, to get the build of the patched
stdcxx-4.2.2 to run:
Fix #1 -- /stdcxx-4.2.2/CNUmakefile:
On lines 583, 591 and 592 of /stdcxx-4.2.2/GNUmakefile:
ln -sf $(TOPDIR)/GNUmakefile $(buildpath)/GNUmakefile;
\ **
ln -sf $(ETCDIR)/GNUmakefile.cfg $(buildpath)/include/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.lib $(LIBDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.rwt $(buildpath)/rwtest/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.exm $(EXMDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.tst $(TSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.ph $(PHTSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.bin $(BINDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/makefile.common $(buildpath)/makefile.common;
\ **
ln -sf $(ETCDIR)/makefile.rules $(buildpath)/makefile.rules;
\ **
ln -sf $(ETCDIR)/configure.sh $(buildpath)/include/configure;
\
ln -sf $(BINDIR)/exec $(buildpath)/run;
\
ln -sf $(BINDIR)/exec $(BINDIR)/run;
\
ln -sf $(ETCDIR)/run_locale_utils.sh $(BINDIR)/run_utils;
\
ln -sf $(BINDIR)/exec $(TSTDIR)/run;
\
ln -sf $(BINDIR)/exec $(PHTSTDIR)/run;
\
ln -sf $(BINDIR)/exec $(EXMDIR)/run
On the three lines marked ** above, I added an explicit file name after the
$(buildpath) because the MinGW <ls> command, was REPLACING the
/stdcxx-4.2.1/build/ directory name, with a link (named /stdcxx-4.2.1/build)
to the file, instead of creating a link to the file (with the name of the
file), IN the /stdcxx-4.2.1/build/ directory.
Fix #2 -- Your /stdcxx-4.2.2/build file:
I renamed the /stdcxx-4.2.2/build file that came with the svn download, to
/stdcxx-4.2.1/build_faridz, because the presence of the build FILE was
preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/ DIRECTORY.
* * *
* * *
The build go a LOT further with the patched stdcxx-4.2.2 than it did with
the stdcxx-4.2.1.
According to Windows XP, the final size of the /stdcxx-4.2.1/build/
directory (including sub-directories) is 126 MB.
There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB.
HOWEVER, the build ended with the following displayed on the MSYS console:
<MSYS:>
[...]
generating dependencies for $(TOPDIR)/tests/self/0.alloc.cpp
gcc -M -I/stdcxx-4.2.2/include/ansi -I/stdcxx-4.2.2/include
-I/stdcxx-4.2.2/build/include -I/stdcxx-4.2.2/tests/include -pedantic
-nostdinc++ -mno-cygwin -W -Wall -Wcast-qual -Winline -Wshadow
-Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.2/tests/self/0.alloc.cpp
make[2]: Leaving directory `/stdcxx-4.2.2/build/tests'
make[2]: Entering directory `/stdcxx-4.2.2/build/tests'
[...]
gcc -c -I/stdcxx-4.2.2/include/ansi -I/stdcxx-4.2.2/include
-I/stdcxx-4.2.2/build/include -I/stdcxx-4.2.2/tests/include -pedantic
-nostdinc++ -mno-cygwin -W -Wall -Wcast-qual -Winline -Wshadow
-Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp: In function
`int main()':
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:144: error:
`LONG_BIT' was not declared in this scope
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:145: error:
`_POSIX_SSIZE_MAX' was not declared in this scope
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:146: error:
`WORD_BIT' was not declared in this scope
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:151: warning:
this decimal constant is unsigned only in ISO C90
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:152: warning:
this decimal constant is unsigned only in ISO C90
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:144: warning:
unused variable 'LONG_BIT'
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:145: warning:
unused variable '_POSIX_SSIZE_MAX'
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:146: warning:
unused variable 'WORD_BIT'
make[2]: *** [18.c.limits.stdcxx-988.o] Error 1
make[2]: Leaving directory `/stdcxx-4.2.2/build/tests'
make[1]: [tests] Error 2 (ignored)
make[1]: Leaving directory `/stdcxx-4.2.2/build'
SteveP@DELL /stdcxx-4.2.2
$
</MSYS:>
In the line "make[1]: [tests] Error 2 (ignored)", does the "(ignored)" mean
that <make> did not terminate prematurely, and that file:
/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp
is the last test source file to be compiled?
According to the /stdcxx-4.2.2/README file, the last build step is the
locale databases. The build I ran left the /stdcxx-4.2.2/nls/ directory
completely EMPTY.
* * *
* * *
Please let me know -- did the build complete successfully? If not, and I
need to fix the 18.c.limits.stdcxx-988.cpp compile error, what changes to I
need to make to fix the compile error?
Thanks,
Steve
Farid Zaripov-2 wrote:
>
> Hi Steve.
>
>> 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.
>
> The 4.2.1 version of the stdcxx isn't ported to MinGW.
>
> You need to get (yet unreleased) 4.2.2 version from svn, i.e.:
>
> svn co http://svn.apache.org/repos/asf/stdcxx/branches/4.2.x
> stdcxx-4.2.2
>
> Then apply this patch: http://people.apache.org/~faridz/mingw.patch
>
> Farid.
>
>
--
View this message in context: http://www.nabble.com/Building-stdcxx-4.2.1-Using-MinGW%2BMSYS-On-Windows-XP-%28SP2%29-tp20672758p20712556.html
Sent from the stdcxx-user mailing list archive at Nabble.com.
RE: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by Farid Zaripov <Fa...@epam.com>.
Hi Steve.
> 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.
The 4.2.1 version of the stdcxx isn't ported to MinGW.
You need to get (yet unreleased) 4.2.2 version from svn, i.e.:
svn co http://svn.apache.org/repos/asf/stdcxx/branches/4.2.x stdcxx-4.2.2
Then apply this patch: http://people.apache.org/~faridz/mingw.patch
Farid.
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by "Steve Petrie, P.Eng." <ap...@attglobal.net>.
Hi Martin,
Thanks for your post.
I'll keep your Jira tip in mind, for the future.
* * *
* * *
I'm no longer working with stdcxx-4.2.1.
Farid has notified me that stdcxx-4.2.2 is ported to MinGW, and he has
provided a patch to apply the MinGW updates to stdcxx-4.2.2.
The work I did on building stdcxx-4.2.1 using MinGW+MSYS wasn't wasted
however, because one of the fixes I discovered (to GNUmakefile), is needed
for using MinGW+MSYS to build stdcxx-4.2.2.
Please see http://www.nabble.com/forum/ViewPost.jtp?post=20712556&framed=y
for the results of my first build of stdcxx-4.2.2 using MinGW+MSYS.
Steve
----- Original Message -----
From: "Martin Sebor" <ms...@gmail.com>
To: <us...@stdcxx.apache.org>
Sent: Wednesday, November 26, 2008 6:32 PM
Subject: Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
> Steve Petrie wrote:
>> Posting the files in the Nabble Message box hangs my Firefox (the file
>> are
>> quite big) so I'm trying the "Upload File..." button above the Nabble
>> Message box...
>
> FYI: You can also open a Jira issue for the problems you're having
> and attach the files to it. That might actually be even preferable.
>
> Martin
>
>>
>> http://www.nabble.com/file/p20695038/config.h config.h
>> http://www.nabble.com/file/p20695038/config.log config.log Martin Sebor-2
>> wrote:
>>>
>>> Could you post here the config.h and config.log files from the
>>> $BUILDDIR/include directory?
>>>
>>> Martin
>>>
>>>
>>
>
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by Martin Sebor <ms...@gmail.com>.
Steve Petrie wrote:
> Posting the files in the Nabble Message box hangs my Firefox (the file are
> quite big) so I'm trying the "Upload File..." button above the Nabble
> Message box...
FYI: You can also open a Jira issue for the problems you're having
and attach the files to it. That might actually be even preferable.
Martin
>
> http://www.nabble.com/file/p20695038/config.h config.h
>
> http://www.nabble.com/file/p20695038/config.log config.log
>
>
> Martin Sebor-2 wrote:
>>
>> Could you post here the config.h and config.log files from the
>> $BUILDDIR/include directory?
>>
>> Martin
>>
>>
>
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by Steve Petrie <ap...@attglobal.net>.
Posting the files in the Nabble Message box hangs my Firefox (the file are
quite big) so I'm trying the "Upload File..." button above the Nabble
Message box...
http://www.nabble.com/file/p20695038/config.h config.h
http://www.nabble.com/file/p20695038/config.log config.log
Martin Sebor-2 wrote:
>
>
> Could you post here the config.h and config.log files from the
> $BUILDDIR/include directory?
>
> Martin
>
>
--
View this message in context: http://www.nabble.com/Building-stdcxx-4.2.1-Using-MinGW%2BMSYS-On-Windows-XP-%28SP2%29-tp20672758p20695038.html
Sent from the stdcxx-user mailing list archive at Nabble.com.
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by Steve Petrie <ap...@attglobal.net>.
Here's a paste of lines 939..956 from file /stdcxx-4.2.1/include/ansi/cwchar:
extern "C" {
inline wchar_t* wcsrchr (wchar_t *__s, wchar_t __c)
{
const wchar_t *__ss = __s;
while (*__ss++);
while (--__ss != __s && *__ss != __c);
return *__ss == __c ? __ss : 0;
}
} // extern "C"
inline const wchar_t* wcsrchr (const wchar_t *__s, wchar_t __c)
{
return wcsrchr (_RWSTD_CONST_CAST (wchar_t*, __s), __c);
}
} // extern "C"
If function wcsrchr on line 951 of file cwchar can't be extern "C", then
there appears to be an extraneous:
} // extern "C"
on line 956.
Martin Sebor-2 wrote:
>
>
>>
>>
>> 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).
>
> Martin
>
>
--
View this message in context: http://www.nabble.com/Building-stdcxx-4.2.1-Using-MinGW%2BMSYS-On-Windows-XP-%28SP2%29-tp20672758p20695299.html
Sent from the stdcxx-user mailing list archive at Nabble.com.
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by "Steve Petrie, P.Eng." <ap...@attglobal.net>.
[MS]
> Right. I think a "build" directory gets created automatically
> when one isn't specified on the command line (via BUILDDIR).
> Something weird seems to be going on in Steve's environment
> (the behavior of ln -s is definitely bizarre)...
>
[SP]
Yes there is something wierd. Please see my response to Farid's message,
regarding a test shell script I created, to replicate the MinGW+MSYS ln
problem.
But I've got a workaround for the problem. And Farid says my stdcxx build is
now working. So no big deal.
I'm "only" using MinGW+MSYS for compiling and building C++ programs through
the NetBeans IDE (with C++ plugin). That all seems to work fine. It's the
comparably far more complex process of building the stdcxx library, that is
stressing my MinGW+MSYS. But I want to use stdcxx because it seems to me
likely to be superior to the standard library shipped with g++, so I don't
mind at all working through the glitches to get stdcxx built and working.
* * *
* * *
[MS]>>> There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB.
>>
>> My congratulations, you have just build the stdcxx library :)
>
> Although it probably shouldn't be called liblibstd, should it?
> What's with the duplicate "lib" part?
>
[SP]
It's lack of sleep -- the correct pathname is
/stdcxx-4.2.2/build/lib/libstd.a
Steve
----- Original Message -----
From: "Martin Sebor" <ms...@gmail.com>
To: <us...@stdcxx.apache.org>
Sent: Thursday, November 27, 2008 3:05 PM
Subject: Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
> Farid Zaripov wrote:
> [...]
>>> Fix #2 -- Your /stdcxx-4.2.2/build file:
>>>
>>> I renamed the /stdcxx-4.2.2/build file that came with the svn download,
>>> to
>>> /stdcxx-4.2.1/build_faridz, because the presence of the build FILE was
>>> preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/
>>> DIRECTORY.
>>
>> Hmm, you must be wrong, we don't have any file with the name "build" in
>> svn.
>
> Right. I think a "build" directory gets created automatically
> when one isn't specified on the command line (via BUILDDIR).
> Something weird seems to be going on in Steve's environment
> (the behavior of ln -s is definitely bizarre)...
>
>>
>> [...]
>>
>>> There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB.
>>
>> My congratulations, you have just build the stdcxx library :)
>
> Although it probably shouldn't be called liblibstd, should it?
> What's with the duplicate "lib" part?
>
> Martin
>
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by Martin Sebor <ms...@gmail.com>.
Farid Zaripov wrote:
[...]
>> Fix #2 -- Your /stdcxx-4.2.2/build file:
>>
>> I renamed the /stdcxx-4.2.2/build file that came with the svn download, to
>> /stdcxx-4.2.1/build_faridz, because the presence of the build FILE was
>> preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/ DIRECTORY.
>
> Hmm, you must be wrong, we don't have any file with the name "build" in svn.
Right. I think a "build" directory gets created automatically
when one isn't specified on the command line (via BUILDDIR).
Something weird seems to be going on in Steve's environment
(the behavior of ln -s is definitely bizarre)...
>
> [...]
>
>> There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB.
>
> My congratulations, you have just build the stdcxx library :)
Although it probably shouldn't be called liblibstd, should it?
What's with the duplicate "lib" part?
Martin
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by "Steve Petrie, P.Eng." <ap...@attglobal.net>.
[SP]
>
> Then I created a documented test case shell script "test.mingw.ln"
> (attached), that replicates the problem on my MinGW+MSYS system.
> Would you like to run the script in an MSYS console on your system, and
> let
> me know the result?
>
[SP]
I notice that user@stdcxx.apache.org has stripped the file attachment
"test.mingw.ln" from my email, before sending my email to mailing list
subscribers.
I will be away from my computer for a couple of days.
When I return, I'll provide the "test.mingw.ln" file to you.
Steve
----- Original Message -----
From: "Steve Petrie, P.Eng." <ap...@attglobal.net>
To: <us...@stdcxx.apache.org>
Sent: Friday, November 28, 2008 12:05 AM
Subject: Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
> [FZ]
> Actually my goal is make it possible to build stdcxx/MinGW and
> stdcxx/Cygwin using Cygwin environment as well as stdcxx/MinGW using MSYS
> environment.
>
> [SP]
> Good -- so we share the same goal of making it possible to build
> stdcxx/MinGW using the MSYS
> environment.
>
> * * *
> * * *
>
> [FZ]
>> On the three lines marked ** above, I added an explicit file name after
>> the
>> $(buildpath) because the MinGW <ls> command, was REPLACING the
>> /stdcxx-4.2.1/build/ directory name, with a link (named
>> /stdcxx-4.2.1/build)
>> to the file, instead of creating a link to the file (with the name of the
>> file), IN the /stdcxx-4.2.1/build/ directory.
>
> I have no such problems when running make on MSYS.
>
> [SP]
> Lucky you :)
>
> But I definitely DO have the problem with "ln" on my MSYS :(
>
> ( It's actually the "ln" command, not "ls" that has the bug. Due to lack
> of
> sleep. I mis-named the "ln" command "ls" in my description. But the
> example
> code above the description, showed "ln".)
>
> I'm using Windows XP (SP2) and MinGW (5.1.4) and MSYS (1.0.10). Perhaps we
> have a difference in our operating environments?
>
> I have replicated the problem outside the stdcxx-4.2.2 make, by manually
> entering the ln commands at an MSYS console.
>
> Then I created a documented test case shell script "test.mingw.ln"
> (attached), that replicates the problem on my MinGW+MSYS system.
> Would you like to run the script in an MSYS console on your system, and
> let
> me know the result?
>
> I plan to report this problem (and provide the test script) to
> www.mingw.org
> and it would be helpful to know for sure that it's something peculiar to
> my
> environment.
>
> Here are a couple of interesting quotes related to MinGW+MSYS and ln, that
> I
> found through a Google search:
>
> <quote 1>
>
> There is no way to create a "file symlink" in MSYS in a way similar to a
> "directory symlink" (that is, a mount point).
> The command ln for creating links works, but it actually makes a copy of
> the
> original file, not a symlink to it.
>
> </quote 1>
>
>
> <quote 2>
> It is possible to build under MinGW, however the release packages are
> build under cygwin and I am trying to duplicate the setup used.
> [...]
> Cygwin softlinks are unusable under native windows, so we need to
> disableCygwin's "ln" command and let gcc's build scripts use "cp"
> instead.</quote 2>
>
> quote 2 above, is from web page
> http://article.gmane.org/gmane.comp.gnu.mingw.user/25585
>
> * * *
> * * *
>
> [FZ]
> My congratulations, you have just build the stdcxx library :)
>
> [SP]
> Great!
>
> Now I'll install the stdcxx library, for use with my NetBeans 6.5 IDE
> (With
> C++ plugin.)
>
> Is there a simple test I can use, a simple C++ program, that e.g. obtains
> the
> ID and version of the stdcxx library?
>
> After I install the stdcxx library, I would like to conclusively PROVE to
> myself,
> that I'm actually hooking into the stdcxx library, and not the standard
> library shipped with MinGW.
>
> * * *
> * * *
>
> [FZ]
> Hmm, you must be wrong, we don't have any file with the name "build" in
> svn.
>
> [SP}
> You are correct -- my apologies.
>
> The /stdcxx-4.2.2/build file, that I mistakenly thought came with the svn,
> was a file link named "build", linked to
> /stdcxx-4.2.2/etc/config/makefile.rules.
>
> This link was created by the buggy MinGW <ln> command that I described in
> my
> "Fix #1 -- /stdcxx-4.2.2/CNUmakefile".
>
> I must have run the make first once, and forgot about the buggy MinGW <ln>
> that created the /stdcxx-4.2.2/build file link. So I assumed that the
> /stdcxx-4.2.2/build file came with the svn.
>
> * * *
> * * *
>
> [FZ]
> It depends on what you want :) You have build the stdcxx library
> successfully, so now you can compile
> your programs with stdcxx.
> [...]
> 18.c.limits.stdcxx-988.cpp is just one of the regression tests. It was
> not
> verified on gcc/MinGW so
> it fails to compile. But this failure doesn't means that there is some
> problem or bug in stdcxx library.
>
> [SP]
> I don't entirely follow your thinking.
>
> I'm glad to know that I've successfully built the stdcxx library -- that's
> a
> HUGE step in the right direction. And certainly I'm going to start using
> stdcxx in my C++ programming work.
>
> HOWEVER, until ALL the stdcxx tests are verified as ok on gcc/MinGW, this
> means
> that there IS/ARE some problem(s) with stdcxx in MinGW, does it not? After
> all, isn't
> the purpose of the tests to prove that the stdcxx libary on the target
> system is working correctly?
>
> Steve
>
> ----- Original Message -----
> From: "Farid Zaripov" <Fa...@epam.com>
> To: <us...@stdcxx.apache.org>
> Sent: Thursday, November 27, 2008 2:24 PM
> Subject: RE: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
>
>
>> I assume that you are building stdcxx-4.2.2 using Cygwin, and targeting
>> MinGW. My objective is to build stdcxx-4.2.2 using MinGW. I don't use
>> Cygwin
>> and I don't plan to use it.
>
> Actually my goal is make it possible to build stdcxx/MinGW and
> stdcxx/Cygwin
> using Cygwin environment as well as stdcxx/MinGW using MSYS environment.
>
>> There were two fixes I had to make, to get the build of the patched
>> stdcxx-4.2.2 to run:
>
> [...]
>
>> On the three lines marked ** above, I added an explicit file name after
>> the
>> $(buildpath) because the MinGW <ls> command, was REPLACING the
>> /stdcxx-4.2.1/build/ directory name, with a link (named
>> /stdcxx-4.2.1/build)
>> to the file, instead of creating a link to the file (with the name of the
>> file), IN the /stdcxx-4.2.1/build/ directory.
>
> I have no such problems when running make on MSYS.
>
>> Fix #2 -- Your /stdcxx-4.2.2/build file:
>>
>> I renamed the /stdcxx-4.2.2/build file that came with the svn download,
>> to
>> /stdcxx-4.2.1/build_faridz, because the presence of the build FILE was
>> preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/
>> DIRECTORY.
>
> Hmm, you must be wrong, we don't have any file with the name "build" in
> svn.
>
> [...]
>
>> There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB.
>
> My congratulations, you have just build the stdcxx library :)
>
>> HOWEVER, the build ended with the following displayed on the MSYS
>> console:
>
> When you run make without targets specified, the examples, tests, locales
> will be build.
> Not all tests are compiling without errors on gcc/MinGW at the moment. It
> is
> ok.
>
> You can build the library only (without examples, tests and so on) using
> this command: "make config lib"
> Also I suggest to explicitly specify the build type. I.e.:
>
> make BUILDDIR=/var/tmp/stdcxx-4.2.2/gcc/15d BUILDTYPE=15d config lib
>
>> In the line "make[1]: [tests] Error 2 (ignored)", does the "(ignored)"
>> mean
>> that <make> did not terminate prematurely, and that file:
>>
>> /stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp
>>
>> is the last test source file to be compiled?
>
> I don't think so. The make should stop on the first error encountered
> unless make was executed with "-k" option specified.
>
>> According to the /stdcxx-4.2.2/README file, the last build step is the
>> locale databases. The build I ran left the /stdcxx-4.2.2/nls/ directory
>> completely EMPTY.
>
> Right, that because of make stopped on the compile error you mentioned
> above.
>
>> Please let me know -- did the build complete successfully?
>
> It depends on what you want :) You have build the stdcxx library
> successfully, so now you can compile
> your programs with stdcxx.
>
>> If not, and I
>> need to fix the 18.c.limits.stdcxx-988.cpp compile error, what changes to
>> I
>> need to make to fix the compile error?
>
> 18.c.limits.stdcxx-988.cpp is just one of the regression tests. It was
> not
> verified on gcc/MinGW so
> it fails to compile. But this failure doesn't means that there is some
> problem or bug in stdcxx library.
>
> Farid.
>
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by "Steve Petrie, P.Eng." <ap...@attglobal.net>.
[FZ]
Actually my goal is make it possible to build stdcxx/MinGW and
stdcxx/Cygwin using Cygwin environment as well as stdcxx/MinGW using MSYS
environment.
[SP]
Good -- so we share the same goal of making it possible to build
stdcxx/MinGW using the MSYS
environment.
* * *
* * *
[FZ]
> On the three lines marked ** above, I added an explicit file name after
> the
> $(buildpath) because the MinGW <ls> command, was REPLACING the
> /stdcxx-4.2.1/build/ directory name, with a link (named
> /stdcxx-4.2.1/build)
> to the file, instead of creating a link to the file (with the name of the
> file), IN the /stdcxx-4.2.1/build/ directory.
I have no such problems when running make on MSYS.
[SP]
Lucky you :)
But I definitely DO have the problem with "ln" on my MSYS :(
( It's actually the "ln" command, not "ls" that has the bug. Due to lack of
sleep. I mis-named the "ln" command "ls" in my description. But the example
code above the description, showed "ln".)
I'm using Windows XP (SP2) and MinGW (5.1.4) and MSYS (1.0.10). Perhaps we
have a difference in our operating environments?
I have replicated the problem outside the stdcxx-4.2.2 make, by manually
entering the ln commands at an MSYS console.
Then I created a documented test case shell script "test.mingw.ln"
(attached), that replicates the problem on my MinGW+MSYS system.
Would you like to run the script in an MSYS console on your system, and let
me know the result?
I plan to report this problem (and provide the test script) to www.mingw.org
and it would be helpful to know for sure that it's something peculiar to my
environment.
Here are a couple of interesting quotes related to MinGW+MSYS and ln, that I
found through a Google search:
<quote 1>
There is no way to create a "file symlink" in MSYS in a way similar to a
"directory symlink" (that is, a mount point).
The command ln for creating links works, but it actually makes a copy of the
original file, not a symlink to it.
</quote 1>
<quote 2>
It is possible to build under MinGW, however the release packages are
build under cygwin and I am trying to duplicate the setup used.
[...]
Cygwin softlinks are unusable under native windows, so we need to
disableCygwin's "ln" command and let gcc's build scripts use "cp"
instead.</quote 2>
quote 2 above, is from web page
http://article.gmane.org/gmane.comp.gnu.mingw.user/25585
* * *
* * *
[FZ]
My congratulations, you have just build the stdcxx library :)
[SP]
Great!
Now I'll install the stdcxx library, for use with my NetBeans 6.5 IDE (With
C++ plugin.)
Is there a simple test I can use, a simple C++ program, that e.g. obtains
the
ID and version of the stdcxx library?
After I install the stdcxx library, I would like to conclusively PROVE to
myself,
that I'm actually hooking into the stdcxx library, and not the standard
library shipped with MinGW.
* * *
* * *
[FZ]
Hmm, you must be wrong, we don't have any file with the name "build" in svn.
[SP}
You are correct -- my apologies.
The /stdcxx-4.2.2/build file, that I mistakenly thought came with the svn,
was a file link named "build", linked to
/stdcxx-4.2.2/etc/config/makefile.rules.
This link was created by the buggy MinGW <ln> command that I described in my
"Fix #1 -- /stdcxx-4.2.2/CNUmakefile".
I must have run the make first once, and forgot about the buggy MinGW <ln>
that created the /stdcxx-4.2.2/build file link. So I assumed that the
/stdcxx-4.2.2/build file came with the svn.
* * *
* * *
[FZ]
It depends on what you want :) You have build the stdcxx library
successfully, so now you can compile
your programs with stdcxx.
[...]
18.c.limits.stdcxx-988.cpp is just one of the regression tests. It was not
verified on gcc/MinGW so
it fails to compile. But this failure doesn't means that there is some
problem or bug in stdcxx library.
[SP]
I don't entirely follow your thinking.
I'm glad to know that I've successfully built the stdcxx library -- that's a
HUGE step in the right direction. And certainly I'm going to start using
stdcxx in my C++ programming work.
HOWEVER, until ALL the stdcxx tests are verified as ok on gcc/MinGW, this
means
that there IS/ARE some problem(s) with stdcxx in MinGW, does it not? After
all, isn't
the purpose of the tests to prove that the stdcxx libary on the target
system is working correctly?
Steve
----- Original Message -----
From: "Farid Zaripov" <Fa...@epam.com>
To: <us...@stdcxx.apache.org>
Sent: Thursday, November 27, 2008 2:24 PM
Subject: RE: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
> I assume that you are building stdcxx-4.2.2 using Cygwin, and targeting
> MinGW. My objective is to build stdcxx-4.2.2 using MinGW. I don't use
> Cygwin
> and I don't plan to use it.
Actually my goal is make it possible to build stdcxx/MinGW and
stdcxx/Cygwin
using Cygwin environment as well as stdcxx/MinGW using MSYS environment.
> There were two fixes I had to make, to get the build of the patched
> stdcxx-4.2.2 to run:
[...]
> On the three lines marked ** above, I added an explicit file name after
> the
> $(buildpath) because the MinGW <ls> command, was REPLACING the
> /stdcxx-4.2.1/build/ directory name, with a link (named
> /stdcxx-4.2.1/build)
> to the file, instead of creating a link to the file (with the name of the
> file), IN the /stdcxx-4.2.1/build/ directory.
I have no such problems when running make on MSYS.
> Fix #2 -- Your /stdcxx-4.2.2/build file:
>
> I renamed the /stdcxx-4.2.2/build file that came with the svn download, to
> /stdcxx-4.2.1/build_faridz, because the presence of the build FILE was
> preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/
> DIRECTORY.
Hmm, you must be wrong, we don't have any file with the name "build" in
svn.
[...]
> There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB.
My congratulations, you have just build the stdcxx library :)
> HOWEVER, the build ended with the following displayed on the MSYS console:
When you run make without targets specified, the examples, tests, locales
will be build.
Not all tests are compiling without errors on gcc/MinGW at the moment. It is
ok.
You can build the library only (without examples, tests and so on) using
this command: "make config lib"
Also I suggest to explicitly specify the build type. I.e.:
make BUILDDIR=/var/tmp/stdcxx-4.2.2/gcc/15d BUILDTYPE=15d config lib
> In the line "make[1]: [tests] Error 2 (ignored)", does the "(ignored)"
> mean
> that <make> did not terminate prematurely, and that file:
>
> /stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp
>
> is the last test source file to be compiled?
I don't think so. The make should stop on the first error encountered
unless make was executed with "-k" option specified.
> According to the /stdcxx-4.2.2/README file, the last build step is the
> locale databases. The build I ran left the /stdcxx-4.2.2/nls/ directory
> completely EMPTY.
Right, that because of make stopped on the compile error you mentioned
above.
> Please let me know -- did the build complete successfully?
It depends on what you want :) You have build the stdcxx library
successfully, so now you can compile
your programs with stdcxx.
> If not, and I
> need to fix the 18.c.limits.stdcxx-988.cpp compile error, what changes to
> I
> need to make to fix the compile error?
18.c.limits.stdcxx-988.cpp is just one of the regression tests. It was not
verified on gcc/MinGW so
it fails to compile. But this failure doesn't means that there is some
problem or bug in stdcxx library.
Farid.
RE: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by Farid Zaripov <Fa...@epam.com>.
> I assume that you are building stdcxx-4.2.2 using Cygwin, and targeting
> MinGW. My objective is to build stdcxx-4.2.2 using MinGW. I don't use Cygwin
> and I don't plan to use it.
Actually my goal is make it possible to build stdcxx/MinGW and stdcxx/Cygwin
using Cygwin environment as well as stdcxx/MinGW using MSYS environment.
> There were two fixes I had to make, to get the build of the patched
> stdcxx-4.2.2 to run:
[...]
> On the three lines marked ** above, I added an explicit file name after the
> $(buildpath) because the MinGW <ls> command, was REPLACING the
> /stdcxx-4.2.1/build/ directory name, with a link (named /stdcxx-4.2.1/build)
> to the file, instead of creating a link to the file (with the name of the
> file), IN the /stdcxx-4.2.1/build/ directory.
I have no such problems when running make on MSYS.
> Fix #2 -- Your /stdcxx-4.2.2/build file:
>
> I renamed the /stdcxx-4.2.2/build file that came with the svn download, to
> /stdcxx-4.2.1/build_faridz, because the presence of the build FILE was
> preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/ DIRECTORY.
Hmm, you must be wrong, we don't have any file with the name "build" in svn.
[...]
> There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB.
My congratulations, you have just build the stdcxx library :)
> HOWEVER, the build ended with the following displayed on the MSYS console:
When you run make without targets specified, the examples, tests, locales will be build.
Not all tests are compiling without errors on gcc/MinGW at the moment. It is ok.
You can build the library only (without examples, tests and so on) using this command: "make config lib"
Also I suggest to explicitly specify the build type. I.e.:
make BUILDDIR=/var/tmp/stdcxx-4.2.2/gcc/15d BUILDTYPE=15d config lib
> In the line "make[1]: [tests] Error 2 (ignored)", does the "(ignored)" mean
> that <make> did not terminate prematurely, and that file:
>
> /stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp
>
> is the last test source file to be compiled?
I don't think so. The make should stop on the first error encountered unless make was executed with "-k" option specified.
> According to the /stdcxx-4.2.2/README file, the last build step is the
> locale databases. The build I ran left the /stdcxx-4.2.2/nls/ directory
> completely EMPTY.
Right, that because of make stopped on the compile error you mentioned above.
> Please let me know -- did the build complete successfully?
It depends on what you want :) You have build the stdcxx library successfully, so now you can compile
your programs with stdcxx.
> If not, and I
> need to fix the 18.c.limits.stdcxx-988.cpp compile error, what changes to I
> need to make to fix the compile error?
18.c.limits.stdcxx-988.cpp is just one of the regression tests. It was not verified on gcc/MinGW so
it fails to compile. But this failure doesn't means that there is some problem or bug in stdcxx library.
Farid.
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Posted by Martin Sebor <ms...@gmail.com>.
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