Re: [SUCCESS] Building stdcxx-4.2.2 Using MinGW+MSYS On Windows XP (SP2)
[MS]
Steve Petrie, P.Eng. wrote:
[...]
I use the following MSYS console shell command, to compile the
test_stdcxx_1.cpp program:
g++.exe -I./include -nostdinc++ -nostdinc -nostdlib -c -o
test_stdcxx_1.o
test_stdcxx_1.cpp
You also need -I./include/ansi. Its also a good idea to avoid
using the g++ command and use gcc instead just to make it 100%
clear that the native C++ Standard Library should not be linked
(unless you know better , I don't think you want -nostdlib as
it normally prevents linking with files you want to link with).
[...]
That's because you're missing -Iinlude/ansi -- that's where
our cwchar lives. All the errors after this one should clear
up after you add it.
[SP]
OK -- I now have a test program that compiles, links and runs using stdcxx
under MinGW+MSYS.
There's more to it than adding -I./include/ansi to the compile as Martin
suggested, but the -I./include/ansi is definitely necessary.
Here's the test program (it's based on the sample that Farid provided at my
request, designed to conclusively PROVE that it's using stdcxx and not only
the standard library shipped with MinGW+MSYS (The __rw_atomic_add32()
function is SPECIFIC to stdcxx, there's no _atomic-x86.h in MinGW) :
// test_stdcxx_2.cpp ...
// standard library includes...
#include
// ...standard library includes.
using std::cout;
// app includes...
#include "rw/_atomic-x86.h"
//... app includes.
using __rw::__rw_atomic_add32;
int main (void)
{
cout << "Hello from test_stdcxx_2.cpp!\n";
int ret = -1;
// dependency on stdcxx library
ret = __rw::__rw_atomic_add32 (&ret, 1);
return ret;
}
// ... test_stdcxx_2.cpp.
* * *
* * *
Here is an MSYS console shell command that successfully compiles the
test_stdcxx_2.cpp program:
gcc.exe -D_RWSTDDEBUG -I./include -I./include/ansi -c -o test_stdcxx_2.o
test_stdcxx_2.cpp
I use the -D_RWSTDDEBUG parameter, because my stdcxx library was built for
debugging.
* * *
* * *
The link is more complicated.
I could NOT find any way to use gcc.exe or g++.exe, to get a successful
link. So I analyzed the various forms of the parameters used with the
following intermediate command (generated by gcc.exe and g++.exe from my
parameters used with them):
i:/apps/mingw/bin/../libexec/gcc/mingw32/3.4.5/collect2.exe ...
parameters ...
Here is the MSYS console shell command, that successfully links the
test_stdcxx_2.o object file (the key items are flagged "**n" here for
convenient reference below):
ld.exe \
-Bstatic \ **1
-o test_stdcxx_2.exe \ **2
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../crt2.o \
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/crtbegin.o \
-L./lib \ **3
-Li:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5 \
-Li:/apps/mingw/bin/../lib/gcc \
-Li:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/lib \
-Li:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../.. \
test_stdcxx_2.o \ **4
-lstd11s \ **5
-lstdc++ \ **6
-lmingw32 \
-lgcc \
-lmoldname \
-lmingwex \
-lmsvcrt \
-luser32 \
-lkernel32 \
-ladvapi32 \
-lshell32 \
-lmingw32 \
-lgcc \
-lmoldname \
-lmingwex \
-lmsvcrt \
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/crtend.o
The key points in the above are:
**1 => either -Bstatic or -Bdynamic works (omitting the -B parameter
entirely also works).
**2 => -o test_stdcxx_2.exe is the executable to be generated.
**3 =>-L./lib is the directory containing the libstd11s.a build of Apache
stdcxx, built with MinGW_MSYS
(it's FIRST in the list of -L parameters, as I assume this
will give it search priority).
**4=> test_stdcxx_2.o is the object input (it MUST precede the -lstd11s
parameter).
**5 => -lstd11s is the reference to the libstd11s.a build of Apache stdcxx
(it's FIRST in the list of -l parameters, as I assume this
will give it search priority).
**6 => -lstdc++ is the reference to the standard library shipped with
MinGW
(it's NECESSARY to resolve references in some of the
MinGW-supplied object modules)
* * *
* * *
I have a shell script file, that compiles, links and runs the C++ test
program. If you would like to have the script file, and the C++ source file,
just let me know.
For purposes of performing this test, the MSYS console current directory is
where the source program test_stdcxx_2.cpp is:
i:/USR/ASP/stdcxx/
and the libstdcxx.a library is in:
i:/USR/ASP/stdcxx/lib/
* * *
* * *
There are now only two OUTSTANDING ISSUES:
(1) The link produces a HUGE (4.9 MB) test_stdcxx_2.exe executable:
(1.1) I've tried the ld "--gc-sections" parameter, which the
ld --help says will "Remove unused sections (on some targets)"
but it doesn't shrink the executabl
Re: Building stdcxx-4.2.2 Using MinGW+MSYS On Windows XP (SP2)
Hi Farid:
[FZ]
It's ok. The rwstderr.cat catalog file is used for overriding standard
exceptions
what() messages (i.e. to have localized messages). On MinGW (as well as on
entire Windows) stdcxx doesn't using rwstderr.cat, but using rwstderr.dll
instead.
Actually if you're fine with english messages, you don't need
rwstderr.{cat|dll}
because of the english messages are hardcoded in library sources.
[SP]
Thanks to your previous assistance, I did succeed in using the GNUmakefile
under MinGW+MSYS, to build a stdcxx libnary libstd11s.a.
HOWEVER, I've been trying without success, to compile a minimal C++ program
under MinGW+MSYS, using the Apache C++ Standard Library (stdcxx), instead of
the Standard Library that is shipped with MinGW+MSYS.
* * *
* * *
The MinGW_MSYS environment, will compile, link and run the following test
program, using the Standard Library shipped with MinGW_MSYS:
// test_mingw.cpp ...
// standard library includes...
#include
// ...standard library includes.
using std::cout;
int main (void)
{
cout << "Hello from test_mingw.cpp!\n";
return 0;
}
// ... test_mingw.cpp.
I use the following MSYS console shell commands to compile and link the
test_mingw.cpp program:
g++ -c -o test_mingw.o test_mingw.cpp # compiles ok.
g++ -o test_mingw test_mingw.o # links ok.
The test_mingw.exe program produce by ld, runs fine and displays the
following on the MSYS console:
Hello from test_mingw.cpp!.
* * *
* * *
HOWEVER, so far I have not found a way to compile a similar minimal C++
program under MinGW+MSYS, using the Apache C++ Standard Library (stdcxx),
instead of the Standard Library that is shipped with MinGW+MSYS.
The minimal C++ program I'm trying to compile is:
// test_stdcxx_1.cpp ...
// standard library includes...
#include
// ...standard library includes.
using std::cout;
int main (void)
{
cout << "Hello from test_stdcxx_1.cpp!\n";
return 0;
}
// ... test_stdcxx_1.cpp.
I use the following MSYS console shell command, to compile the
test_stdcxx_1.cpp program:
g++.exe -I./include -nostdinc++ -nostdinc -nostdlib -c -o test_stdcxx_1.o
test_stdcxx_1.cpp
(Note the dot "." between "-I" and "/include". I have an stdcxx "include"
directory, with all its sub-directories, as a sub-directory of the directory
where the test_stdcxx_1.cpp source program is located, because I haven't yet
been able to figure out how to get g++.exe to respect a "-I" parameter
pointing to a more complex path description. The "include" directory, with
all its sub-directories, is a copy of what is shipped with stdcxx-4.2.2.)
g++.exe displays the following compile errors on the MSYS console:
In file included from ./include/rw/_traits.h:40,
from ./include/rw/_strref.h:48,
from ./include/string:43,
from ./include/loc/_locale.h:36,
from ./include/rw/_iosbase.h:36,
from ./include/streambuf:39,
from ./include/ostream:39,
from ./include/istream:38,
from ./include/iostream:33,
from test_stdcxx_1.cpp:4:
./include/rw/_mbstate.h:195:27: cwchar: No such file or directory
In file included from ./include/rw/_strref.h:48,
from ./include/string:43,
from ./include/loc/_locale.h:36,
from ./include/rw/_iosbase.h:36,
from ./include/streambuf:39,
from ./include/ostream:39,
from ./include/istream:38,
from ./include/iostream:33,
from test_stdcxx_1.cpp:4::
./include/rw/_traits.h:104:51: cstring: No such file or directory
In file included from ./include/rw/_strref.h:48,
from ./include/string:43,
from ./include/loc/_locale.h:36,
from ./include/rw/_iosbase.h:36,
from ./include/streambuf:39,
from ./include/ostream:39,
from ./include/istream:38,
from ./include/iostream:33,
from test_stdcxx_1.cpp:4:
./include/rw/_traits.h:302: error: expected `;' before "state_type"
./include/rw/_traits.h:303: error: `state_type' was not declared in this
scope
./include/rw/_traits.h:303: error: template argument 1 is invalid
./include/rw/_traits.h: In static member function `static _CharT*
std::char_traits<_CharT>::move(_CharT*, const _CharT*, unsigned int)':
./include/rw/_traits.h:347: error: `memmove' is not a member of `std'
./include/rw/_traits.h: In static member function `static _CharT*
std::char_traits<_CharT>::copy(_CharT*, const _CharT*, unsigned int)':
./include/rw/_traits.h:353: error: `memcpy' is not a member of `std'
./include/rw/_traits.h: At global scope:
./include/rw/_traits.h:396: error: expected `;' before "state_type"
./include/rw/_traits.h
Re: Building stdcxx-4.2.2 Using MinGW+MSYS On Windows XP (SP2)
[FZ] I have MSYS 1.0.11.0(0.46/3/2) and "ln --version" reports version 5.97 [SP] The "ln" in MSYS 1.0.10 was pre-5.97, so I downloaded and installed: msysCORE-1.0.11-20080826.tar.gz. In this version of MSYS, the "ln" version is 5.97. I reverted to the GNUmakefile shipped with stdcxx-4.2.2, and ran the stdcxx-4.2.2 build under MSYS with the following command (following the instructions in your earlier email, except: changing the BUILDTYPE to 11s from 15D, and explicitly specifying the CONFIG=gcc.config): make BUILDDIR=/stdcxx-4.2.2/build_11s \ BUILDTYPE=11s \ CONFIG=gcc.config \ config lib The "ln" command worked ok, and the build created a "libstd11s.a" file of 12.4 MB size. HOWEVER, after the completion of the "ar rv libstd11s.a ..." command executed near the very end of the build process, the following was displayed on the MSYS console, and the build process stopped: ar rv libstd11s.a [...] a - valarray.o a - vecbool.o a - version.o a - wcodecvt.o a - wctype.o i:\apps\mingw\bin\ar.exe: creating libstd11s.a gencat rwstderr.cat /stdcxx-4.2.2/src/rwstderr.msg /bin/sh: gencat: command not found make[2]: [rwstderr.cat] Error 127 (ignored) make[2]: Leaving directory `/stdcxx-4.2.2/build_11s/lib' make[1]: Leaving directory `/stdcxx-4.2.2/build_11s' make: Nothing to be done for `lib'. [EMAIL PROTECTED] /stdcxx-4.2.2 It looked to me like the (line 10) message: "/bin/sh: gencat: command not found" happened because the stdcxx-4.2.2 utilities had not been built, so no "gencat.exe" utility program existed.. So I deleted the "build_11s" build, and ran the stdcxx-4.2.2 build under MSYS, using the following command: make BUILDDIR=/stdcxx-4.2.2/build_11s \ BUILDTYPE=11s \ CONFIG=gcc.config \ builddir config util lib locales Again, the build ended, with a "/bin/sh: gencat: command not found" error. However, there was now a "gencat.exe" in /stdcxx-4.2.2/build_11s/bin". It looked like the "/bin/sh: gencat: command not found" error was caused because "gencat.exe" was not reachable via any path definition. So I copied "gencat.exe" into the /msys/1.0.11/bin/" directory, and tried to install the library, using the following command, with MSYS in the /stdcxx-4.2.2/build_11s directory: make install PREFIX=install_11s The install displayed the following on the MSYS console: $ make install PREFIX=install_11s mkdir -p install_11s make -Clib install make[1]: Entering directory `/stdcxx-4.2.2/build_11s/lib' gencat rwstderr.cat /stdcxx-4.2.2/src/rwstderr.msg windres: i:/apps/stdcxx-4.2.2/src/rwstderr.msg:1: syntax error make[1]: [rwstderr.cat] Error 1 (ignored) mkdir -p install_11s/lib cp libstd11s.a install_11s/lib if [ libstd11s.a != libstd11s.a ]; then \ rm install_11s/lib/libstd11s.a; \ ln -s libstd11s.a install_11s/lib/libstd11s.a; \ fi mkdir -p install_11s/etc cp rwstderr.cat install_11s/etc cp: cannot stat `rwstderr.cat': No such file or directory make[1]: *** [install] Error 1 make[1]: Leaving directory `/stdcxx-4.2.2/build_11s/lib' make: *** [install] Error 2 [EMAIL PROTECTED] /stdcxx-4.2.2/build_11s On line 6 of the above, the gencat command failed, and displayed: "windres: i:/apps/stdcxx-4.2.2/src/rwstderr.msg:1: syntax error". On line 16 of the above, the cp command failed (due to the earlier failure of the gencat command), and displayed: "cp: cannot stat `rwstderr.cat': No such file or directory". I tried changing the format of file "rwstderr.msg" from DOS to UNIX format (i.e from 0D0A line ends, to 0A line ends) but got the same error from "gencat.exe". So now I'm stuck at the install step. Would please tell me, what do I need to do, to get the gencat.exe utility to accept the rwstderr.msg file? Thanks, Steve - Original Message - From: "Farid Zaripov" <[EMAIL PROTECTED]> To: Sent: Friday, November 28, 2008 8:09 AM Subject: Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2) But I definitely DO have the problem with "ln" on my MSYS :( [...] 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 MSYS 1.0.11.0(0.46/3/2) and "ln --version" reports version 5.97 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? Unfortunately, I don't see any file attached :( Here are a couple of interesting quotes related to MinGW+MSYS and ln, that I found through a Google search: 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. Right, the ln just copying file on my sid
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
[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." <[EMAIL PROTECTED]> To: 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 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: 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. 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 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 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 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. HOW
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 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: 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. 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 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 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 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" <[EMAIL PROTECTED]> To: 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 command, w
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
[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" <[EMAIL PROTECTED]> To: 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)
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" <[EMAIL PROTECTED]> To: 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)
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" <[EMAIL PROTECTED]> To: 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.
