Quantcast

Problem with configure when trying to build gcc 5.3

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Problem with configure when trying to build gcc 5.3

David Gressett-5
I got mingw-pkg installed and started working on gcc 5.3.0

I immediately found a problem when mingw-pkg did a configure.
It did not configure to build the Ada compiler. I found nothing obvious
that would explain this in config.log, so I went to the MinGW installer
to see if I had anything missing and found that the mingw-gnat dll is
still at version 4.8.1-4 and the repository version number is
also 4.8.1-4.

I have only built one Ada program since I upgraded to gcc 5.3.0,
and it compiles and runs with no problems, but this does look a bit
odd, and I suspect that the gcc configure may be  more demanding
about runtime library compatibility than my little program is.

There was also a 4.8.1-4 version number on the
mingw32-gcc-ada info file.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30/12/16 02:23, David Gressett wrote:
> I immediately found a problem when mingw-pkg did a configure.
> It did not configure to build the Ada compiler. I found nothing obvious
> that would explain this in config.log, so I went to the MinGW installer
> to see if I had anything missing and found that the mingw-gnat dll is
> still at version 4.8.1-4 and the repository version number is
> also 4.8.1-4.

I *think* the libgnat-dll version thing is a red herring; ada builds
fine for me, but libgnat.a is built as a static library only -- I can
find no way to create a corresponding DLL, (short of brute force, by
extracting and linking all of the objects from libgnat.a, which I
didn't bother to try).

For me, ada is a completely alien world, and I simply don't have the
inclination to devote either time or energy to debugging its quirky
build system.  If you are willing to pursue it, I'll assist as best
I can, but I have no ada expertise to offer.

- --
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)

iQIcBAEBAgAGBQJYZjSlAAoJEMCtNsY0flo/mhMQAJS5I5zWIHupnFcbJEy0lIvA
0Q/pqDm/84DffdLw8R3A0Q6Pc7zT++Kwsvm0YAmKD/XxTk4gFyOGFMmdFb76GBxh
F6NJLVZmCuhOZII4NgdvfPYgCgC7GjrBhyxZ3LLMCxBS+U8oZXzqSYOU02s5b59t
IXt79BUsOynH+kapKfgBi4NhINkSopGXnaxRFaPticiF3mXqDU9TJj7pkaaRSKZH
YQHV0qOWE8kRWrxSr6K3dbJgmmKiU9vT/UMy7dtmtlj4M9Mecjla1eV5xeNLgGzx
JfTG2qbqDFoY45rxOy9s39vejGW0a1BpmQE9I60uJ3r/IxBH9XV/WZiKqYuMj6IJ
v9JoGMi3xSgXS1MTmZYGCvk2y5aeYTE5Xzy2ctxm5FTjASNg/wiYlqd/fXRhHkmc
8V0Vbr67gq+0LP2I0XUmuWflm9VRlIjaAJLUt3A4Lac3HZaGcz2wM5l66lGuBAiG
DJGPbsUaknunL+uBxxShTCXEsNZRsQS5HlNIC7OCyiMWaBCL8cKddcoJ8sIczq3/
b2+UU1gaQPzXM51zRpGLEGQACU92gktUN8uS/fulIf757mA3pt8xwR5ZxxUsRA87
/IQRH33P8QxdP/k3S/AHC2gNTqDwOyGPJeodzOZVUtNFyqZZrT4b0N5qDOJb1paq
KbpAvqVNwANXjG54vc4d
=DU1z
-----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-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

David Gressett-5
>On 30/12/16 02:23, David Gressett wrote:
>> I immediately found a problem when mingw-pkg did a configure.
>> It did not configure to build the Ada compiler. I found nothing obvious
>> that would explain this in config.log, so I went to the MinGW installer
>> to see if I had anything missing and found that the mingw-gnat dll is
>> still at version 4.8.1-4 and the repository version number is
>> also 4.8.1-4.

>I *think* the libgnat-dll version thing is a red herring; ada builds
>fine for me, but libgnat.a is built as a static library only -- I can
>find no way to create a corresponding DLL, (short of brute force, by
>extracting and linking all of the objects from libgnat.a, which I
>didn't bother to try).

>For me, ada is a completely alien world, and I simply don't have the
>inclination to devote either time or energy to debugging its quirky
>build system.  If you are willing to pursue it, I'll assist as best
>I can, but I have no ada expertise to offer.

I have now learned a bit more.

my first problem became visible when I used mingw-pkg to
do the configure stage of the gcc build. configure displayed this:

"The following languages will be built: c,c++,fortran,java,lto,objc"

I did not get Ada, which i did expect, and got java, which I did
not expect and was not configured in the pkgspec file. The objective-c
languages also dropped out.

I examined the config.log and found the command line that was
used to run the gcc configure.

I found a problem; it contained --build=x86_64-pc-linux-gnu
instead of the expected -build=mingw32

I have a copy of .mingw-pkgrc in both my $HOME
directory and the gcc build directory. I had constructed it
by modifying the one that you included as an attachment
by changing the build line to this:

build=${build-"mingw32"}

It seems that mingw-pkg ignored .mingw-pkgrc.

I then removed the results of the configure step and
reconfigured it using by directly issuing the configure
command line to see if it the problem would go away:

../../src/gcc-5.3.0/configure --build=mingw32 --host=mingw32 , etc

It did go away - I saw this:

"The following languages will be built: c,ada,c++,fortran,lto,objc,obj-c++"

I am now using mingw-pkg to run the compile step.  It failed  
when it got to Ada, with a problem in adaint.c

"error: 'fstat64' was not declared in this scope."

That looks to me like a patch failure, as one of the patch files
deals with fstat64.

It appears that mingw-pkg is behaving badly in msys on my Windows 10
computer.  My next step is to avoid mingw-pkg and do all the patching
and configuration manually.







------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/01/17 22:15, David Gressett wrote:
> I found a problem; it contained --build=x86_64-pc-linux-gnu

- From whence is it picking that up?  For me, that comes from my
$HOME/.mingw-pkgrc; it should not be defined otherwise.

> instead of the expected -build=mingw32

Why is this expected?  If your $build == $host, (as would be the
norm for a native build), your configure line should (ideally)
not specify either --build or --host.

> I have a copy of .mingw-pkgrc in both my $HOME directory and
> the gcc build directory.

Well, that's just plain wrong; if you need it at all, (which you
may not, unless you have a burning desire to customize something),
then it belongs in $HOME, and nowhere else.

> It appears that mingw-pkg is behaving badly in msys on my
> Windows 10 computer.  My next step is to avoid mingw-pkg and
> do all the patching and configuration manually.

Well, okay as an interim measure, but we really need to debug this.
Did you run 'mingw-pkg patch'?  In the source or the build tree?
If so, what was its (console) output?

- --
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)

iQIcBAEBAgAGBQJYaYlSAAoJEMCtNsY0flo/2kEQAMeHeeUGlv2y0p7onCd2cjj9
65QahKxvkYb2nfismz7AYnqQadD2oiXkPqyBrOuhx7pGru26uS+pHlCh72DmOXJA
xlrnEWDpzoknP65tV+N7goKpvdkAp6j1RPv7g6yDBxLHoWuCmdTqZH552K71nvob
nMi0xyEqOXvAUtlub9p52PiQ45PnbXak2EchrOUUQgXlwzU25l58locHcClyCIeM
DmYvxLkBVb+VYxdL/1TsjQnBPXWNHhLz3cNCiCoBkpsL4kyAPcZ4XghxE5HQkHOa
IUSavfYSKApwE6e5k5sMU6AYIF4REgzcQxYDPSTuSg1NXdnAm05lLwUL4SsN8gCP
o7bLYH3hIznC9OWfyii2tqHd9aE35cFypylIylaEzLj4kUlQ7eBvvlk1M3s4CNfA
AlyDCgIIT4m7kxwndewEWwPYOmzaP+QJGbZxHc4KLdSW1A3Wl7/dq8M1pFC1LIBu
CM0hF/kQ9SuWr/pa6k6ibvBMiWz6rIEK6enIjoODy7hMXER+ZwneYQN/KyHqtaqF
UInkVHhpMr8IO79PpU5gVzjDBjGtWmFtFBnp0+m7b4h7vACLxOAuJAW1aybvGdb9
pWSe3Kgs7dYjGmkqi+51CA2QCwzpLpZ86KhavsZfhMfDsbz50D26/5dwaEGyoV/b
Gi0ICqmkbWIKDOd4wOoB
=8gDU
-----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-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

David Gressett-5

From: Keith Marshall <[hidden email]>
Sent: Sunday, January 1, 2017 4:57 PM

>On 01/01/17 22:15, David Gressett wrote:
>> I found a problem; it contained --build=x86_64-pc-linux-gnu

>- From whence is it picking that up?  For me, that comes from my
>$HOME/.mingw-pkgrc; it should not be defined otherwise.

>> instead of the expected -build=mingw32

>Why is this expected?  If your $build == $host, (as would be the
>norm for a native build), your configure line should (ideally)
>not specify either --build or --host.

>> I have a copy of .mingw-pkgrc in both my $HOME directory and
>> the gcc build directory.

>Well, that's just plain wrong; if you need it at all, (which you
>may not, unless you have a burning desire to customize something),
>then it belongs in $HOME, and nowhere else.

>> It appears that mingw-pkg is behaving badly in msys on my
>> Windows 10 computer.  My next step is to avoid mingw-pkg and
>> do all the patching and configuration manually.

>Well, okay as an interim measure, but we really need to debug this.
>Did you run 'mingw-pkg patch'?  In the source or the build tree?
>If so, what was its (console) output?

I ran it as you specified in you message in the MinGW list:
$ cd $HOME/build/gcc-5.3.0-mingw32
$ mingw-pkg SRCDIR=../../src/gcc-5.3.0 patch

For my next attempt, I removed both copies of
.mingw-pkgrc., deleted all the remains of the previous
attempt from my build directory and did the patch
and configure steps again.

This time, I used tee to save the console display and
stayed to watch the patch step.

$ mingw-pkg SRCDIR=../../src/gcc-5.3.0 patch | tee ../mingw-pkg-patch.log

the console showed this:

>>> apply patches


>>> done.

It completed so quickly that it is obvious that it really did no patches,
rather than suppressing or redirecting any console output.

I then did the configure:
$ mingw-pkg SRCDIR=../../src/gcc-5.3.0 configure | tee ../mingw-pkg-configure.log

The configure step produced exactly the same results as my previous
configure, even though there was no .mingw-pkgrc:  The console display
still announced that it would build java but not ada and the configure
command line still contained  --build=x86_64-pc-linux-gnu.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/01/17 14:24, David Gressett wrote:
>> Well, okay as an interim measure, but we really need to debug this.
>> Did you run 'mingw-pkg patch'?  In the source or the build tree?
>> If so, what was its (console) output?
>
> I ran it as you specified in you message in the MinGW list:
> $ cd $HOME/build/gcc-5.3.0-mingw32
> $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 patch

Right.  The CWD *must* be set to the top of the source tree while
applying patches; the 'mingw-pkg patch' command *should* use your
specified SRCDIR, to make that so, but ...

> For my next attempt, I removed both copies of
> .mingw-pkgrc., deleted all the remains of the previous
> attempt from my build directory and did the patch
> and configure steps again.
>
> This time, I used tee to save the console display and
> stayed to watch the patch step.
>
> $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 patch | tee ../mingw-pkg-patch.log
>
> the console showed this:
>
>>>> apply patches
>
>
>>>> done.

... this suggests that it didn't; it should have looked like:

|  $ mingw-pkg SRCDIR=../gcc-5.3.0 patch
|
|  >>> apply patches
|
|  >>> applying patch: arch/mingw32/01-mingw-w64-brain-damage.patch
|  patching file gcc/config/i386/mingw32.h
|  >>> applying patch: arch/mingw32/02-mingw32-float.h.patch
|  patching file gcc/ginclude/float.h
|  >>> applying patch: arch/mingw32/03-ada-largefile.patch
|  patching file gcc/ada/adaint.c
|  patching file gcc/ada/adaint.h
|  patching file gcc/ada/cstreams.c
|  >>> applying patch: arch/mingw32/04-eh-frame-begin.patch
|  patching file libgcc/config/i386/cygming-crtbegin.c
|  >>> applying patch: arch/mingw32/05-fortran-strings.patch
|  patching file libgfortran/intrinsics/selected_char_kind.c
|  patching file libgfortran/runtime/environ.c
|  patching file libgfortran/runtime/string.c
|  >>> applying patch: arch/mingw32/06-ssp-wincrypt.patch
|  patching file libssp/ssp.c
|
|  >>> done.

> It completed so quickly that it is obvious that it really did no
> patches,

I doubt if it even found the patch files, relative to the CWD in
the build tree.  The script fragment which deals with patches is
missing a 'cd $SRCDIR' command; I can fix that ... in fact, I've
already done so in my local code base, to get the above output.

> rather than suppressing or redirecting any console output.
>
> I then did the configure:
> $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 configure | tee ../mingw-pkg-configure.log
>
> The configure step produced exactly the same results as my previous
> configure, even though there was no .mingw-pkgrc:  The console display
> still announced that it would build java but not ada and the configure
> command line still contained  --build=x86_64-pc-linux-gnu.

Well, it's getting that from somewhere, (and the only place it
should be able to find it is $HOME/.mingw-pkgrc); FWIW, if I run
the 'mingw-pkg configure' command in MSYS, as:

  $ sh -vx `which mingw-pkg` SRCDIR=../gcc-5.3.0 configure 2>&1

(and capture output via 'tee'), I see:

| checking build system type... i686-pc-mingw32
| checking host system type... i686-pc-mingw32
| checking target system type... i686-pc-mingw32

so $build is *not* being set by --build=x86_64-pc-linux-gnu, (or
by an other explicit option), but is correctly auto-detected as
i686-pc-mingw32, (which is as it should be).  However, I'm also
seeing no evidence of *any* configure options be read from the
package specification file ... indeed, I'm seeing evidence of an
MSYS shell bug, which prevents mingw-pkg from even locating the
package specification file:

|  # Ensure we have a PACKAGE name specification; if not, attempt to deduce
|  # a suitable default from the name of the top-level source code directory.
|  #
|    pkgspec_from_srcdir(){
|      pkgspec_$1 $PACKAGE_ABS_SRCDIR
|    }
|    pkgspec_get_name(){
|      IFS=-; set -- `basename "$1"`; value= IFS=
|      for part
|        do case $part in [0-9]*) break;;
|             *) value="$value$IFS$part" IFS=-;;
|           esac
|        done
|      echo "$value"
|    }
|    PACKAGE=${PACKAGE-"`pkgspec_from_srcdir get_name`"}
|  pkgspec_from_srcdir get_name
|  +++ pkgspec_from_srcdir get_name
|  +++ pkgspec_get_name /home/keith/gcc-5.3.0
|  +++ IFS=-
|  basename "$1"
|  ++++ basename /home/keith/gcc-5.3.0
|  +++ set -- gcc 5.3.0
|  +++ value=
|  +++ IFS=
|  +++ for part in '"$@"'
|  +++ case $part in
|  +++ value=gcc
|  +++ IFS=-
|  +++ for part in '"$@"'
|  +++ case $part in
|  +++ value=gcc-5.3.0
|  +++ IFS=-
|  +++ echo gcc-5.3.0
|  ++ PACKAGE=gcc-5.3.0
|    test "x$PACKAGE" = x && PACKAGE='<package>'
|  ++ test xgcc-5.3.0 = x

Notice that it has failed to match the 'case [0-9]*)' pattern, as it
should have, and consequently, has set 'PACKAGE=gcc-5.3.0', where it
should have been just 'PACKAGE=gcc'; contrast the above with correct
behaviour, when run using the dash shell, on my Linux box:

|  # Ensure we have a PACKAGE name specification; if not, attempt to deduce
|  # a suitable default from the name of the top-level source code directory.
|  #
|    pkgspec_from_srcdir(){
|      pkgspec_$1 $PACKAGE_ABS_SRCDIR
|    }
|    pkgspec_get_name(){
|      IFS=-; set -- `basename "$1"`; value= IFS=
|      for part
|        do case $part in [0-9]*) break;;
|             *) value="$value$IFS$part" IFS=-;;
|           esac
|        done
|      echo "$value"
|    }
|    PACKAGE=${PACKAGE-"`pkgspec_from_srcdir get_name`"}
|  + pkgspec_from_srcdir get_name
|  + pkgspec_get_name /home/keith/src/mingw/gcc-build/src/gcc-5.3.0
|  + IFS=-
|  + basename /home/keith/src/mingw/gcc-build/src/gcc-5.3.0
|  + set -- gcc 5.3.0
|  + value= IFS=
|  + value=gcc IFS=-
|  + break
|  + echo gcc
|  + PACKAGE=gcc
|    test "x$PACKAGE" = x && PACKAGE='<package>'
|  + test xgcc = x

(Do note that this is not an MSYS specific bug; if I substitute
bash for dash, on the Linux box, I see the same mishandling of the
case pattern; I'll have to explore possible work arounds).

- --
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)

iQIcBAEBAgAGBQJYbDVVAAoJEMCtNsY0flo/xwEP/j/TDHNlnAB44qjaSwbIYTmH
GMOU2E6j9iML5oU+m01U2KYqYw33JnOcIr8DdafmMrhmaOIzsRPVRM9ZuQ5fYoKo
gluts7Dv1ZPr24UaQwpgSg8ELVFHO6jubHEYbkkijlza47SA/3ow7PVvk1S6Ar68
7cZYIRMsUbz15HYmeS5Jkn9OfWLhW0TW2yOmqM1FHLb8C8gHZxtDPyb3u0z+C1YF
ZmV2JUoS50ybZZprTLsv6Gc6UhnmEA5MIAtV0KA1gCQxWCZqJukNrG/B5gNUZQeI
6vbBWTcsjwZLkr7aot9tG2XMBS4ChoKxnLGDHFw69ZTuvmGM5TiufafPEen+uWYC
8KQChf3SYvVpN8sO6BVOi9O7l3/5CEcfYNiurTajK7Mn0BNyBfWRNbaU2ambs8Ty
kIkQLBMptdMb7pyAsA6kUSBaIJrQ2MKhjtU9eJYV+cWtHNk/ov3/MArgO2wsjYSm
oix87xYzEBgw+SauooDBuFph4iW+D7akpcJHEdILrJUZ7/wD0OBvA2fB8A1WRVVx
F7rL0aAVlFXdGqRLupoaG3BpdAo3Zn2bYPtGrR1z5pcJUOhcm+ikhF5WI2BsYhl5
hIoXnkhQuLOTeul9uW5gr5Co8yEZbHhc3qYIHOXT/MPF1Po8Z800dXB4VG7oTZwc
xtr2p98+JjxeyvH1f3Cv
=W8m0
-----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-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/01/17 23:35, Keith Marshall wrote:
> I'm seeing evidence of an MSYS shell bug, which prevents mingw-pkg
> from even locating the package specification file:
>
> ...
>
> it has failed to match the 'case [0-9]*)' pattern, as it
> should have, and consequently, has set 'PACKAGE=gcc-5.3.0', where it
> should have been just 'PACKAGE=gcc'

This issue appears to arise as a consequence of leaving the '-' in
$IFS; the effect is as if bash performs IFS directed word splitting
on the case pattern, (which I think is incorrect behaviour -- dash
certainly handles it more intelligently -- but I cannot find any
definitive specification for what would be "correct" behaviour).
In any case the effect is that the '[0-9]' character range within
the 'case [0-9]*)' pattern specification is misinterpreted.  The
issue is mitigated by clearing $IFS, and using a local, unrelated
shell variable in its place, within the scope of the case statement.

Today, I've pushed changes to circumvent this issue, and to correct
the previously identified 'mingw-pkg patch' defect, to my SF user
repository, so mingw-pkg should now work as originally suggested,
regardless of any host shell deficiencies.

- --
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)

iQIcBAEBAgAGBQJYbXj6AAoJEMCtNsY0flo/ENEQALt0g/RnJtxoHhlalkJI5bPj
bDhxwTUOcGyBozgstk4YkqXTwQeXe0wEkTpjHqm3EETWN3W7hk2MrWNpvoORdaZI
gpXoThIKgmrwxpopPu7dd2V9zuPjramYz+H1mWxJSCGHrY3abLk1Y+S33eyWVA15
j5dK64XjXhjRPsxvlJYEQmwejgvRr+JonMq77TUOYIgperXUwOdQK3HZ3FAFryuh
UO0sQGJ08wP8u6+YRXj/mG1WZiQtdvUtnoeQdNx6RabujnBNiYo3q6w0Pz3PqXjX
5yIY57006YgvUplEXr/SuP4FFST2Ta9P2gSFIkGgvdogK49+K03JC55pLVuff2UC
/aaBZXDekCOWN9aIAkIABTpndI/LHDoylfbHFuV2r/jKSJfaeLxI1IeV25HmhLUA
u24AfCfP2sS6tNM4AHg1r3gerdwcnUfA6qFPv8wCxTt+X0SioViZAy5x2JQjf/S/
nIs1/QcEwZfn3vj6PCMNmFbBHZ2o+fDqbNv1dayKyz0kYQURlG4uUMj9EhJquU05
GMM9I4DfKloDP4D6/XoCqfjI71uN1wLIwkQutPgTc5UeFaLzqwE3tVGRjg2IaY/V
TI1KIN8/hMrQOxf4vdnFPC567Ne5LzN38J+S2Tz9o9huUvwuvv8g8iSHMGTMTZ8X
DdsmIKur59PYz8HqUB2m
=swdI
-----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-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

David Gressett-5

>From: Keith Marshall <[hidden email]>
>Sent: Wednesday, January 4, 2017 4:36 PM
>To: [hidden email]
>Subject: Re: [MinGW-dvlpr] Problem with configure when trying to build gcc      5.3

>On 03/01/17 23:35, Keith Marshall wrote:
>> I'm seeing evidence of an MSYS shell bug, which prevents mingw-pkg
>> from even locating the package specification file:
>>
>> ... snip ...
>>
>> it has failed to match the 'case [0-9]*)' pattern, as it
>> should have, and consequently, has set 'PACKAGE=gcc-5.3.0', where it
>> should have been just 'PACKAGE=gcc'

>This issue appears to arise as a consequence of leaving the '-' in
>$IFS;
--- snip ...

>Today, I've pushed changes to circumvent this issue, and to correct
>the previously identified 'mingw-pkg patch' defect, to my SF user
>repository, so mingw-pkg should now work as originally suggested,
>regardless of any host shell deficiencies.

I tried it and it worked perfectly for the patch;
however, I still have the problem with the ghost of .mingw-pkgrc
that continues to haunt my build attempts by inserting
--build=x86_64-pc-linux-gnu
into my configure options. I have seen some evidence that this is
part of a larger problem: some msys components are having
problems with the Windows 10 file system. I found one
problem when I was trying to build gcc 5.3.0 without
mingw-pkg. Instead of doing a completely manual build,
I modified Earnie's 4.8.1 build system. I set this up on
my Windows C drive in C:/Build_gcc, which was
/c/Build_gcc in msys. I found that when I used tee
to copy stdout to ../make-patch.log that the resulting
log file was invisible on the Windows side. A dir command in
a cmd window could not list it and it was not visible
in a Windows explorer window, but the msys ls could
list it and rm could make it disappear. I moved everything
down one level into a subdirectory of Build_gcc and
the problem disappeared.

I suspect that my use of rm .mingw-pkgrc was not
completely successful and that it may have corrupted
the file system rather than removing the file, leaving
a file that could be read but not listed.

I saw another possibly related problem with my
build using Earnie's build system. I found that
make prep, make patch, and make configure all
apparently worked, but make stage did not work .

I saw errors like
/bin/cp: cannot stat  stg/include/*': No such file or directory

make quit shortly after that, leaving an empty stg/include
directory.

I saw that this build did create the Ada dll files but it
did not give them the same names that I had
set up in the makefile. I tweaked Earnie's makefile by
replacing all instances of the string "4.8.1" with "5.3.0"
and likewise changing "4.8" to "5.3". This gave me

ada_DLL_FILES = libgnat-5.3.dll libgnarl-5.3.dll

at line 66 in the makefile, but the build produced

libgnarl-5.dll and libgnat-5.dll







------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/01/17 17:07, David Gressett wrote:
> I still have the problem with the ghost of .mingw-pkgrc
> that continues to haunt my build attempts by inserting
> --build=x86_64-pc-linux-gnu
> into my configure options.

There's not a lot we can do, to help you debug that; have you
tried running 'mingw-pkg configure' under 'sh -vx ...', (as I
suggested on Tuesday)?  The output from that should show you
where the bogus setting is creeping in.

- --
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)

iQIcBAEBAgAGBQJYbsmWAAoJEMCtNsY0flo/0yUP/itVEfyfgUB68/1kIyWE0Kpx
Q8opHXI9CALfpl4/MDC/Aon3mJOy7Dw0N/vL1kb6TmNYy6caI522Db4fPk434Mja
gTsP84/RFhkJfM2OtKJVIZQB9yO8Qo68yj+Jn12tA977hTVcGzIO4ZqDArxPCGUT
npMyK02vrkFLLKDvRLPTyzsngmiMCy48iYyWbsxg5ZX0O3/VfVt3iPZUxvmeEnsI
LABYomX1q9XcA/o37Y1Jcrb9n5hO7karp2yTes91ew5BZlsrQjl9fYb4z2OtpmGX
JrRu4S7/hxGobSFwQWFEbiaN8WgLO/2/m04sWmqC5m3VofglM0YQY67zAnREYX6q
6hUY0w0kT0CLw+X+I5oyC0yDbKCAdLc4eNL1s/5khMXnVhaEzliCyIeb6EDRMYO0
ptF4BHzcLkQTLKHFsXZTZgubWew/pLAITOX9ZgHa+HD9Rev94JE+N8oeDz7jDN4A
YPWgJqxbB+B0icUdbdCi5gP6Ec+cKBgtkr+jwAdu7netUpPlwKXhNSxzvferpQdS
DeCJDF38h9K7xp/b9ZIHyz9w/v6Nf2fgxpwckIztEfJNs9NQdffDtrt0QV5UvSkG
bv4ju5nw5XRYNbmegQPBjVziH9g+fI6EoQBRtdTRse528mT+xjhCyVFeTw4pbYSS
BNJxA1ieIF3KDDoaQa31
=IRv6
-----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-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

Earnie Boyd
In reply to this post by David Gressett-5
On 1/5/2017 12:07 PM, David Gressett wrote:

>
>> From: Keith Marshall <[hidden email]>
>> Sent: Wednesday, January 4, 2017 4:36 PM
>> To: [hidden email]
>> Subject: Re: [MinGW-dvlpr] Problem with configure when trying to build gcc      5.3
>
>> On 03/01/17 23:35, Keith Marshall wrote:
>>> I'm seeing evidence of an MSYS shell bug, which prevents mingw-pkg
>>> from even locating the package specification file:
>>>
>>> ... snip ...
>>>
>>> it has failed to match the 'case [0-9]*)' pattern, as it
>>> should have, and consequently, has set 'PACKAGE=gcc-5.3.0', where it
>>> should have been just 'PACKAGE=gcc'
>
>> This issue appears to arise as a consequence of leaving the '-' in
>> $IFS;
> --- snip ...
>
>> Today, I've pushed changes to circumvent this issue, and to correct
>> the previously identified 'mingw-pkg patch' defect, to my SF user
>> repository, so mingw-pkg should now work as originally suggested,
>> regardless of any host shell deficiencies.
>
> I tried it and it worked perfectly for the patch;
> however, I still have the problem with the ghost of .mingw-pkgrc
> that continues to haunt my build attempts by inserting
> --build=x86_64-pc-linux-gnu
> into my configure options. I have seen some evidence that this is
> part of a larger problem: some msys components are having
> problems with the Windows 10 file system. I found one
> problem when I was trying to build gcc 5.3.0 without
> mingw-pkg. Instead of doing a completely manual build,
> I modified Earnie's 4.8.1 build system. I set this up on
> my Windows C drive in C:/Build_gcc, which was
> /c/Build_gcc in msys. I found that when I used tee
> to copy stdout to ../make-patch.log that the resulting
> log file was invisible on the Windows side. A dir command in
> a cmd window could not list it and it was not visible
> in a Windows explorer window, but the msys ls could
> list it and rm could make it disappear. I moved everything
> down one level into a subdirectory of Build_gcc and
> the problem disappeared.
>
> I suspect that my use of rm .mingw-pkgrc was not
> completely successful and that it may have corrupted
> the file system rather than removing the file, leaving
> a file that could be read but not listed.
>
> I saw another possibly related problem with my
> build using Earnie's build system. I found that
> make prep, make patch, and make configure all
> apparently worked, but make stage did not work .
>
> I saw errors like
> /bin/cp: cannot stat  stg/include/*': No such file or directory
>
> make quit shortly after that, leaving an empty stg/include
> directory.
>
> I saw that this build did create the Ada dll files but it
> did not give them the same names that I had
> set up in the makefile. I tweaked Earnie's makefile by
> replacing all instances of the string "4.8.1" with "5.3.0"
> and likewise changing "4.8" to "5.3". This gave me
>
> ada_DLL_FILES = libgnat-5.3.dll libgnarl-5.3.dll
>
> at line 66 in the makefile, but the build produced
>
> libgnarl-5.dll and libgnat-5.dll

Sounds to me like you have what Cygwin calls "BLODA" going on.  Have you
tried with AV off or ignoring your work environment?

The one thing about ADA that I remember is that it required a previous
build of ADA to build the new one.  I'm sure there must be a bootstrap
process other than building via cross but it was beyond what I had time
to consider.

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

David Gressett-5
In reply to this post by Keith Marshall-3

>From: Keith Marshall <[hidden email]>
>Sent: Thursday, January 5, 2017 4:32 PM
>To: [hidden email]
>Subject: Re: [MinGW-dvlpr] Problem with configure when trying to build gcc      5.3


>On 05/01/17 17:07, David Gressett wrote:
>> I still have the problem with the ghost of .mingw-pkgrc
>> that continues to haunt my build attempts by inserting
>> --build=x86_64-pc-linux-gnu
>> into my configure options.

>There's not a lot we can do, to help you debug that; have you
>tried running 'mingw-pkg configure' under 'sh -vx ...', (as I
>suggested on Tuesday)?  The output from that should show you
>where the bogus setting is creeping in.

I tried that and the result  looked just like the example that
you had in your Tuesday message. config.log  still showed

Configured with: ../src/gcc-5.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --prefix=/mingw ...

config.status, however, contained an option list that had no --build
option. At that point, I tried the compile step, using tee to save
the console display. It eventually crashed with this message:

C:\MinGW\mingw32\bin\ld.exe: cannot find dllcrt2.o: No such file or directory

I then looted Earnie's package.ini for configure options that
were not originally in your gcc-5.3.0-mingw32.pkgspec and
added them into it and tried again, with exactly the same results.
This struck me as odd, since the compilation with Earnie's build
system completed successfully.

I have attached a bit of the compile log file that shows the
context of the error.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

error.txt (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/01/17 20:09, David Gressett wrote:
>> There's not a lot we can do, to help you debug that; have you
>> tried running 'mingw-pkg configure' under 'sh -vx ...', (as I
>> suggested on Tuesday)?  The output from that should show you
>> where the bogus setting is creeping in.
>
> I tried that and the result  looked just like the example that
> you had in your Tuesday message. config.log  still showed
>
> Configured with: ../src/gcc-5.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --prefix=/mingw ...

I meant you to search in the echoed shell commands, as executed
by mingw-pkg, to identify which of them is adding that bogus
option; if you can't find it there, then do you, perhaps, have
a stale config.cache in your build tree, from whence it may be
inherited?  If so, get rid of it; ideally, 'rm -rf' the entire
build tree, and start with a clean slate.

> config.status, however, contained an option list that had no --build
> option. At that point, I tried the compile step, using tee to save
> the console display. It eventually crashed with this message:
>
> C:\MinGW\mingw32\bin\ld.exe: cannot find dllcrt2.o: No such file or directory

Hmm.  dllcrt2.o is a component of mingwrt; for me it lives in
'/home/keith/mingw32/lib`, (under the '/home/keith/mingw32'
prefix, where my Linux hosted mingw32-gcc cross-compiler is
installed).  For the crossed-native build, I didn't appear to
need to do anything in particular, to have that found, but,
when building the cross-compiler itself, I need to:

1) Configure and 'make install-headers' for mingwrt/w32api,
   with prefix configured as /home/keith/mingw32

2) Configure, make, and 'make install' GNU binutils, with
   this same prefix, (also specified for '--with-sysroot'),
   and with `--target=mingw32'

3) Symbolically link /home/keith/mingw32/mingw to its own
   containing directory; (this is a ludicrously defective
   requirement of the GCC build system itself -- without it,
   the build will fail with 'the directory which should
   contain the system headers does not exist', in spite of
   them being correctly installed in prefix/sysroot at
   step (1)).

4) Configure the GCC build, again with /home/keith/mingw32
   as prefix, and sysroot; (sysroot is appropriate in the
   case of cross-compilers, but not native builds).

5) Perform the first 'make all-gcc' phase, of a two stage
   GCC build.

6) 'make install-gcc' the partial GCC built in step (5).

7) Use that partially built and installed step (6) GCC
   to make and 'make install' mingwrt/w32api.

8) Complete the GCC build, with 'make', then 'make install'

Once the above is in place, the crossed-native build is much
simpler:

1) Configure, as per mingw-pkg specification.

2) Build it; all that seems to be required is 'make', which
   is all that 'mingw-pkg compile' does, for the GCC case.

I've never tried to build GCC natively on Windows; the whole
process is much too painful!  Perhaps you need something like
the stage-by-stage procedure used for my cross-compiler?  Or
maybe, a 'make bootstrap' procedure, (for which the mingw-pkg
specification isn't set up, in the 'mingw-pkg compile' case)?

- --
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)

iQIcBAEBAgAGBQJYcj6bAAoJEMCtNsY0flo/AXwQALOYw7T8UDacxKOnwu3M86S6
PNGC+yI88qKPROZxNAIYOkhc7gRyLdbYkXTuHtCsYtMl5+4bpkdEaDktBORbo740
4SUo/O9+WhUwoYS9DZ4niEa8xW/aBPRpiSFjlX6Voodqhb9DA6t04H5J3ImKuUjA
0wcLaTdDX9j/hrOsSzVfaoUEIyHkcu/z333w9/0Ov6+UiL9GYQS/O0tKWeFJe3/s
IzRWyALyH6jsQHhYtdNx472b/WY4knNzWoCyYxi1HvORdlZ7R8xdgFAMmnsOL8O0
hrdF1W+MoPx1/nHRvkanMQ3zaA+GIITV0E0bqYU1cUAkDxlUsPbmPIcRo1FYQ/Lj
6Vps1ls/MlNG9ctfTsEAkV3iFDMtK5DGOFRQCoM1sygx0IYDa9E7FLYS6FWj6DzB
+NxrlCDERYtAtX8PcTI8vPoObNODbtos84LGe0vQPyzC5l/XzjhUf+ORR/OcMqwT
/i5VxPRx5N58HgKwmReDhsoK4OVFOLT6jduNT+CcQ9Kb2GIpJh0xYlMtiUW3LecC
ZztlOsGypeLtcwXRc3a2M1qloqCokg0HgOnLlOUVGE8NdKWBqQPagV8pwjWl83xM
XpWWE/f+9cSBnfNhKbk8MRIdlgcT+kVcnEWzmEhDsObnb4apLuEe+Wc+Zd8pR4KC
OgT81+5Jy+wVhPZOZ2P3
=aFUb
-----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-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

Cesar Strauss-2
In reply to this post by David Gressett-5
On 01/07/2017 20:09, David Gressett wrote:
> I tried that and the result  looked just like the example that you
> had in your Tuesday message. config.log  still showed
>
> Configured with: ../src/gcc-5.3.0/configure
> --build=x86_64-pc-linux-gnu --host=mingw32 --prefix=/mingw ...

This is harmless. It is simply echoing how your native gcc (installed
via mingw-get) was configured. Try running gcc -v:

$ gcc -v
Using built-in specs.
COLLECT_GCC=c:\programas\mingw\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/programas/mingw/bin/../libexec/gcc/mingw32/5.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-5.3.0/configure --build=x86_64-pc-linux-gnu
--host=mingw32 --prefix=/mingw --disable-win32-registry --target=mingw32
--with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada
--enable-static --enable-shared --enable-threads --with-dwarf2
--disable-sjlj-exceptions --enable-version-specific-runtime-libs
--with-libintl-prefix=/mingw --enable-libstdcxx-debug
--with-tune=generic --enable-libgomp --disable-libvtv --enable-nls :
(reconfigured) ../src/gcc-5.3.0/configure --build=x86_64-pc-linux-gnu
--host=mingw32 --prefix=/mingw --disable-win32-registry --target=mingw32
--with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada
--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
Thread model: win32
gcc version 5.3.0 (GCC)

> config.status, however, contained an option list that had no --build
> option.

Then it's OK. It should not be picking any "ghost" of .mingw-pkgrc.

Regards,
Cesar


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with configure when trying to build gcc 5.3

David Gressett-5
In reply to this post by Keith Marshall-3

>From: Keith Marshall <[hidden email]>
>Sent: Sunday, January 8, 2017 7:28 AM
... snip ...
>> config.status, however, contained an option list that had no --build
>> option. At that point, I tried the compile step, using tee to save
>> the console display. It eventually crashed with this message:
>>
>> C:\MinGW\mingw32\bin\ld.exe: cannot find dllcrt2.o: No such file or directory

Hmm.  dllcrt2.o is a component of mingwrt; for me it lives in
'/home/keith/mingw32/lib`, (under the '/home/keith/mingw32'
prefix, where my Linux hosted mingw32-gcc cross-compiler is
installed).

... snip ...

>I've never tried to build GCC natively on Windows; the whole
>process is much too painful!  Perhaps you need something like
>the stage-by-stage procedure used for my cross-compiler?  Or
>maybe, a 'make bootstrap' procedure, (for which the mingw-pkg
>specification isn't set up, in the 'mingw-pkg compile' case)?

There should be a clue to the dllcrt2.0 problem in Earnie's build
system that was used for the 4.8.1 release - when I hack it to
build 5.3.0, I have problems with make stage, as I previously mentioned,
but the the make compile step completes with no dllcrt2.o problem.

I did a test builds of gcc 5.3.0 using both Earnie's system and
mingw-pkg. In order to make a better comparison, I modified
the build options in gcc-5.3.0-mingw32.pkgspec to be an exact
duplicate of the ones that I lifted from the package.ini file in
Earnie's 4.8.1 build. The builds had the same result as before -
The compile step succeeded in Earnie's system and failed
with the dllcrt.o problem with the mingw-pkg system

I did a diff of the config.log and config.status files that
were produced by the two build systems. I found that the only
difference was  the path relationship between the build
and source directories, which is a trivial difference.

>From that, I conclude that mingw-pkg in a native Windows
environment is doing something that causes problems for
make; I will need to do some more analysis to find out what
is happening. It would help if I knew what command line that
mingw-pkg  creates for  make in the compile stage, but
'sh -vx' should be useful there.


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Loading...