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)
Farid Zaripov wrote:
Although it probably shouldn't be called liblibstd, should it?
What's with the duplicate "lib" part?
I think you should know, that the library file located in lib subdirectory ;)
I suppose that there missed '/' after the first 'lib':
/stdcxx-4.2.2/build/lib/libstd.a
And what I don't like is that when BUILDTYPE is not specified, the name of
library file is always
libstd.{a;so} for any possible BUILDMODE values (even for empty BUILDMODE). The
comments
in GNUMakefile says that BUILDTYPE and BUILDMODE both are optional and by
default will be
used 11s, but this is not true...
We should fix the text. When you don't specify either you get neither
debugging (i.e., no -g) nor optimization (i.e., no -O). I.e., you get
whatever the default invocation of the compiler gives you with no
options.
Martin
Farid.
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
> Although it probably shouldn't be called liblibstd, should it?
> What's with the duplicate "lib" part?
I think you should know, that the library file located in lib subdirectory ;)
I suppose that there missed '/' after the first 'lib':
/stdcxx-4.2.2/build/lib/libstd.a
And what I don't like is that when BUILDTYPE is not specified, the name of
library file is always
libstd.{a;so} for any possible BUILDMODE values (even for empty BUILDMODE). The
comments
in GNUMakefile says that BUILDTYPE and BUILDMODE both are optional and by
default will be
used 11s, but this is not true...
Farid.
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)
> 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, 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 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.
