mingw-users Mailing List for MinGW - Minimalist GNU for Windows

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26/02/17 02:54, David Gressett wrote:
> I then downloaded and installed the proposed version 5 releases
> of mingwrt and w32api and tried the gcc 6.3.0 build again

Okay, thanks.

> It failed, with the crash of a program that is part of the Ada 
> build system: xsinfo.exe, located in my build tree at 
> 
> gcc-6.3.0-mingw32/gcc/ada/bldtools/sinfo/xsinfo.exe
> 
> xsinfo almost completed successfully; Here are the last few
> lines that it displayed in my msys window:
> 
> "Check for missing functions in body
>      OK
> 
> Check Set procedures in body
>      OK
> 
> Check for missing set procedures in body
>      OK
> 
> All tests completed successfully, no errors detected

So, it appears that it may have reached the end of it's main() 
function, then failed in the termination code.

> This application has requested the Runtime to terminate it in
> an unusual way. Please contact the application's support team
> for more information."

That's got to be one of the least useful error messages, ever.

> The "unusual way" line also appeared in a Windows popup error
> message box. I will supply more information later as I do more
> detective work to try to find the cause of the failure.

Did that popup message box not report a status code?  Knowing 
that might have been helpful.  It's possible that this is some 
sort of latent bug in the xsinfo.exe program itself, just as it 
may be due to some change in mingwrt or w32api.  Could you run 
xsinfo.exe under GDB, to determine where it is crashing?  Or,
build mingwrt and w32api from the repository, then run a git 
bisect over the changes since the last 3.x releases?

If you can do this, I'll hold off on the release of 5.0 for a 
couple of weeks, until we can glean some useful information 
about this crash.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYteqqAAoJEMCtNsY0flo/6O4P/RcNkv8LYRgqu2wstjY/d/6A
zAgHJ8iXJyxQE3Dv8H8vZGUS9HgmWH8CDgxleCesJ9coSRWlltZirfQgUkmOZ2EF
0gZo1YZDl2MJTYts1o51S/5Szlq/b2d7yEGqqKPl6rloxU2x7HwrytywgK0GOhRe
dp+bTGGd1UdK383nB6vZ9N86myGQgcQ397LQUewp15covMionukvqJvq5iAWiqkY
gUm/T5dRwdwvlphEwe/9YZpo++rxsBSuKYfPOkIEkbu6SLtoxmTeIiGr7gbYsTbq
YEL4iw6u5LmAm85G3qNQDQxGiN0Pu5s9CaI/u+Lf8wij2yiTRND8hrEYk34R6XGt
4kLHpybkaFdIZtWm496M6O3YBFbllKjq11EJcJV9MLKuS/hbcp4/wGoe3UDqC0hQ
IeXyHICK1BT+p1AiuYTM9UiOMJDhUErEskz7935j7fEHGckWdt5gNucCE99il3pn
UTTxd/r6P0zKDJEclrD05dxhKxEnfsa+eytGBGNSShhvyuSlbOWPKODjFWTyIHVZ
lxnZoHpdgFH7IVstKgvsDCOv2SkAU1oTasZwSOr0EvkKzb/lwVK8jw81YRKuVK2w
1usqefShTJllMpUurCrcfDRjAl5bdtz9rqNtODtw6AwLjULOhLemuVw1k1Xicbzg
vyJGbVg0YHibvHdGYnTB
=+AlD
-----END PGP SIGNATURE-----

On 2/25/2017 10:25 PM, Emanuel Falkenauer wrote:
> I agree: Outlook must be the worst program ever written by man. I'm on 
> Thunderbird, it's frankly excellent.
> 

I'm using Thunderbird with the Enigmail and Thunderbird Conversations
extensions.  Enigmail for PGP and Conversations for a threaded view of
all mail regardless of where I filter it to.  Conversations also allows
for reading your Inbox of multiple email accounts in one folder view.

-- 
Earnie

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/02/17 00:56, David Gressett wrote:
> B. Issue a series of export commands. There are nine of them:

This smacks of "cargo cult" programming ... something we really 
need to get away from.

> export GCC_EXEC_PREFIX=/mingw/lib/gcc/
> export LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
> export LDFLAGS_FOR_TARGET="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
> export LDFLAGS_FOR_BUILD="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
> export STAGE1_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
> export POSTSTAGE1_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
> export BOOT_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
> export TOOLS_LIBS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
> export SYSLIBS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"

How many of them do you *really* need; indeed, *why* do you need 
*any* of them?

> C. Issue the actual make command that does the compilation (3). 
> This is a really long command line. I'm going to break it into pieces to 
> make it easier to read.
> 
> make  LDFLAGS_FOR_TARGET="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
>  LDFLAGS_FOR_BUILD="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib" 
>  STAGE1_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib" 
>  POSTSTAGE1_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib" 
>  BOOT_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib" 
>  TOOLS_LIBS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib" 
>  SYSLIBS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
>   LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
>  2>&1 | tee ../../manual-compile.log
> 
> You can see that there is a lot of duplication of the export commands
> here.

Indeed ... which begs the question: what on earth was the purpose 
of redundantly cluttering up the environment with all of them?

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYtdyrAAoJEMCtNsY0flo/fmoP/j2U04KJbdlVLBkrtOuqMWAU
zi1EMvymk7BcZxNMf30eUkMEN8Tj222R/Xl/enyAXTZ9GjjAgEEqcxrzH1OxaJzA
YhEnR1z+/pp9vd20LUQjUcllZqPPdLai3VD8Uzx/g2ENqj/FJ5ZTCYZNBzySfWD1
Kj0nI8c0PZ0wUMbdxd5lCxMqfsD7qbav4MxumGBa0QJa4gk+RfeUIRpR7gBFi/Vd
TgghbImBleEkmlRJsTskMpufLANd7aAcyO1jY71WpVydebKmI67qKyJmVeqP+pvT
KTBalEy5raJ1KBCuXNWdPYk+vW0hx6YP3AbOSg6KTPj0IwN/uf0nj+IPQUb4lg4b
aC73SCN6fkcj6vyzwuIEIa1Pa5cyocARhurLZFX2bt8tg4nhU1kyHLC/DgosiKGa
t+sCrnLj40Faw7rMtGY4WHQUGZ7Vjt898LVY8kr4YmTFVEgT0IYC4JTrY6cFueeF
u6knITWU62nIzvLyttS6y0vnZLh+DbyQ9juRXv2QMWLZ4f6X2Mq0pPQyntOrcT3/
X8j+7XC7UVl09M138hpP/YlqJWQQoQoc6LiUQ3GdqSPsWCDZOXjd/XvPvhalMu6j
Gd297AHELEh3Eh9s2+E3A6AoqtzncstuQjs/7DGtf3+w7fELqrnp/QXoTEpw/wO0
x1LpN8yODkInhwwcbh8G
=msnc
-----END PGP SIGNATURE-----

--- snip ...
>The third step is a "make install" in nice environments like Linux.
... snip...

Mistake, that should be  just "make"

... snip ...
>The below of course does not relate to MinGW32, but I'm 
>neither informed what FLAGS and configure arguments 
>generally are for MinGW32 gcc versions. 
>Could someone send me what these might be?

Read all of this, its long ...

Download the  the MinGW gcc-5.3.0 source code from Sourceforge
 MinGW section. When you untar it, you will get a source code  tree
 which has an addition:  a directory named "arch", which contains
a subdirectory named mingw32 which contains the answers to your
question, in the file gcc-5.3.0-mingw32.pkgspec. The other files are
patches to the  upstream gcc source code which are needed in
order to successfully compile.  

Actually getting the compilation to work on a Windows platform
will be a bit of a chore - the build instructions as documented by the
main gcc project will not work.  (Keith Marshall, who built and
packaged the MinGW gcc does a cross build on a Linux system)

Keith uses a build tool for his cross builds which provides a
much easier build than is possible with the upstram gcc
build instructions.  Unfortunately, it does not yet completely
work in the MinGW environment that you must use (msys).

The basic build process is this:

1. Apply patches.
2. Execute the configuration  needed for gcc to be compiled
for the mingw environment.
3. Compile the source code.
4. Install it to a staging directory.
5. Construct tha final product tar files that can be unpacked into
a running mingw installation.

Keith's build system, mingw-pkg, will only do the first two steps
on Windows.

Where to get mingw-pkg and instructions for installing it have
been discussed recently on this list - you should go back and find
and read those messages if you want to simplify the first two
build steps.

The third step is a "make install" in nice environments like Linux.
There is no such luck in Windows. I extracted a hack which solves
that problem from a makefile used in a now-abandoned build
system used in an earlier mingw gcc release.

Here is the build directory stucture that I use
I create a directory named "workspace".  It is easiest to do this
in your msys home directory, but it can go anywhere.
I create under it the directories "src" and "build/gcc-5.3.0-mingw32"

Put the Mingw source tarball in src and untar it there.
Note that you should use the MinGW installer to make
sure that you have the prerequisite libraries like gmp, mpfr, etc.
installed. Otherwise, follow gcc installation instructions
and unpack them into the gcc source tree.

Then make the gcc-5.3.0-mingw32 directory your
current directory.  Note that you are now two levels below
the workspace directory.

Now, do the patch step (1). If you have mingw-pkg, do this:

mingw-pkg SRCDIR=../../src/gcc-5.3.0 patch 2>&1 | tee ../../mingw-pkg-patch.log

Otherwise, do  a manual application of the patches.

Now the configure step. (2)

mingw-pkg SRCDIR=../../src/gcc-5.3.0 configure 2>&1 | tee ../../mingw-pkg-configure.log

Otherwise, as above, do the configure manually.

To do the compilation step (3), then you must use the hack.
It consists of three parts:

A. Hack a .o file from mingw into the  into the building directory:

mkdir gcc
cp -a /mingw/lib/crt2.o gcc/

B. Issue a series of export commands. There are nine of them:
export GCC_EXEC_PREFIX=/mingw/lib/gcc/
export LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
export LDFLAGS_FOR_TARGET="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
export LDFLAGS_FOR_BUILD="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
export STAGE1_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
export POSTSTAGE1_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
export BOOT_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
export TOOLS_LIBS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
export SYSLIBS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"

C. Issue the actual make command that does the compilation (3). 
This is a really long command line. I'm going to break it into pieces to 
make it easier to read.

make  LDFLAGS_FOR_TARGET="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
 LDFLAGS_FOR_BUILD="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib" 
 STAGE1_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib" 
 POSTSTAGE1_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib" 
 BOOT_LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib" 
 TOOLS_LIBS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib" 
 SYSLIBS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
  LDFLAGS="--verbose -L/mingw/mingw32/lib -B/mingw/mingw32/lib"
 2>&1 | tee ../../manual-compile.log

You can see that there is a lot of duplication of the export commands here.
 All of this was needed to get gcc 4.8.1 to build. It may be possible to leave
some of this out for more recent versions, but I have not yet done the
 time-consuming experiments needed to know.

Now comes  the staging installation. (4). 
Do not do a simple-minded "make install".
Some hackery must be done  Do something like

make DESTDIR=someconvenientststagingdirectory install

Then you go into the staging directory and fix problems.
The main one is that most of the executables have "mingw32-"
prefixed onto their names, and these need to be renamed,
so that mingw32-whatever.exe becomes whatever.exe.
Some files are supposed to have this, and do they get a
double dose. These are mingw32-mingw32-whatever.exe"
Rename these as mingw32-whatever.exe.

The best way to identify problems is to download all of
the mingw32 binary manual installation tarballs and 
compare them file-by-file with the staging installation.
I made a directory listing of the whole lot and used it
 as a base to add notes about what installed correctly 
and what didn't. There were only a few other failures.
The vast majority of files installed correctly.

Do note, however: You may not want to do this with
the 5.3.0 version that Keith has released as source code.
I have done all of this with gcc 6.3.0,  the latest upstream
release, and the only problem in it is the executables
in the bin directory still have the mingw- prefix. All of the
other filename glitches and disappearances  have 
vanished. To do this you will need to do several more 
patches in step (1). Let me know and I will post them to 
this list.

>P.S. I'm not clear what the HTML policy ...
... snip ...

Never do HTML. The most experienced people on this
list (and most others) use Unix or Linux e-mail clients 
that completely freak out on HTML mail, and they will
 ignore such postings. I'm stuck with Microsoft Outlook
at work, which is where I am writing this, and although I
can turn off HTML, and I have done so for this message,
it is still not very good for this list.

I am going to get a new e-mail address and a better
mail client for future posting to this list and others, and 
I recommend that you do something similar.

Also, never top-post. Put your answers below the
questions, as I have done. A good mail client
will mark the question lines with a > prefix automatically.
This is proper Unix/Linux email structure. Do that
manually in bad clients like Outlook. Keep the lines
short.

it is ascii 10, linefeed.  I got it.  apparently by looking at it, thought
it should print 'a'
instead the last character the getchar gets was newline.  I should
investigate more before asking but I appreciate all of your replies.

Thanks!.

2017-02-27 3:27 GMT-05:00 KHMan <kei...@gm...>:

> On 2/27/2017 12:24 PM, Chan Oak wrote:
> > here source code
> >
> > #include <stdio.h>
> > #define MAX 100
> > char aaa[MAX];
> > int addstr(char a)
> > {
> >      static int cur = 0;
> >      if (cur > MAX)
> >          return 0;
> >      else
> >          aaa[cur] = a;
> >
> >      return 1;
> > }
> > int main()
> > {
> >      char a;
> >      int i;
> >
> >      while ((a = getchar()) != EOF)
> >      {
> >          addstr(a);
> >      }
> >      printf("%c", aaa[0]);
> >      printf("hello\n");
> > }
> >
> > here is output
> >
> > a
> > ^Z
> > hello
> > the global array aaa[0] is modified yet it does not print aaa[0].
> > if I put printf inside function addstr to print aaa[0], it does print
>
> In addstr(), cur is not much of a use unless you increment it.
> aaa[0] ends up with the last character before the ^Z
>
> Try:
> ====
>    printf("%c%d", aaa[0], aaa[0]);
>
> Modified Output:
> ================
> a
> ^Z
>
> 10hello
>
> Windows command prompt does line-by-line stdin. So the last
> character before the end-of-input ^Z is a newline, which should be
> a CRLF or an LF (apparently I got LF only, so LF it is). The last
> aaa[0] will be LF which is ASCII 10, as shown above. The empty
> line after ^Z is the output of %c (which is LF), the 10 is the
> output of %d (ASCII value of LF).
>
> --
> Cheers,
> Kein-Hong Man (esq.)
> Selangor, Malaysia
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>

If you're going to print aaa[] as a string, you'll need to make sure it is
properly terminated.  You can have addstr() bounds check against the
array's size before appending the input character and then afterward,
append a NULL character to kill two birds with one stone.

MinGW Users,

The below of course does not relate to MinGW32, but I'm neither informed what FLAGS and configure arguments generally are for MinGW32 gcc versions. Could someone send me what these might be?

Here's a page regarding variables utilised on a GNU/Linux distro.

http://slackblog.com/slackware/slackware-14.2/source/d/gcc/gcc.SlackBuild

I am curious if my assessment that the configure arguments for mingw-w64-i686-gcc-6.1.0-1-any.pkg.tar.xz might have resulted in the appending of a duplicate entry for '-mtune= ', when I ran an emacs-25.1 configure script utilising that toolchain.  

http://nurmi-labs.blogspot.com/2016/11/git.html

"I thought to compile emacs-25.1, and manually installed the gcc-6.1.0-1 and dependency packages, but when I ran the configure script with CFLAGS and examined the config.log the CFLAGS had been appended with a duplicate entry for -mtune=."

Sincerely,
Eric Lindblad

P.S. I'm not clear what the HTML policy is regarding the mailing list, whether this implies that URL links are not wanted in emails' content. My initial email regarding "macros for patches (haskell package)", sent after registering, has not been responded to, which, as above also contained links to my Internet log (blog).

Hello there!

You overwrite the first letter every time. The last thing in there is
EOF, I think. So that one is printed out. Increment "cur" somewhere.
Increment is "cur++" or "++cur" or "cur +=1;" or "cur = cur + 1;".

I hope that helps.

I'm not very good in english, interpersonal stuff might sound a bit clumsy.

Regards
Foster


2017-02-27 5:24 GMT+01:00 Chan Oak <cha...@gm...>:

> here source code
>
> #include <stdio.h>
> #define MAX 100
> char aaa[MAX];
> int addstr(char a)
> {
>     static int cur = 0;
>     if (cur > MAX)
>         return 0;
>     else
>         aaa[cur] = a;
>
>     return 1;
> }
> int main()
> {
>     char a;
>     int i;
>
>     while ((a = getchar()) != EOF)
>     {
>         addstr(a);
>     }
>     printf("%c", aaa[0]);
>     printf("hello\n");
> }
>
> here is output
>
> a
> ^Z
> hello
> the global array aaa[0] is modified yet it does not print aaa[0].
> if I put printf inside function addstr to print aaa[0], it does print
>
> is this compiler bug?
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>

On 2/27/2017 12:24 PM, Chan Oak wrote:
> here source code
>
> #include <stdio.h>
> #define MAX 100
> char aaa[MAX];
> int addstr(char a)
> {
>      static int cur = 0;
>      if (cur > MAX)
>          return 0;
>      else
>          aaa[cur] = a;
>
>      return 1;
> }
> int main()
> {
>      char a;
>      int i;
>
>      while ((a = getchar()) != EOF)
>      {
>          addstr(a);
>      }
>      printf("%c", aaa[0]);
>      printf("hello\n");
> }
>
> here is output
>
> a
> ^Z
> hello
> the global array aaa[0] is modified yet it does not print aaa[0].
> if I put printf inside function addstr to print aaa[0], it does print

In addstr(), cur is not much of a use unless you increment it.
aaa[0] ends up with the last character before the ^Z

Try:
====
   printf("%c%d", aaa[0], aaa[0]);

Modified Output:
================
a
^Z

10hello

Windows command prompt does line-by-line stdin. So the last 
character before the end-of-input ^Z is a newline, which should be 
a CRLF or an LF (apparently I got LF only, so LF it is). The last 
aaa[0] will be LF which is ASCII 10, as shown above. The empty 
line after ^Z is the output of %c (which is LF), the 10 is the 
output of %d (ASCII value of LF).

-- 
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia

On 2017-02-27 05:24, Chan Oak wrote:
> here source code
> 
> #include <stdio.h>
> #define MAX 100
> char aaa[MAX];
> int addstr(char a)
> {
>     static int cur = 0;
>     if (cur > MAX)
>         return 0;
>     else
>         aaa[cur] = a;
>    
>     return 1;
> }
> int main()
> {
>     char a;
>     int i;
>    
>     while ((a = getchar()) != EOF)
>     {
>         addstr(a);
>     }
>     printf("%c", aaa[0]);
>     printf("hello\n");
> }
> 
> here is output
> 
> a
> ^Z
> hello
> the global array aaa[0] is modified yet it does not print aaa[0].
> if I put printf inside function addstr to print aaa[0], it does print
> 
> is this compiler bug?

I suspect that aaa[0] contains a newline after the while loop and that
this is why you do not see what is actually printed before hello.

Try this instead.

#include <stdio.h>

char aaa[100];

int addstr(char a)
{
	static int cur;

	if (cur >= sizeof(aaa) / sizeof(aaa[0]))
		return 0;

	aaa[cur++] = a;
	return 1;
}

int main(void)
{
	char a;
   
	while ((a = getchar()) != EOF)
	{
		addstr(a);
	}

	printf("%s", aaa);
	printf("hello\n");

	return 0;
}

Hi Chan,

I think that first of all, you should be aware that the people who 
create compilers are extremely serious and, therefore, compiler errors 
are extremely rare. To give you a sense of proportion, in 30+ years of 
very heavy programming (i.e. millions of lines of code), I have really 
identified just FOUR TRUE compiler bugs (which have all been promptly 
corrected in the next release) - all the rest were my own bugs. In 
short: the first thing to check is definitely your own code.

Here are some pointers to look at:
- From your example it's not clear WHAT the aaa array should actually 
contain, as you don't specify what the getchar() actually gets: is it 
the char 'a' (i.e. the one actually printed!) or not? Please do not 
confuse a (the variable) with 'a' (the ASCII char constant)
- Furthermore, you never increment the "cur" variable in addstr(), which 
means that each new char input will simply overwrite aaa[0] - i.e. it's 
not ADDstr: it's really SETstr0
- Finally, if you actually were incrementing cur in addstr (which you 
aren't), it would eventually reach MAX, which would overflow the 
aaa[MAX] array (because it only goes up to [MAX-1]), causing all sorts 
of unpredictable mess.

I really don't want to offend you, and I actually applaud your 
enthusiasm... but it looks like some really basic C issues still elude you.

Best,

Emanuel


On 27-Feb-17 05:24, Chan Oak wrote:
> here source code
>
> #include <stdio.h>
> #define MAX 100
> char aaa[MAX];
> int addstr(char a)
> {
>     static int cur = 0;
>     if (cur > MAX)
>         return 0;
>     else
>         aaa[cur] = a;
>
>     return 1;
> }
> int main()
> {
>     char a;
>     int i;
>
>     while ((a = getchar()) != EOF)
>     {
>         addstr(a);
>     }
>     printf("%c", aaa[0]);
>     printf("hello\n");
> }
>
> here is output
>
> a
> ^Z
> hello
> the global array aaa[0] is modified yet it does not print aaa[0].
> if I put printf inside function addstr to print aaa[0], it does print
>
> is this compiler bug?
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe

here source code

#include <stdio.h>
#define MAX 100
char aaa[MAX];
int addstr(char a)
{
    static int cur = 0;
    if (cur > MAX)
        return 0;
    else
        aaa[cur] = a;

    return 1;
}
int main()
{
    char a;
    int i;

    while ((a = getchar()) != EOF)
    {
        addstr(a);
    }
    printf("%c", aaa[0]);
    printf("hello\n");
}

here is output

a
^Z
hello
the global array aaa[0] is modified yet it does not print aaa[0].
if I put printf inside function addstr to print aaa[0], it does print

is this compiler bug?

Thanks for Keith,I'm just a copycat. ;)
I copy the steps that build gcc-5.3 cross compiler as follow:

build enviroment:
os: ubuntu x86(i386) 14.10
gcc version: 4.9.1
gcc source version: 5.3

mingw32 build steps:
1) download source:
from sourceforge's mingw project:
  mingwrt-5.0 preview snapshot
  w32api-5.0 preview snapshot
  gcc-5.3.0 (distributed by MinGW.org)
from GNU mirror:
  binutils-2.26
  gmp-6.1.0
  mpfr-3.1.3
  mpc-1.0.2

2) make dirs:
$ cd $HOME
$ mkdir -p $HOME/mingw32-src/build/{binutils,gcc,mingwrt,w32api}
$ mkdir $HOME/mingw32-gcc-sandbox
$ ln -fs mingw32-gcc-sandbox mingw32
$ cd $HOME/mingw32
$ ln -s . mingw

3)prepare source:
unpack downloaded source packages to $HOME/mingw32-src.
$ cd $HOME/mingw32-src/gcc-5.3.0
$ ln -s ../gmp-6.1.0 gmp
$ ln -s ../mpfr-3.1.3 mpfr
$ ln -s ../mpc-1.0.2 mpc

4)export PATH:
$ export PATH=$PATH:$HOME/mingw32/bin

5)install mingw-pkg tool:
download mingw-pkg snapshot from
https://sourceforge.net/u/keithmarshall/mingw-pkg/ci/master/tree/

unpack downloaded mingw-pkg,configure,make and make install mingw-pkg. You
can get information form this thread:
https://sourceforge.net/p/mingw/mailman/message/35573728/

If you get error: sh: ../configure: No such file or directory.
No panic, just get autoconf installed( form ubuntu packages or get source
form gnu and install).

6)mingwrt (just headers):
$ cd $HOME/mingw32-src/build/mingwrt
$ ../../mingwrt-5.0/configure --build=unknown --host=mingw32
--prefix=$HOME/mingw32
$ make install-headers

7)w32api (just headers):
$ cd ../w32api
$ ../../w32api-5.0/configure --build=unknown --host=mingw32
--prefix=$HOME/mingw32
$ make install-headers

8)binutils:
$ cd ../binutils
$ ../../binutils-2.26/configure --target=mingw32
--{prefix,with-sysroot}=$HOME/mingw32 --disable-nls
$ make
$ make install

9)gcc: stage-1 build
$ cd $HOME/mingw32-src/gcc-5.3.0
$ mingw-pkg patch
$ cd $HOME/mingw32-src/build/gcc
$ ../../gcc-5.3.0/configure --{prefix,with-sysroot}=$HOME/mingw32 \ 
     --target=mingw32 --with-arch=i586 --with-tune=generic \ 
     --enable-shared --enable-threads --disable-win32-registry \ 
     --disable-sjlj-exceptions --disable-multilib --disable-nls \ 
     --disable-libvtv --with-dwarf2 --enable-languages=c,c++
$ make all-gcc && make install-gcc

10)gcc: check
make sure we can access it via $PATH
$ which mingw32-gcc
/home/www/mingw32/bin/mingw32-gcc

Here terminal display message should be different:
/home/**/mingw32/bin/mingw32-gcc   (** is your login account if you logined
with nonroot)

$ mingw32-gcc --version 
  mingw32-gcc (GCC) 5.3.0 
  Copyright (C) 2015 Free Software Foundation, Inc.

11)mingwrt:
$ cd ../mingwrt
$ ./config.status --recheck 
$ ./config.status 
$ make 
$ make install 

12)w32api:
$ cd ../w32api 
$ ./config.status --recheck 
$ ./config.status 
$ make 
$ make install

13)gcc: stage-2 build
$ cd ../gcc 
$ make all 
$ make instal

If you get some error like awk, get and install ubuntu gawk package.
If you get some error like m4, get and install ubuntu m4 package.
If you get error: 'wcstof' is not a member of 'std', you can apply the
workaround provided by keith:
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/617f15b16863cb5d542d1134e44e8fbd72739ad4/

Now we get building work done. Enjoy it!
Next, I'll move on and try to build windows-host ARM toolchain according to
Keith's advice.



--
View this message in context: http://mingw.5.n7.nabble.com/SPAM-I-m-a-newbie-to-MinGW-How-Can-I-build-MinGW-from-source-tp35651p35690.html
Sent from the MinGW - User mailing list archive at Nabble.com.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26/02/17 10:40, firebird wrote:
> I'm building against mingwrt-5.0 preview.  I take the workaround and
> build the gcc compiler successfully.
> 
> I wanna DIY gcc compiler.

Well, you have that now; it's GNU/Linux hosted, and it builds binaries 
for deployment on 32-bit MS-Windows, (or 64-bit in 32-bit mode).

> I want to use MinGW to build window-hosted ARM toolchains.

Do they need to be Windows hosted?  Since your host is GNU/Linux, would 
Linux hosted ARM tools not be more useful to you?

> There are some known out-of-box tools or windows installer,

For which you would need a Windows host.  In your case, you could run 
a virtual machine, but that could turn out to be an order of magnitude 
slower than tools running natively on the GNU/Linux host.

> I think DIY at source level maybe more useful to me. At first, I need
> to learn how to build the compiler from scratch.

You've already done that.  Now you can use it to build applications 
which will run on Windows; invoke it as "mingw32-gcc" or "mingw32-g++", 
just as you would invoke "gcc" or "g++" to build applications to run on 
the GNU/Linux host.  If the source uses a GNU standard configure script, 
you configure as you would for a native Linux build, but you must add 
the "--build=unknown --host=mingw32" configuration options; if you 
are building tools to run on Windows, but generate ARM code, you 
probably also need "--target=arm", (or appropriate identifier).

In your position, I would be seeking to adapt the technique I've just 
used to build a Linux hosted compiler for the mingw32 target, to build 
Linux hosted tools for the ARM target.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYssyhAAoJEMCtNsY0flo/tSkQAKufRXwSXksL0lf1jYTFAIgN
h+9eiifWTiQOUVrJThP/iMbAIOupKIOAIHtGsfqQXAVzgg4MyY3e4DfSPS2NKwAv
PQg1Wo0QKOGaDtOAVrmcvaHW/UbJGCSHyNryPYmjEp4P4zsXrBdPeGK/eqNxdA0j
XNHQ4f+O+c7rwFOBeqarBnKp7uglJlGNHrpSti8QIBwJWFFXxLgU2TRNkUGMPav9
RcM2mRWXwHLRRVAy6ZZb78pEgtXbCe6cKGhqd8DGbCM5NHGkiLvhymkw5F4iajjP
B4ZR2ucPPwSGuuSb9bc/E5qi9dF0NZqSJqDVPihVdeD22twVEqxRWx9d6X2PPQrc
3FuhJrVernY+7oLXiHysOS709H9WCPzuN+P0XZQKCYLIXoGs8MS7RksLAKNqRxYc
M4WNS9PpmQiuRf9rz01TBonLbP5YCQ8zbHEoOh+Vz9nk9jTf9NIot3A0inCKg7PV
VMcaDqX+BGdh2anh+TyCP0kyo8Oecr7lbkW6bG2L53msrEyvco55/HNeRMfOvJO9
40uLnQgJHfYn1CtVXx+6zRAFk0sinwRBkYXVKLjMVw0d72J26sSLR/c37xsiAxnH
DjrSLJx8lrUhS7ma+K7dYkTdp14tU5DacdBgBQ3j5jdEKaktnvQGohgnZ3CryIz7
qLdcbYvrJZibWENEfj4R
=GQrM
-----END PGP SIGNATURE-----

Addendum: for lists/forums like Mingw, Thunderbird offers the very cool 
button "Reply List".  ;-)

When Thunderbird (TB) suddenly ceased to function on my machines some 
five years ago, I switched to Outlook because I desperately needed an 
e-mail client immediately... but got so disgusted with the monstrosity 
that I went those hundred extra miles to rebuild TB from sources and 
debug it to figure out what was wrong. Took me three full days... but I 
did find the bug (as well as an immediate workaround), which was duly 
corrected by the TB team just a few versions later.
I returned to TB... and boy were those three days well spent!


On 26-Feb-17 04:25, Emanuel Falkenauer wrote:
> I agree: Outlook must be the worst program ever written by man. I'm on
> Thunderbird, it's frankly excellent.
>
> On 26-Feb-17 04:00, David Gressett wrote:
>> What would be the best e-mail client for  Windows to use for
>> communication  with the mingw-users and mingw-dvlpr lists?
>>
>> Microsoft Outlook is a flaming heap of garbage,and the various
>> web-based mail systems that I have seen are only a little better
>> than that.
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> MinGW-users mailing list
>> Min...@li...
>>
>> This list observes the Etiquette found at
>> http://www.mingw.org/Mailing_Lists.
>> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>>
>> _______________________________________________
>> You may change your MinGW Account Options or unsubscribe at:
>> https://lists.sourceforge.net/lists/listinfo/mingw-users
>> Also: mailto:min...@li...?subject=unsubscribe
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>

I agree: Outlook must be the worst program ever written by man. I'm on 
Thunderbird, it's frankly excellent.

On 26-Feb-17 04:00, David Gressett wrote:
> What would be the best e-mail client for  Windows to use for
> communication  with the mingw-users and mingw-dvlpr lists?
>
> Microsoft Outlook is a flaming heap of garbage,and the various
> web-based mail systems that I have seen are only a little better
> than that.
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>

What would be the best e-mail client for  Windows to use for
communication  with the mingw-users and mingw-dvlpr lists?

Microsoft Outlook is a flaming heap of garbage,and the various
web-based mail systems that I have seen are only a little better
than that.

________________________________________
>From: Keith Marshall <kei...@us...>
>Subject: [Mingw-users] Pending new mingwrt and w32api releases

>Folks,

>Almost two weeks ago, I invited you to test pre-release snapshots of the
>proposed version 5.0 releases of these two package sets.  Vadim Zeitlin has kindly done so, in conjunction with his builds of wxWidgets, and has
>identified one minor issue, (which arises due to an upstream GCC bug; I
>have identified a workaround, to be included in the final release).

I am working on native Windows builds of gcc and have
successfully built 5.3.0, 5.4.0, and 6.3.0, with my
MinGW installation using the current mingwrt and w32api.

After successfully building  6.3.0, I installed 6.3.0 to replace
the gcc 5.3.0 installed by the MinGW installer and successfully
built 6.3.0 again.

I then downloaded and installed the proposed version 5 releases
of mingwrt and w32api and tried the gcc 6.3.0 build again

It failed, with the crash of a program that is part of the Ada build 
system: xsinfo.exe, located in my build tree at

gcc-6.3.0-mingw32/gcc/ada/bldtools/sinfo/xsinfo.exe

xsinfo almost completed successfully; Here are the last few
lines that it displayed in my msys window:

"Check for missing functions in body
     OK

Check Set procedures in body
     OK

Check for missing set procedures in body
     OK

All tests completed successfully, no errors detected

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information."

The "unusual way" line also appeared in a Windows popup error message box.
I will supply more information later as I do more detective work to try to 
find the cause of the failure.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/02/17 04:31, Ranger wrote:
> Thanks for Keith Marshall-3's patience!

You will exhaust it, if you keep calling me Keith Marshall-3.  Where 
are you getting this from anyway?  It is not my name, and I find your 
persistent use of it to be rather impolite.  My given name is Keith; 
my family name is Marshall, and "-3" has no business to be there at 
all; please, just call me Keith.

> ...

> error: 'wcstof' is not a member of 'std'

Are you still building against mingwrt-2.22.4?  Or did you switch to 
the mingwrt-5.0 preview?  I didn't fall foul of it myself, but this is 
a recently identified (upstream) GCC bug, and some other condition had 
already prompted me to apply the workaround:

https://sourceforge.net/p/mingw/mingw-org-wsl/ci/617f15b16863cb5d542d1134e44e8fbd72739ad4/

If you are using the mingwrt-5.0 snapshot, either apply that patch, 
remake, and reinstall mingwrt, (or simply replace your installed copy 
of $HOME/mingw32/include/_mingw.h with the attached update [*]), then 
retry the stage-2 gcc build.

[*]: note that, if you simply replace the installed copy, that will 
cease to match your local source tree; applying the patch, and then 
rebuilding, is the more robust way to proceed).

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYsaepAAoJEMCtNsY0flo/J+AP/38ToYoeg8wqzTu49cRJsGXr
Emr9+VYKqKBbuHttpY7kmvAtFk/1dUn7Mlrzca8WxEj3//l6HeHdKpWkZxYogeYp
7gF8Zf2xRRiU+i/VJmIO2u969SmZ4aKF2G8E8D3DPu9JeUQzOBq6CNolxOg2zEzS
MvEe7/Ey7J6lB9X5PU23mPSYzESZkRPNZ7UjLa+Re3RxLq9EMSQcIY5v/7cDRRTF
+Y6P8ubte3ffiH66UOMzWuUbTYk3RSMk2Ip6a0jWd0WPg5rUlWFvf3/B7qtOiUAb
lG9aBTPlqcO6TS/e1mLyKZFC5kesDYZRwhTVpriiFjKJHtfi+ALUlrX7/I/kKdrV
AqsZSLNyW959mflzz0WrjPWmGLCSmMWw1YFdTBRZtW4DNx8HU11g9SZF7gNRY65+
jB5XTELHVKJOB0tmFQwt8TdMI9V/YMGIo0D7sGifI9xfLLnNrfVhtIHeT13tCz32
Bo7OHvjFBA0sB4+98P38DVRGTRnlTC/7uN7ODhRnhWhACG73obTTRp0BgAwH5JFM
DPpu4DLdcoqeXIiTErJPuAD/7a0tVZne7fcjRKtF+B8Xo32a87WSmZf2k5f+1aKW
+ZMBIQF22B0ebVR1hNjaK/WM28528VQEQGQCIQ5DYgs3UwK5RP9KSnM+W7M6tQbC
kdIEJp2f4dPng4Vjkz6/
=l/xS
-----END PGP SIGNATURE-----

MinGW Users,

System: Microsoft Windows XP Home Edition
CPUs: Intel(R) Atom(TM) CPU N270 @1.60GHz
Deps: HaskellPlatform-2014.2.0.0-i386-setup.exe
(includes MinGW32 w/ gcc-4.5.2)

Patches for hmatrix-0.16.1.5 are located here:

https://github.com/albertoruiz/hmatrix/pull/138/files
Fix windows support #125 #138

http://nurmi-labs.blogspot.com/2015/10/plot.html (see end of post)
plot

...

But after the patching attempting to run in ghci.exe the hmatrix-tests-0.4.1.0
> Numeric.LinearAlgebra.Tests.runTests 20

resulted in failure of the hmatrix-0.16.1.5 package to load, with the output
unknown symbol `_windows_random_r_errno'.

Here, I looked again at the subject, and wonder if anyone has suggestions on appending/modifying the

#if defined

statements in the patches.

http://nurmi-labs.blogspot.com/2017/02/patching-hmatrix.html
patching hmatrix

Sincerely,
Eric Lindblad

Thanks for Keith Marshall-3's patience!
As Keith Marshall-3 said, I done things wrong before!

Now I'm following steps and instructions above described by Keith
Marshall-3:
At the last step:

>Feb 24, 2017; 6:16am — by  Keith Marshall-3 Keith Marshall-3

>What you *should do*, at this point, is: 

>  $ cd ../gcc 
>  $ make all 
>  $ make install 

>to complete the stage-2 build, and final installation of the *cross* 
>compiler; (note that it will *not* be OpenMP enabled -- if you want to 
>pursue that aspect, we can follow up in a future post).  Also, if you 
>still want to pursue the use of the cross-compiler to create a native 
Windows gcc build, (and please explain why you think you need to do 
this, because it isn't at all clear why you think you might need it), 
we can follow up on that, later. 


The compiling process display a error and exit. The error message is:

make[4]: Entering directory
`/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include'
mkdir -p ./mingw32/bits/stdc++.h.gch
/home/www/mingw32-src/build/gcc/./gcc/xgcc -shared-libgcc
-B/home/www/mingw32-src/build/gcc/./gcc -nostdinc++
-L/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/src
-L/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/src/.libs
-L/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/libsupc++/.libs
-L/home/www/mingw32-src/build/gcc/mingw32/winsup/mingw
-L/home/www/mingw32-src/build/gcc/mingw32/winsup/w32api/lib -isystem
/home/www/mingw32-src/gcc-5.3.0/winsup/mingw/include -isystem
/home/www/mingw32-src/gcc-5.3.0/winsup/w32api/include
-B/home/www/mingw32/mingw32/bin/ -B/home/www/mingw32/mingw32/lib/ -isystem
/home/www/mingw32/mingw32/include -isystem
/home/www/mingw32/mingw32/sys-include    -x c++-header -nostdinc++ -g -O2 
-I/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/mingw32
-I/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include
-I/home/www/mingw32-src/gcc-5.3.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/home/www/mingw32-src/gcc-5.3.0/libstdc++-v3/include/precompiled/stdc++.h \
	-o mingw32/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/string:52:0,
                 from
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/bits/locale_classes.h:40,
                 from
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/bits/ios_base.h:41,
                 from
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/ios:42,
                 from
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/istream:38,
                 from
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/sstream:38,
                 from
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/complex:45,
                 from
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/ccomplex:38,
                 from
/home/www/mingw32-src/gcc-5.3.0/libstdc++-v3/include/precompiled/stdc++.h:52:
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/bits/basic_string.h:
In function 'float std::__cxx11::stof(const wstring&, std::size_t*)':
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/bits/basic_string.h:5390:31:
error: 'wcstof' is not a member of 'std'
   { return __gnu_cxx::__stoa(&std::wcstof, "stof", __str.c_str(), __idx); }
                               ^
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/bits/basic_string.h:5390:31:
note: suggested alternative:
In file included from
/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include/cstdlib:72:0,
                 from
/home/www/mingw32-src/gcc-5.3.0/libstdc++-v3/include/precompiled/stdc++.h:47:
/home/www/mingw32/mingw/include/stdlib.h:407:7: note:   'wcstof'
 float wcstof (const wchar_t *__restrict__, wchar_t **__restrict__);
       ^
make[4]: *** [mingw32/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
make[4]: Leaving directory
`/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3/include'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home/www/mingw32-src/build/gcc/mingw32/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/home/www/mingw32-src/build/gcc'
make: *** [all] Error 2


I tried to add CFLAGS="-g -O2 -std=gnu99" to the end of configure but the
error still exist: 
../../gcc-5.3.0/configure --prefix=/home/www/mingw32
--with-sysroot=/home/www/mingw32 --target=mingw32 --with-arch=i586
--with-tune=generic --enable-shared --enable-threads
--disable-win32-registry -disable-sjlj-exceptions --disable-multilib
--disable-nls --disable-libvtv --with-dwarf2 target_alias=mingw32
--enable-languages=c,c++,lto --no-create --no-recursion CFLAGS="-g -O2
-std=gnu99"

How do I fix this problem?

Best Regards!
Wang LingJun



--
View this message in context: http://mingw.5.n7.nabble.com/SPAM-I-m-a-newbie-to-MinGW-How-Can-I-build-MinGW-from-source-tp35651p35680.html
Sent from the MinGW - User mailing list archive at Nabble.com.

Dear Keith,

I must have missed the announcement.

I haven't compiled on windows lately (I once compile Amarok long ago), thus
I ask:

Are there some (manual) test cases you'd recommend?


If yes, should I simply install mingw with the latest installer and then
manually replace all files from
https://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/mingwrt-5.0/
and
https://sourceforge.net/projects/mingw/files/MinGW/Base/w32api/w32api-5.0/
and then compile something of which I know that it used to work
(suggestions)?

On 24 February 2017 at 14:49, Keith Marshall <
kei...@us...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Folks,
>
> Almost two weeks ago, I invited you to test pre-release snapshots of the
> proposed version 5.0 releases of these two package sets.  Vadim Zeitlin
> has kindly done so, in conjunction with his builds of wxWidgets, and has
> identified one minor issue, (which arises due to an upstream GCC bug; I
> have identified a workaround, to be included in the final release).
>
> Since I posted the snapshots, the download statistics, as reported by SF,
> have been rather disappointing.  I would like to get these two package
> sets formally released by the end of February, and I'm interpreting the
> general apathy, and absence of feed back, as tacit approval for the code
> base, as it currently stands.  If you have any concerns about this code,
> and its suitability for formal release, you had best act quickly to let
> me know.
>
> - --
> Regards,
> Keith.
>
> Public key available from keys.gnupg.net
> Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.20 (GNU/Linux)
>
> iQIcBAEBAgAGBQJYsDn8AAoJEMCtNsY0flo/kFMP/ibuSVb7CSZJTv4pFaxG+AWo
> 9ZY/pAmb1Cw+vX7E7v/r6JlXwL/BYpaVIY6FE05T7oZLy/uo84F4h3NN6gKXh62P
> dkHTmesT3Z2cyLDzX2tvvZnWctl9tpFGlY5LfngdNAazoj4n9zPw4Y6UsVjdUQqW
> yFOHcgkUf/gzdQdtbxkWMAY+nErGQNxEqP9qEH6ZsoU2OudW+2b3p6/pgsDCnLHJ
> P+aD/Z8+h2syhvMspFYtVd0reHMR8kiGpCwPq5RVMgl7LLuil8h59sSrnchc8avp
> Oty1DarohbOIeB9C0pvpQuppZ9v+KqIZUFuasVy29AOmyvwU6GNWWsQDMMVJw0lj
> tYi/tPHIAP8d5tp8v+VQu70f0BaLFM5ai91V7uYfI3qXWtL8A+zddIlZZx9ocFIg
> Lq4Oenb8Q0DPe106Akn40GfKm4m+oWIw1gBWvDGGcdTKY3OSehvUzv2gn64OHY1e
> dcO7f/MoC0TUYSX+UumMKIQKnnyT194ZEssziQnTOyTskCUBB2VQs0+IGRI40Y+Q
> xuKTYwmEVrJ7DEBO1Kqe/g2ZcCZYm/J4JHplnYgCBDSV1FnBysSDYlmqSsh36L1O
> 5Xx9M3WV5lbclxiWACgtVCkdEZC90crAK3SRXkYVhghD19NNu6FaYwuyYyt6Yxav
> RUsjuWA9/b77nRFo+nqa
> =bqxp
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Folks,

Almost two weeks ago, I invited you to test pre-release snapshots of the 
proposed version 5.0 releases of these two package sets.  Vadim Zeitlin has kindly done so, in conjunction with his builds of wxWidgets, and has 
identified one minor issue, (which arises due to an upstream GCC bug; I 
have identified a workaround, to be included in the final release).

Since I posted the snapshots, the download statistics, as reported by SF, 
have been rather disappointing.  I would like to get these two package 
sets formally released by the end of February, and I'm interpreting the 
general apathy, and absence of feed back, as tacit approval for the code 
base, as it currently stands.  If you have any concerns about this code,
and its suitability for formal release, you had best act quickly to let 
me know.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYsDn8AAoJEMCtNsY0flo/kFMP/ibuSVb7CSZJTv4pFaxG+AWo
9ZY/pAmb1Cw+vX7E7v/r6JlXwL/BYpaVIY6FE05T7oZLy/uo84F4h3NN6gKXh62P
dkHTmesT3Z2cyLDzX2tvvZnWctl9tpFGlY5LfngdNAazoj4n9zPw4Y6UsVjdUQqW
yFOHcgkUf/gzdQdtbxkWMAY+nErGQNxEqP9qEH6ZsoU2OudW+2b3p6/pgsDCnLHJ
P+aD/Z8+h2syhvMspFYtVd0reHMR8kiGpCwPq5RVMgl7LLuil8h59sSrnchc8avp
Oty1DarohbOIeB9C0pvpQuppZ9v+KqIZUFuasVy29AOmyvwU6GNWWsQDMMVJw0lj
tYi/tPHIAP8d5tp8v+VQu70f0BaLFM5ai91V7uYfI3qXWtL8A+zddIlZZx9ocFIg
Lq4Oenb8Q0DPe106Akn40GfKm4m+oWIw1gBWvDGGcdTKY3OSehvUzv2gn64OHY1e
dcO7f/MoC0TUYSX+UumMKIQKnnyT194ZEssziQnTOyTskCUBB2VQs0+IGRI40Y+Q
xuKTYwmEVrJ7DEBO1Kqe/g2ZcCZYm/J4JHplnYgCBDSV1FnBysSDYlmqSsh36L1O
5Xx9M3WV5lbclxiWACgtVCkdEZC90crAK3SRXkYVhghD19NNu6FaYwuyYyt6Yxav
RUsjuWA9/b77nRFo+nqa
=bqxp
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/02/17 02:23, Ranger wrote:
> My build OS: ubuntu 14
> gcc version: 4.9

FWIW, I'm on LinuxMint Debian Edition, with gcc-4.8.2 as host compiler;
a bit older than yours, but that shouldn't matter.

> Note: my login account: www 

If you always refer to your home directory as $HOME, that's irrelevant.

> How do fix the error in gcc rebuild?
> 
> I follow steps in Keith Marshall-3's reply for "Problem with
> configure when trying to build gcc 5.3":

Well, you didn't follow them religiously :-)

> 1.downloaded source code
> binutils-2.25.1-1-mingw32-src.tar.xz
> mingwrt-3.22.4-mingw32-src.tar.xz
> w32api-3.18.2-mingw32-src.tar.xz
> gcc-5.3.0-3-mingw32-src.tar.xz

Okay, I reviewed (and repeated) my build procedure, (to remind myself 
what I did, and to check that I hadn't overlooked anything).  I used:

- - binutils-2.26 (from a GNU distribution mirror)
- - gcc-5.3.0 (as distributed by MinGW.org, with our patches applied)
- - mingwrt-5.0 preview snapshot, as posted 2017-02-12
- - w32api-5.0 preview snapshot (likewise)

> 2.mkdir /home/www/mingw32-src
>   mkdir /home/www/mingw32
>   cd /home/www/mingw32-src

I used a slight modification of this:

  $ mkdir -p $HOME/mingw32-src/build/{binutils,gcc,mingwrt,w32api}
  $ cd mingw32-src

then unpacked the mingwrt and w32api tarballs; (for gcc and binutils, 
I created symbolic links to previously unpacked working copies, which
I happened to have elsewhere within my file system).

> 3.mingwrt:
> untar mingwrt-3.22.4-mingw32-src.tar.xz in /home/www/mingw32-src and
> get mingwrt-3.22.4 folder
> cd /home/www/mingw32-src/mingwrt3.22.4
> ./configure --prefix=/home/www/mingw32

You don't say how you established the $HOME/mingw32 directory, into
which this will install; rather than leaving this...

> make install-headers

...to establish it by default, (and overwrite anything which may be
there already), I prefer to do something like, (with knowledge that
$HOME/mingw32-gcc-sandbox definitely doesn't exist beforehand):

  $ mkdir $HOME/mingw32-gcc-sandbox
  $ (cd $HOME && ln -fs mingw32-gcc-sandbox mingw32)
  $ (cd $HOME/mingw32 && ln -s . mingw)

and ensure that $HOME/mingw32/bin is included at or near the end of 
$PATH; (I have this set in $HOME/.profile):

  test -d $HOME/mingw32/bin && PATH=$PATH:$HOME/mingw32/bin

This allows me to have multiple side-by-side installations, (different 
versions, or alternative experimental builds), and switch between them
by the simple expedient of remapping one symbolic link.

With that all set up, then you should configure fully:

  $ cd build/mingwrt
  $ ../../mingwrt-5.0/configure --build=unknown --host=mingw32 \
     --prefix=$HOME/mingw32
  $ make install-headers

> 4.w32api:
> untar w32api-3.18.2-mingw32-src.tar.xz in  /home/www/mingw32-src and
> get w32api-3.18.2 folder
> cd /home/www/mingw32-src/w32api-3.18.2
> ./configure --prefix=/home/www/mingw32
> make install-headers

Likewise, you should configure fully:

  $ cd ../w32api
  $ ../../w32api-5.0/configure --build=unknown --host=mingw32 \
     --prefix=$HOME/mingw32
  $ make install-headers

> 5.GNU binutils:
> untar binutils-2.25.1-1-mingw32-src.tar.xz in /home/www/mingw32-src
> and get binutils-2.25.1 folder
> cd /homw/www/mingw32-src/binutils-2.25.1
> mkdir build
> cd build  (pwd is /home/www/mingw32-src/binutils-2.25.1/build)
> ../configure --prefix=/home/www/mingw32 \
>  --with-sysroot=/home/www/mingw32 --target=mingw32
> make
> make install

That looks okay; I did it mostly the same:

  $ cd ../binutils
  $ ../../binutils-2.26/configure --target=mingw32 \
     --{prefix,with-sysroot}=$HOME/mingw32 --disable-nls
  $ make && make install

> 6.Symbolically link:
> cd /home/www/mingw32
> ln -s /home/www/mingw32 mingw

Again, looks okay, (although I prefer the 'ln -s . mingw' format).

> 7.Prepare GCC source:
> untar gcc-5.3.0-3-mingw32-src.tar.xz in /home/www/mingw32-src and get
> gcc-5.3.0 folder

Okay, but your next step seems kind of pointless:

> cd /home/www/mingw32-src
> mkdir src
> mv gcc-5.3.0 src
> cd src/gcc-5.3.0 (pwd is /home/www/mingw32-src/src/gcc-5.3.0 )

(You can just as well leave the source at $HOME/mingw32-src/gcc-5.3.0).

> ./contrib/download_prerequisites

I didn't use this; I manually downloaded gmp, mpfr, and mpc, unpacked
all of them in $HOME/mingw32-src, then:

  $ cd $HOME/mingw32-src/gcc-5.3.0
  $ ln -s ../gmp-6.1.0 gmp
  $ ln -s ../mpfr-3.1.3 mpfr
  $ ln -s ../mpc-1.0.2 mpc

Then, while you're here, and before you proceed any further, you should 
apply the MinGW.org patches, (which are delivered in the MinGW source 
tarball, along with *unpatched* original GCC source); if you installed
mingw-pkg, then the easiest way to do this is:

  $ mingw-pkg patch

otherwise, you could do it like this:

  $ (for p in arch/mingw32/*.patch; do patch -p1 < $p; done)

> 8.Build GCC:
> cd /home/www/mingw32-src
> mkdir build
> cd build     (pwd is /home/www/mingw32-src/build)
> ../src/gcc-5.3.0/configure --prefix=/home/www/mingw32 \
>  --with-sysroot=/home/www/mingw32

Once again, you should configure it fully:

  $ cd $HOME/mingw32-src/build/gcc
  $ ../../gcc-5.3.0/configure --{prefix,with-sysroot}=$HOME/mingw32 \
     --target=mingw32 --with-arch=i586 --with-tune=generic \
     --enable-shared --enable-threads --disable-win32-registry \
     --disable-sjlj-exceptions --disable-multilib --disable-nls \
     --disable-libvtv --with-dwarf2 --enable-languages=c,c++
  $ make all-gcc && make install-gcc

> make all-gcc (here has a error: can't find
> /home/www/mingw32/usr/include.

Likely a consequence of your incomplete configuration; when configured 
as I've indicated, I see no such problem...

> I mkdir this path and rebuild successfully)

...and here, rather than eliminating the cause of the problem, you've 
kludged around a symptom of it, likely leaving further consequences to 
surface later.

> make install-gcc

Yes, but what is it installing, and where?  Since it wasn't properly 
configured, it's likely as useful as a chocolate teapot.

At this point, I would like to throw in a caveat, of which I have been 
reminded on working through the procedure again: even if you ultimately 
aim to create an OpenMP enabled cross-compiler, you should *not* add 
the '--enable-libgomp' configuration option at this stage.  If you do, 
you will not be able to complete the stage-2 gcc build, without having 
installed pthreads support, and you will not be able to compile that 
pthreads support until after you have completed the stage-2 gcc build.

> At present, I finish building cross compiler.

No, you haven't; you've merely completed the stage-1 gcc build and 
installed it into $HOME/mingw32.  Before you go any further, you
should confirm that it is accessible via $PATH, and is working:

  $ which mingw32-gcc
  /home/keith/mingw32/bin/mingw32-gcc

  $ mingw32-gcc --version
  mingw32-gcc (GCC) 5.3.0
  Copyright (C) 2015 Free Software Foundation, Inc.
  ...

> Next,I'll start to build second pass.

You're not ready to do that yet!  Your next step *must* be to go back 
to mingwrt, and to w32api, to build and install the runtime libraries;
without them, the stage-2 gcc build will fail; (indeed, it's to give 
you an opportunity to install these, that the gcc build is segregated 
into two separate stages):

  $ cd ../mingwrt
  $ ./config.status --recheck
  $ ./config.status
  $ make
  $ make install

  $ cd ../w32api
  $ ./config.status --recheck
  $ ./config.status
  $ make
  $ make install

Now, you're ready to proceed with the stage-2 gcc build; however...

> 9. Prepare GCC source again:
> untar gcc-5.3.0-3-mingw32-src.tar.xz in /home/www/mingw32-src and get
> gcc-5.3.0 folder again
> cd /home/www/mingw32-src
> mkdir srcx
> mv gcc-5.3.0 srcx
> cd srcx/gcc-5.3.0 (pwd is /home/www/mingw32-src/srcx/gcc-5.3.0 )
> ./contrib/download_prerequisites

...this is utterly futile, and together with this...

> 10.Build GCC again:
> cd /home/ww/mingw32-src
> mkdir buildx
> cd buildx        (pwd is /home/www/mingw32-src/buildx)
> mingw-pkg SRCDIR=../srcx/gcc-5.3.0 patch
> ../srcx/gcc-5.3.0/configure --prefix=/mingw --disable-win32-registry \
>   --target=mingw32 --with-arch=i586 --enable-languages=c,c++ \
>   --enable-static --enable-shared --enable-threads --with-dwarf2 \
>   --disable-sjlj-exceptions --enable-version-specific-runtime-libs \
>   --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw \
>   --enable-libstdcxx-debug --with-tune=generic --enable-libgomp \
>   --disable-libvtv --enable-nls

...is entirely wrong!  (I don't mean because you've chosen different 
options to those that I did; for you, your choice may be appropriate.  
However, your --prefix is definitely wrong -- should be the same as
you used in the stage-1 build -- and --with-sysroot is required, but 
conspicuously absent.  Also, I'd question your references to /mingw;
does your Ubuntu box have any such directory?)

What you *should do*, at this point, is:

  $ cd ../gcc
  $ make all
  $ make install

to complete the stage-2 build, and final installation of the *cross* 
compiler; (note that it will *not* be OpenMP enabled -- if you want to 
pursue that aspect, we can follow up in a future post).  Also, if you 
still want to pursue the use of the cross-compiler to create a native 
Windows gcc build, (and please explain why you think you need to do 
this, because it isn't at all clear why you think you might need it), 
we can follow up on that, later.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYr18pAAoJEMCtNsY0flo/9YgP/0mkgbaNCD8TuW8cCpwI46mG
SqXbEX1MNCL6TAalXSwtyOJbfwWRnO39JCtxokr/SbYxVwnnvSyMFok3rztld/H2
nwjA7gJmY0iEZE2dx6PrHf9x1BgklChLTgCt+C0zZokFou0qVznEr1uvrlGQt4Jj
EwePzbwDX6mBH1pjD4QIdPwC6a0Jweu/K1tsrGnULSbtYSl/rRgXTW8/JXCZ49aW
Q5aqLPq8hsarKxB88oOHQf4+qI91LyNPiula5/J4JyOXKgBCbhV6iBoMBXrkLAhs
sMB5Lpcd7DRLKtOski44WwYuc8/HwckhZsEAUMR4yKN9uaLT7TS4nsQwOTcI6Q8L
UEODQOz1YDKiVdvVXMGmFsQLCLScnXYnVqbb3TGmOu0W2bjtVOot8sMThNLG8mRz
4GVDWKjp79Du05A1Qufqmbx14LBkOgD814+9kXDXOWziE/19BzONK8hQxKyIMp7B
ni7Dg+6e3fN5ZwGT4R0NrwK2juPRUuxJ7JE/nR3YMr9w0fsbox9MC7ZxEecLgtEX
1zA9MBkypDpPmSCN2sxvImqiKM8jUFyMUojC9dzLRwQKKm+RU5IhdPt8QFoZcvoH
Jr5Ci0nPS+CwdNABwmkoWmW0NyvZj5zT4Xjt3HF7JQkzZ5NuUZH5XRqrFpQBwp3I
b8Y6XBpvkSp2d0yzjbYP
=NNlX
-----END PGP SIGNATURE-----