stdcxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Petrie, P.Eng." <apet...@attglobal.net>
Subject Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Date Fri, 28 Nov 2008 05:05:45 GMT
[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" <Farid_Zaripov@epam.com>
To: <user@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.

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message