Fortran Patches for gcc 5.3.0

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Fortran Patches for gcc 5.3.0

David Gressett-5
The bug that is fixed in gcc 6.3.0 is in the GCC Bugzilla as bug report 70684.
a patch is in Comment 7:

-----------------------
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index e24b3922..b8e174c5 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -197,7 +197,7 @@ check_buffers (st_parameter_dt *dtp)
     }
 
 done:
-  dtp->u.p.at_eol = (c == '\n' || c == EOF);
+  dtp->u.p.at_eol = (c == '\n' || c == '\r' || c == EOF);
   return c;
 }
-------------------------

The other patch is the one for the undefined items;

----------------------------
diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.am gcc-5.3.0-working-m64/libgfortran/Makefile.am
--- gcc-5.3.0-current/libgfortran/Makefile.am 2014-11-28 11:39:15 -0600
+++ gcc-5.3.0-working/libgfortran/Makefile.am 2015-12-27 17:21:46 -0600
@@ -44,13 +44,13 @@ libgfortran_la_DEPENDENCIES = $(version_
 myexeclib_LTLIBRARIES = libgfortranbegin.la
 myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
 libgfortranbegin_la_SOURCES = fmain.c
-libgfortranbegin_la_LDFLAGS = -static
+libgfortranbegin_la_LDFLAGS = -static -no-undefined
 libgfortranbegin_la_LINK = $(LINK) $(libgfortranbegin_la_LDFLAGS)
 
 cafexeclib_LTLIBRARIES = libcaf_single.la
 cafexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
 libcaf_single_la_SOURCES = caf/single.c
-libcaf_single_la_LDFLAGS = -static
+libcaf_single_la_LDFLAGS = -static -no-undefined
 libcaf_single_la_DEPENDENCIES = caf/libcaf.h
 libcaf_single_la_LINK = $(LINK) $(libcaf_single_la_LDFLAGS)
 
diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.in gcc-5.3.0-working-m64/libgfortran/Makefile.in
--- gcc-5.3.0-current/libgfortran/Makefile.in 2015-12-04 04:47:53 -0600
+++ gcc-5.3.0-working/libgfortran/Makefile.in 2015-12-27 17:21:46 -0600
@@ -610,12 +610,12 @@ libgfortran_la_DEPENDENCIES = $(version_
 myexeclib_LTLIBRARIES = libgfortranbegin.la
 myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
 libgfortranbegin_la_SOURCES = fmain.c
-libgfortranbegin_la_LDFLAGS = -static
+libgfortranbegin_la_LDFLAGS = -static -no-undefined
 libgfortranbegin_la_LINK = $(LINK) $(libgfortranbegin_la_LDFLAGS)
 cafexeclib_LTLIBRARIES = libcaf_single.la
 cafexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
 libcaf_single_la_SOURCES = caf/single.c
-libcaf_single_la_LDFLAGS = -static
+libcaf_single_la_LDFLAGS = -static -no-undefined
 libcaf_single_la_DEPENDENCIES = caf/libcaf.h
 libcaf_single_la_LINK = $(LINK) $(libcaf_single_la_LDFLAGS)
 @IEEE_SUPPORT_TRUE@fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude
------------------------------------

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

Re: Fortran Patches for gcc 5.3.0

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

On 15/03/17 16:04, David Gressett wrote:
> The bug that is fixed in gcc 6.3.0 is in the GCC Bugzilla as bug
> report 70684. a patch is in Comment 7:

Thanks, David, but I wonder is really worth bothering to back-port to
GCC-5.3.0?  Would it not be better to just release GCC-6.3.0, which we
have both now built successfully[*]?

> The other patch is the one for the undefined items;
> diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.am gcc-5.3.0-working-m64/libgfortran/Makefile.am
> ...
> diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.in gcc-5.3.0-working-m64/libgfortran/Makefile.in

Strictly, you should patch only Makefile.am, then run autoreconf to
regenerate Makefile.in, (along with the rest of the build system), and
yes, that's an absolute pain in the proverbial, unless your automake is
identically the same version as the original maintainer's; just one of
the reasons why, despite favouring autoconf, I detest automake.

For me, that patch does no more than suppress an innocuous, and harmless
warning about only being able to create a static libcaf_single.a; that's
all I get anyway, with or without the patch.  Does it create a DLL, and
accompanying libcaf_single.dll.a, for you?

[*] I think I've applied all your patches, but I still don't get any
Ada associated DLLs built.

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

iQIcBAEBAgAGBQJZKvFMAAoJEMCtNsY0flo/3wkP/j62TC8UCvrS2gwNg8fO0AEt
/fcCb6OWCpb+9Jkrr1jXykVoDA0liCLK2PpNYpQIPuH1JwRNCMUXL8GDN3lqQpta
T3xlG+ydRz2h8yYdVOAZO5RPo8hmWp2rQDbk7XJt4Klh2ltYHkPfaLtUPDl6nTjc
cXzBmoSG4wBGzjofYxEPlGzCpUOBrvwL6LJ989zVm4NV0JC87fygrcJI17SPPeam
uX2ymKdb06ENPsdNaOQSRbwiCUBvcS8b8Q2ma3bmuzfRAESqzYNTsO5boqD8P4S0
Ps41Y5zkxGoW39dB1o90OPivmFjTBx55mCAEZhWVPdcEA8vGaUeW7Bbo7O1Kf61c
Kb06d9FwX+hBqmQaR68AhHTrXAnjBt3T488NgaFATvGZQhdVE5VesY6ADBkKzGn+
B/NjHpWCdS1Gr4a6xCXUrZWVyBFBI6f4m6V4KS8seLySvoN1+rgmdMmRh6s7oXZP
VWFlCJngytz7IJwrgeULV3gKlMJJFiBKJG03dUnSkPegds135CumomMSb9F3/wlh
Ayo6u0tf9nfcpatfmmeAvDf81EQ9zV0+2S9fPPwuO1YnSR1rN+ZFs6r7x3JVKC6j
CUaNcSO0eCJqVWv6Ay25yg64kFof27xYSa8mSEScUTuPjglx9L2bSzwO6LxHA8V4
Ua+y+xIr6bYzU41nfqls
=GA0c
-----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
|

Re: Fortran Patches for gcc 5.3.0

David Gressett-5


On Sunday, May 28, 2017 10:48 AM Keith Marshall wrote:

>On 15/03/17 16:04, David Gressett wrote:
>> The bug that is fixed in gcc 6.3.0 is in the GCC Bugzilla as bug
>> report 70684. a patch is in Comment 7:

>Thanks, David, but I wonder is really worth bothering to back-port to
>GCC-5.3.0?  Would it not be better to just release GCC-6.3.0, which we
>have both now built successfully[*]?

It is better; if you are ready to move forward, I say go for it.

>> The other patch is the one for the undefined items;
>> diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.am gcc-5.3.0-working-m64/libgfortran/Makefile.am
>> ...
>> diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.in gcc-5.3.0-working-m64/libgfortran/Makefile.in

>Strictly, you should patch only Makefile.am, then run autoreconf to
>regenerate Makefile.in, (along with the rest of the build system), and
>yes, that's an absolute pain in the proverbial, unless your automake is
>identically the same version as the original maintainer's; just one of
>the reasons why, despite favouring autoconf, I detest automake.

No disagreement here. I have avoided the autotools, as I have never
needed them for anything that I have produced, and so I know little
about them; I only use them as needed to build open-source software.
For me, they are magic spells, to be avoided when possible.

I have found, however, that I can't avoid automake. My attempt at
rebuilding the various MinGW libraries with my sjlj  GCC-7.1.0
was derailed when my attempt at compiling gettext-0.18.3.2
dropped dead because it wanted  automake 1.14.

(To  be more specific, it wanted aclocal-1.14)

I am now working on getting the newer automakes to work.

>For me, that patch does no more than suppress an innocuous, and harmless
>warning about only being able to create a static libcaf_single.a; that's
>all I get anyway, with or without the patch.  Does it create a DLL, and
>accompanying libcaf_single.dll.a, for you?

I searched my builds for 5.3.0, 6.3.0, and 7.1.0 and found no DLL.

>[*] I think I've applied all your patches, but I still don't get any
>Ada associated DLLs built.

My builds do not put them in the usual place. Look in

/mingw/lib/gcc/mingw32/6.3.0/adalib

In that directory,  I have libgnarl.a, libgnarl-6.dll, libgnarl-6.dll.a,
libgnat.a, libgnat-6.dll, and libgnat-6.dll.a


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

Re: Fortran Patches for gcc 5.3.0

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

On 30/05/17 18:31, David Gressett wrote:

>
>
> On Sunday, May 28, 2017 10:48 AM Keith Marshall wrote:
>
>> On 15/03/17 16:04, David Gressett wrote:
>>> The bug that is fixed in gcc 6.3.0 is in the GCC Bugzilla as bug
>>> report 70684. a patch is in Comment 7:
>
>> Thanks, David, but I wonder is really worth bothering to back-port to
>> GCC-5.3.0?  Would it not be better to just release GCC-6.3.0, which we
>> have both now built successfully[*]?
>
> It is better; if you are ready to move forward, I say go for it.

You may notice that, earlier today, I uploaded gcc-6.3.0-mingw32 to FRS,
along with binutils-2.28-mingw32, gmp-6.1.2-mingw32, mpfr-3.1.5-mingw32,
mpc-1.0.3-mingw32, and isl-0.18-mingw32.  I may post an interim heads up for interested users, on the MinGW-Users list, but I'll hold off on a
formal release notice until I've completed the mingw-get integration,
(which I may not get around to until next week).

>>> The other patch is the one for the undefined items;
>>> diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.am gcc-5.3.0-working-m64/libgfortran/Makefile.am
>>> ...
>>> diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.in gcc-5.3.0-working-m64/libgfortran/Makefile.in
>
>> Strictly, you should patch only Makefile.am, then run autoreconf to
>> regenerate Makefile.in, (along with the rest of the build system), and
>> yes, that's an absolute pain in the proverbial, unless your automake is
>> identically the same version as the original maintainer's; just one of
>> the reasons why, despite favouring autoconf, I detest automake.
>
> No disagreement here. I have avoided the autotools, as I have never
> needed them for anything that I have produced, and so I know little
> about them; I only use them as needed to build open-source software.
> For me, they are magic spells, to be avoided when possible.

Well, I think I spent about an hour a day, for around a week, to grasp
the rudiments of autoconf; I find it so useful that I tend to use it
for everything ... even trivial projects.  However, when I subsequently
looked at automake, I just could never grasp what useful purpose it
might serve ... unless you like to have your logical makefile syntax
translated into pure gobbledygook.

> I have found, however, that I can't avoid automake. My attempt at
> rebuilding the various MinGW libraries with my sjlj  GCC-7.1.0
> was derailed when my attempt at compiling gettext-0.18.3.2
> dropped dead because it wanted  automake 1.14.
>
> (To  be more specific, it wanted aclocal-1.14)

Ah, aclocal; logically, that should be an autoconf component, but the
autoconf developers declined to provide any such tool, (perhaps because
they were unable to come up with a reasonable design); the automake
folks took it on themselves to provide the current turd ... it is both
conceptually and fundamentally broken by design, and may even destroy
a carefully crafted aclocal.m4, if used carelessly.

> I am now working on getting the newer automakes to work.
>
>> For me, that patch does no more than suppress an innocuous, and harmless
>> warning about only being able to create a static libcaf_single.a; that's
>> all I get anyway, with or without the patch.  Does it create a DLL, and
>> accompanying libcaf_single.dll.a, for you?
>
> I searched my builds for 5.3.0, 6.3.0, and 7.1.0 and found no DLL.

Right, so that patch isn't strictly necessary ... it does no more than
suppress a fundamentally harmless message, which is readily overlooked
anyway, amongst the rest of the build system noise.

>> [*] I think I've applied all your patches, but I still don't get any
>> Ada associated DLLs built.
>
> My builds do not put them in the usual place. Look in
>
> /mingw/lib/gcc/mingw32/6.3.0/adalib
>
> In that directory,  I have libgnarl.a, libgnarl-6.dll, libgnarl-6.dll.a,
> libgnat.a, libgnat-6.dll, and libgnat-6.dll.a

I've already searched my entire build tree, and staged install tree; in
the build tree, I see:

  gcc/ada/rts/libgnarl.a
  gcc/ada/rts/libgnat.a

but no corresponding DLLs or .dll.a import libraries; in the install
tree, I see that these have been copied to:

 $prefix/lib/gcc/mingw32/6.3.0/adalib/libgnarl.a
 $prefix/lib/gcc/mingw32/6.3.0/adalib/libgnat.a

Among the messages from "make install", I see conditional attempts to
install the corresponding DLLs, IFF they exist in gcc/ada/rts, which of
course they don't.  Among those messages, I also see:

  cp: cannot stat ‘rts/standard.ads.h’: No such file or directory

which may be (potentially) more disturbing.

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

iQIcBAEBAgAGBQJZLcPcAAoJEMCtNsY0flo/WD0QAIsYUOdADSbph+H3zXYcQY2Z
94V7rCRX8vc4/KZ5TaYIPNqXS0ged0bIXGBJa275pHsCrguxjuZVw5edlwqaTO8j
p4AVjAKGU8sJDL3DYdU7fDEQvO0r7ojl2fJRfsYKv33TwHrkWTvCeS92fMHQ8ZRD
nvWtW8DqHj3HxAbzhtqiWxh+jl2COy/8/lvhLtPfK4iFxMNeAnbBtnGpDPkba9ZE
ZEw6Ap87dy18e9jDVrsHoMC5xsOwKWKO9+X9B6pyi+jrNLIIxd6+RP4OC7Rbu7gD
XHwSYl3XGwfemiRur8PRbb/F6ISO56Gf87dWf6PNwv5z/821KiuOeQgZ7k1GC75o
zT3qvzd6BZO5xnVuTGO4jkgvo+pQr2AH8avR5tKgPBbDlxOHJQEF4DzKPaBD6tia
00HSZ+HuHUPKEJLg//gUM3LoiqGzuwgW+UjqOC4ZPc9w1ZZy27LdFFSaIcYFEMuq
weksmU7CcOnL/D0FeIoiGro+tjtxEdWIEwOKkZDHdUh3anhcoS/ymHW/1LCJlRmN
mPulAn5ZIaAZ30spfJr+0peYso034Vg/oTIMzr/sjC9Gbd9P/QZaXYCIf1nP8hrw
ajAvcUJfMBL+A6lm0yrqPrgtX3jx2IXB0hg7MsF4HWP73wXfau6lNtOuvQUdd3sf
yeXYQWMtVKYBpIgq7rVJ
=+x31
-----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
|

Re: Fortran Patches for gcc 5.3.0

David Gressett-5


OnTuesday, May 30, 2017 2:11 PM Keith Marshall wrote

>On 30/05/17 18:31, David Gressett wrote:
>
>
> On Sunday, May 28, 2017 10:48 AM Keith Marshall wrote:
>
... snip ...

>>> [*] I think I've applied all your patches, but I still don't get any
>>> Ada associated DLLs built.
>>
>> My builds do not put them in the usual place. Look in
>>
>> /mingw/lib/gcc/mingw32/6.3.0/adalib
>>
>> In that directory,  I have libgnarl.a, libgnarl-6.dll, libgnarl-6.dll.a,
>> libgnat.a, libgnat-6.dll, and libgnat-6.dll.a

>I've already searched my entire build tree, and staged install tree; in
>the build tree, I see:

>  gcc/ada/rts/libgnarl.a
>  gcc/ada/rts/libgnat.a

>but no corresponding DLLs or .dll.a import libraries;

In my build tree, i do have the corresponding DLLs and import libraries
in gcc/ada/rts.

>in the install
>tree, I see that these have been copied to:

> $prefix/lib/gcc/mingw32/6.3.0/adalib/libgnarl.a
> $prefix/lib/gcc/mingw32/6.3.0/adalib/libgnat.a

>Among the messages from "make install", I see conditional attempts to
>install the corresponding DLLs, IFF they exist in gcc/ada/rts, which of
>course they don't.  Among those messages, I also see:

I see the same conditional attempts. ( I am looking at the results of
"make install-strip", so some parts are different) In my case they succeed,
since I do have the pieces that your build tree does not have.

>  cp: cannot stat ‘rts/standard.ads.h’: No such file or directory

>which may be (potentially) more disturbing.

I do not have that.

Does your build tree contain gnatdll.exe?  if not, the patch that enables
its construction may not have happened. If it does exist, does your install
log show an attempt to install it?

In my install-strip log,   a set of twelve gnat tools (gnatbind, gnatchop,
gnat, etc are installed  in a loop; a few lines down, I see gnatdll.exe installed
separately.

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

Re: Fortran Patches for gcc 5.3.0

Keith Marshall-3
In reply to this post by Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30/05/17 20:11, Keith Marshall wrote:
> I see:
>
>   gcc/ada/rts/libgnarl.a
>   gcc/ada/rts/libgnat.a
>
> but no corresponding DLLs or .dll.a import libraries

I submitted: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921

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

iQIcBAEBAgAGBQJZLdDAAAoJEMCtNsY0flo/8j8QAIYSzBvtJLKItPUrxzCKgj66
JKiqCsQZJKBLRp3mmnzAbmBZjXsXJc40SUMuj6rT/a2evbAbI4KXnzE7Hsr9G1Ho
TMc+qswkMPQdLhg2RHFOe3GbeYcAsVoRwMdDw1+BXQUxoYEYsakfQCGcJEIkdCwQ
rKuFk7g7B6wY8TMuvhpr/HebOLtB/uI16hMmaxea2jm849rIcddOLJ/X+Cyiw6lV
E4oSxNiKpkZ17aIR559cSyls/z6YPQuQMKrAKZbHighTtpmPzbdFSvDsRJMjAm3s
QThZ8sdl+0M8zMZCATPonq4uLXR/xFD4QEbayar6VvYQSlh/W6+Z97i+ZbBjBzF7
0HtLN9A6fL3PDfAKU2XPo8myo1ukK+Zq9Z1fGZrFZ4e6ddDmDbU5ZE/h1Dj2cO+0
ea8yPYekjJKEIduGge35SguK7Y3jwKVRmGSdRcoMwbXhDOSUJxHZd7QJxpAiWAcZ
YBzmpqIO2/zYSln2COX5imnahyEZBWkQiun9i/HCUCAJjj9newO/qUHHJjBeOd8e
tYHXQVwPcQGrDQhyupE/lKbpt/9H/Dq5k9q2tjk/rX46Elf3peiTFN5Hdiz5R+Cf
l51TRK66AChRIUUNEa05XljjMLpMOJdDZq922iV0xnQa6r5XuEOlvtlHHN0neru/
bf+Rqxw6IGXwWqQ2wT1O
=cIrV
-----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
|

Re: Fortran Patches for gcc 5.3.0

Keith Marshall-3
In reply to this post by David Gressett-5
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30/05/17 21:06, David Gressett wrote:
>>   cp: cannot stat ‘rts/standard.ads.h’: No such file or directory
>>
>> which may be (potentially) more disturbing.
>
> I do not have that.
>
> Does your build tree contain gnatdll.exe?

Yes, as gcc/gnatdll.exe

> If it does exist, does your install log show an attempt to install
> it?

A successful attempt; it appears at $prefix/bin/gnatdll.exe.  It is also
installed (incorrectly) into my cross-compiler tree, as gnatdll, whereas
it should be installed as mingw32-gnatdll.

> In my install-strip log, a set of twelve gnat tools (gnatbind, gnatchop,
> gnat, etc are installed in a loop;

These are also installed, for me, and (correctly) named with the host
prefix, in the cross-compiler tree ...

> a few lines down, I see gnatdll.exe installed separately.

... and it is presumably in that separate installation, that the host
prefix is omitted, in the cross-compiler installation.

FWIW, I used "install-strip" too, when staging the distribution, but,
cognizant of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720, I also
checked the effect of "install", in case there was a similar omission
for the Ada DLLs.  I also included the attached patch, to correct the
(long-time ignored) PR-54720 bug, in *our* distribution.

The "cannot stat rts/standard.ads.h" issue is evident in both my install
and install-strip logs.

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

iQIcBAEBAgAGBQJZLdjvAAoJEMCtNsY0flo/No8P/RLz+93l9EEEQIopuaNXh47h
bcOuIfIiFODr4r6ilMAlNUgGCLm6EtXUpvZAv/yVCbRvjxGVby8P+Fca1zZ3ufI5
ovfkg7LJ/HlFOuLoZFQ5BvgJrDj66WBIkaxfG3O+04uxZgwu+1jiwedy0GdCUKSa
soe63Gdx5yKTgHEGR+dyLgTbC+fy3mv5ysPngbv5ZJuoaZa4Q17tMrgC7JSMDWr+
vC9/KxntJE1JXji9NbFjpqGSMy3zAoo0yKn5OliLHmwqdUpREtS63beaqtU4oGrj
yc/wnFH6O8/yyxFUWYreiLlIwkLM4ZGrybY5qnQ1HxRd6qUJM1LKkpVJLmc2ZskS
1IJ3vRpXgB2Y1gTMQH15ixWIDLMoVrCxO8qBlzbIBNRxMEPokXRA49u0Bdfx7HCI
9W8Hiki2zgvZUDujI6ZXzRDfrzr3j7pFZgyvLFN31VU1H7ofy7zjIxSVafWE+Odx
gznzvJQr7ECFZ+pAnC1/o9g6NES4eACtSaX76nlh+6vRtjIa2PnAldWAClViWw+U
o/QwquE3M+3RIOaaOUrb8rbIMHENx26g6zUoht57OI0zVHC4Qf4HtjdT1HdJxp0z
qtfVSbebj2G/d4YxzNcgV0ehc6fbzI5kRGltjmPB2c0cw5EDHJCkKWaJm4TFXW5o
lJJHzR2uIuz7dpLNc/kS
=pkoq
-----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

11-libobjc-install-strip.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fortran Patches for gcc 5.3.0

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

On 30/05/17 21:41, Keith Marshall wrote:
> The "cannot stat rts/standard.ads.h" issue is evident in both my install
> and install-strip logs.

Further investigation reveals that, at some point in the build phase, a
symbolic link has been created at $top_builddir/gcc/ada/standard.ads.h; it
refers to non-existent $top_srcdir/gcc/ada/standard.ads.h, and the "cannot
stat" issue arises when attempting to resolve that symbolic link during
the install (or install-strip) phase.

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

iQIcBAEBAgAGBQJZLePJAAoJEMCtNsY0flo/1IgQAKDxHRJSr/CRYnrziIHfLtFF
/4ouuyIk84Sneq9IjJrGZVR5RTxsnIm3e7c/hNh3KTuJxiqpqi6od4TjMs4zeXCd
rAD7q1NqyWI0rzOxzdyhdf68HNg55k2S8SXK+R3Hsvy81vGN5Ac5t9ZvjV/w8VUk
jmjeB41jvZB2j0NPLfsVD0ySl3e7GfvzwSEyRn9LC0B7ijN5lpd/X3CXQxtMPH/R
706KJuDylajkLGjmGdI9WY388ZPYv9LjIyt2M01f+9sKoYKsI133OHc3klePcyjM
kpV42R3c+f002iAoxuJ/DG6Gd+gso3Gm/OwPAq8TBWsc3yfwTaSTFdaddDXWRKUu
GSRcCH1yiSubU8c63AmDaaC+x4WDBrEMB4L3vVqlqyCOdWNuNiSu983XKeVDe2Uh
/r+H2TAhwI5fZrpcc5geJO2sFH5DECb2PahuUPSyNnGT7zORjSYRC+RmAF0MQGiu
Igr3SJ4D+5+VQHu985hVOwCeD22LUX8fKPkm2iFuHzDMbp3KIkaghnb9+6ABCSPE
j2ilysKSNmmS/ogOrAhAtxXSAh/R6Xk+yCOD7uOxunKiT2C979DfHVEz9mT8SnnX
ekAPFfSTW2Gvwui/nX8lohe91CpCFOQQPmknCo9o4ILcMUgBnxGRIovmo3sKpRJD
f0cR/JHCm7+SgwXyyzem
=H3uI
-----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
|

Re: Fortran Patches for gcc 5.3.0

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

 On Tuesday, May 30, 2017 3:41 PM, Keith Marshall  wrote


>On 30/05/17 21:06, David Gressett wrote:
>>>   cp: cannot stat ‘rts/standard.ads.h’: No such file or directory
>>>
>>> which may be (potentially) more disturbing.
>>
>> I do not have that.
>>
>> Does your build tree contain gnatdll.exe?

>Yes, as gcc/gnatdll.exe

>> If it does exist, does your install log show an attempt to install
>> it?

>A successful attempt; it appears at $prefix/bin/gnatdll.exe.  It is also
>installed (incorrectly) into my cross-compiler tree, as gnatdll, whereas
>it should be installed as mingw32-gnatdll.

It installs for me as gnatdll.exe

>> In my install-strip log, a set of twelve gnat tools (gnatbind, gnatchop,
>> gnat, etc are installed in a loop;

>These are also installed, for me, and (correctly) named with the host
>prefix, in the cross-compiler tree ...

I get the same thing , with the host prefixes, which are incorrect for a
native build; I fix them manually after the build completes. There are
several executables that get a host prefix from another source, and
so get  a double dose; for example, i get mingw32-mingw32-gcc.exe,
which I rename to mingw32-gcc.exe.

The configure system seems to have a problem getting the differences
between a native and cross build exactly right. I see other signs of this
when I build gcc with  gmp, mpfr, and mpc in-tree; I get warnings in
my compile log that I am using cross tools not prefixed with the
host triplet and that the none host is obsolete. This does not happen
when I build the gmp, mpfr, and mpc DLLs as standalone builds.

I get  compilers that work, however, even with the GCC-7.1.0 builds.


>> a few lines down, I see gnatdll.exe installed separately.

>... and it is presumably in that separate installation, that the host
>prefix is omitted, in the cross-compiler installation.

... and is also omitted for me in my native installation.

It looks as if in both cross and native builds, the set of twelve
get the prefix and the single gnatdll does not, with different
consequences for the Ada DLLs.

This leads me to believe that your failure to get the Ada DLLs
is the result of the cross build system looking for mingw32-gnatdll
and not finding it in the compile part of the build, but my native build
looks for gnatdll and finds it. My guess: Those parts of the GCC compiler
collection that are used in the  middle of the compile process are built
early on with the prefix because the cross build needs to use them.
gnatdll is handled separately, and incorrectly at one crucial point.
The same screwup happens in the native build and accidentally works.

... snip ...


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

Building Ada System DLLs [was: Fortran Patches for gcc 5.3.0]

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

On 31/05/17 00:58, David Gressett wrote:
> This leads me to believe that your failure to get the Ada DLLs
> is the result of the cross build system looking for mingw32-gnatdll
> and not finding it in the compile part of the build, ...

No; although incorrectly installed as gnatdll, I linked that (by file system hard link) to the correctly named mingw32-gnatdll, so it should
be found.  In any case, there's no evidence in any config.log, nor in
my build.log, that there was any attempt to find it.

The real cause of the problem is a bogus (utterly nonsensical) test in
libada/configure, (requiring $build == $target), which effectively
disables building of shared Ada libraries[1]; once I remove that test,
I do get libgnat-6.dll and libgnarl-6.dll, (but corresponding import libraries are not built, because there is nothing in the corresponding
Makefile to build them).

[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921

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

iQIcBAEBAgAGBQJZMFb+AAoJEMCtNsY0flo/IjsQALFQfcPIiVGPcWySnhCRZFdk
KxWiKblq+phJJ5s5dWqDSiiMqYgxLJvPsEHDh8Kw2bYqv9ANIuPSOXmPuZYzAL/I
gVFjZR0ulH8GIM3DJKfo/mGFDC860O0eFK20uF4475OJ33wWmMA3CeojVrjs86nd
NOsmSy6GQgjFN6AXZRoZZ5gMhqIQEpe7Kzl2PcR4Wd1s1Q/3BBI5cAKv0xM33kb5
tBgzP5/h9UfIVuX3vZAMMg9v+lRTX0wSs3OtRr2qxrBjOSsX2dlGWOAJOKdg5LyH
dNfAqI7wiL0r7gEhobEut8/qbqzpZuekpsRloqTrMBOSBKkO7Jm0k68IMXcdM18U
niSh4tqfVJB0Hlc0UpnPeIeRyggp1y59CizzRjgobLskl1CvmamonrggI9OziWMw
3sbWIuWAJFqDAxs33yoOFa18zaO+L5IptjzN36G+hZFsvxGzf/YupTy7Y+dWuCDh
27YuYTGcA2ME/piyI5J9xx8YiqbzUgyAuTfzVMvf6QiWUO1LKPsBYqPLOhwyQWSb
4ErqrzK0aoc3gZ9QanyjHyFCLqf/t7qmHI6w+1AXLwbg8zqbn3Vhz33Hr4GXCt5y
HVM81HtZaT7svG8FTisfAuufCdCULuoEQiwI7kGoBR6MmA6zrnkjd3ndFbXvJKgv
PxWvbPFC9LDdRmN8mngo
=zNv9
-----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
|

Re: Building Ada System DLLs

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

David,

On 01/06/17 19:03, Keith Marshall wrote:
> I do get libgnat-6.dll and libgnarl-6.dll, (but corresponding
> import libraries are not built, because there is nothing in the
> corresponding Makefile to build them).

I note that "make install-strip" does not strip these DLLs; should it?  
(Ditto, for libgcc_s_dw2-1.dll).

I can hack the Makefile.in to create import libs.  Do we need them?  
(The upstream maintainer says we don't).

I also note that "make install", (or "make install-strip"), sequesters
all gnat libraries, whether static, import, or DLL, in:

  $prefix/lib/gcc/mingw32/6.3.0/adalib/

I assume that the gnat tools expect to find them there, but surely any
dynamically linked application, built with them, will need the DLLs in
a runtime path?  Where should mingw-get install them?  Come to that, how
do the gnat tools select between static and dynamic linking?  (The GNU
linker will not associate, say, libgnat-6.dll with -lgnat, so if we do
not provide libgnat.dll.a, surely it will pick libgnat.a, which is a
static library).  Does this imply that gnat applications always default
to static linking?

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

iQIcBAEBAgAGBQJZMdGBAAoJEMCtNsY0flo/enIQAL3jdoxNpO7t0/6DOaKEij3Z
nL35JavMBOcbFeBIz6/sibZCmZPXI/hXXU5dfzAx2TtKjzl/U7+9hfLWYfeaFvgC
9fEPh/TCoyQzQY2mAW6XI++jFbLyQC84K3KTcWPnL2xX130vnpRv69pyqurQvE+M
HtvKym3lcvdRJZeBh5Iis8oP2aWMVDM4TaYVOya9TO26ATtpFTsSOAYRaOOVbk/I
bBY6mlh5jsAQO+fVnV+ppYLvasADC5oNuGC8xmSH1HobX2n7Iu9d2PbfEjmBXz7M
gfrLy2kulBWITBYz5OcHOVaqYZyYF52y+6SQhIyqgTlL0tzQHsEKr2Yu2uWS0SOq
92uEpuqQjfRPVz+ADUI9X4dSzrPD8Sjh3hzVbnvl22EreIJi4fCYJtS8gPzIfU8U
gGkmXpGOh3sLOYlsRvV2y5BlhBpH/PGxyTjhLuBSbNE3NUqw8ntm85F6+vFgt9yy
qHaEjgjSvmRSdVqNh/agaVRqe7YL5FY7Oee8bD8L3+dUIS26ZvYr9d03oJEaBt1x
vLh1p6jGWyh9CxR7I2c0H2YX9tcxdr5tcl+SEwL6zetlBZ07c8SnurjCEPdNeIo6
CbD7tdD9Zr97zSeoGUqLr0ROF242LBmaT4arv/OyR3d59Rt/JJdOwiAkr6CMGGym
Inf1qlKi1u3Kc3xmApEM
=eGoB
-----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
|

Re: Building Ada System DLLs

David Gressett-5

On Friday, June 2, 2017 3:58 PM, Keith Marshall wrote:

>David,

>On 01/06/17 19:03, Keith Marshall wrote:
>> I do get libgnat-6.dll and libgnarl-6.dll, (but corresponding
>> import libraries are not built, because there is nothing in the
>> corresponding Makefile to build them).

>I note that "make install-strip" does not strip these DLLs; should it?
>(Ditto, for libgcc_s_dw2-1.dll).

No, stripping an Ada DLL will cause it to lose its relocatability.

>I can hack the Makefile.in to create import libs.  Do we need them?
>(The upstream maintainer says we don't).
It wouldn't hurt to have them, but I expect that any use of them
would be very , very infrequent.

>I also note that "make install", (or "make install-strip"), sequesters
>all gnat libraries, whether static, import, or DLL, in:

>  $prefix/lib/gcc/mingw32/6.3.0/adalib/

>I assume that the gnat tools expect to find them there, but surely any
>dynamically linked application, built with them, will need the DLLs in
>a runtime path?  Where should mingw-get install them?  Come to that, how
>do the gnat tools select between static and dynamic linking?  (The GNU
>linker will not associate, say, libgnat-6.dll with -lgnat, so if we do
>not provide libgnat.dll.a, surely it will pick libgnat.a, which is a
>static library).  Does this imply that gnat applications always default
>to static linking?

Static linking is the default. I never do dynamic linking, so I
don't remember the gnat tool syntax needed; there is a specific
command-line option used to dynamically link the runtime, but
you would have to find it in the Ada user guide. The libgnat
and libgnarl DLL's should be left where "make install" puts them.
You could put copies in some place easier to find for people
who need to distribute them, but documentation that shows
where they are to be found would be adequate.
------------------------------------------------------------------------------
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
|

Re: Building Ada System DLLs

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

On 03/06/17 16:47, David Gressett wrote:
>> I note that "make install-strip" does not strip these DLLs; should
>> it?  (Ditto, for libgcc_s_dw2-1.dll).
>
> No, stripping an Ada DLL will cause it to lose its relocatability.

Why?  I don't understand.  Surely all Windows DLLs are inherently
relocatable?  Stripping doesn't modify the relocation tables, so why
would it have any such effect?

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

iQIcBAEBAgAGBQJZMwwjAAoJEMCtNsY0flo/SgwQAI0hgM1656xjqZqIKwWRgzET
W/ZEralDrzXIEzAAOb9+C068LeXs32fBcQMqglIC61E1+lVAqHva3JZn4X9GZJwI
y/Yas9rsEQF7tn8/WLUQBTpgCfGdvQwGvmnMCBBJChGbUaLGIlvtq4+ct9cI0ou6
obt8ZEjH5xfs9AiudkrWdP18TuoeLwykNb9mAYL4le/LZM6fqSeLj1C2X++21ZpT
TnTKSR7ins8GfBaMBg9J/NVZqM5pR3ijSFRKb4tnukCKOJCEzeQ90hKqoTFefc51
9PtG1s8/BCbSsANc0HeNoQUfZDvTV/p4mnPhvIeNaz9HxCVDEx50ws3Hfh9v7gZu
DazxySF0nJdEYLgkyQsEpRNOakMwUwT7OsFkfCIfq0FAKOaonGt0sc63RNfPWnOf
RqcWQ5JKNbuujawduowKULe6b3FUrTsE+145CHu/7WaWH0q3MsDf1aZh4ag9pj6k
F67agvebZ7VHBJbb/xW7P70w+FDtQZM+Mn9nr1B8aNmUFx+JLCMyiSX8umNlIpFv
1XVfFzN1M7MxN1kEHNC7ZGWcU39yXHPajsF91E91W0u/zFg3P4z8FiH6/YI2X+To
SpF0jReAGtU4H59yhaDia/qHcNubkAlwWfT775GP2rpIN/WNEERhd0rM2AslhB2m
7txpPhSUwAZJ04KARSLn
=kuw4
-----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
|

Re: Building Ada System DLLs

David Gressett-5
On Saturday, June 3, 2017 2:21 PM, Keith Marshall wrote:
1

>On 03/06/17 16:47, David Gressett wrote:
>>> I note that "make install-strip" does not strip these DLLs; should
>>> it?  (Ditto, for libgcc_s_dw2-1.dll).
>>
>> No, stripping an Ada DLL will cause it to lose its relocatability.

>Why?  I don't understand.  Surely all Windows DLLs are inherently
>relocatable?  Stripping doesn't modify the relocation tables, so why
>would it have any such effect?

It has been several years since I looked at the Gnat user's guide,
so I went back to it to double-check my memory. It is indeed
documented in  the Gnat user's guide that stripping will cause
problems. In section 9.3.5.12 of the Gnat user's guide:

"Note that a relocatable DLL stripped using the strip binutils
tool will not be relocatable anymore. To build a DLL without
debug information pass -largs -s to gnatdll. This restriction
does not apply to a DLL built using a Library Project."

I have no idea at present as to whether the part of the  makefile
that builds the gnat runtime invokes a library project or not;
I would have to dig through the build log to find out, and I have
not done that yet.


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

iQIcBAEBAgAGBQJZMwwjAAoJEMCtNsY0flo/SgwQAI0hgM1656xjqZqIKwWRgzET
W/ZEralDrzXIEzAAOb9+C068LeXs32fBcQMqglIC61E1+lVAqHva3JZn4X9GZJwI
y/Yas9rsEQF7tn8/WLUQBTpgCfGdvQwGvmnMCBBJChGbUaLGIlvtq4+ct9cI0ou6
obt8ZEjH5xfs9AiudkrWdP18TuoeLwykNb9mAYL4le/LZM6fqSeLj1C2X++21ZpT
TnTKSR7ins8GfBaMBg9J/NVZqM5pR3ijSFRKb4tnukCKOJCEzeQ90hKqoTFefc51
9PtG1s8/BCbSsANc0HeNoQUfZDvTV/p4mnPhvIeNaz9HxCVDEx50ws3Hfh9v7gZu
DazxySF0nJdEYLgkyQsEpRNOakMwUwT7OsFkfCIfq0FAKOaonGt0sc63RNfPWnOf
RqcWQ5JKNbuujawduowKULe6b3FUrTsE+145CHu/7WaWH0q3MsDf1aZh4ag9pj6k
F67agvebZ7VHBJbb/xW7P70w+FDtQZM+Mn9nr1B8aNmUFx+JLCMyiSX8umNlIpFv
1XVfFzN1M7MxN1kEHNC7ZGWcU39yXHPajsF91E91W0u/zFg3P4z8FiH6/YI2X+To
SpF0jReAGtU4H59yhaDia/qHcNubkAlwWfT775GP2rpIN/WNEERhd0rM2AslhB2m
7txpPhSUwAZJ04KARSLn
=kuw4
-----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

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

Re: Building Ada System DLLs

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

On 03/06/17 23:37, David Gressett wrote:
> In section 9.3.5.12 of the Gnat user's guide:
>
> "Note that a relocatable DLL stripped using the strip binutils
> tool will not be relocatable anymore."

As a professional engineer, I'm conditioned to treat such claims with
suspicion; it's inconsistent with the behaviour I see for every other
regular DLL built for Windows, so I'd like to see concrete evidence in
support of the claim.

> "To build a DLL without debug information pass -largs -s to gnatdll.
> This restriction does not apply to a DLL built using a Library
> Project."

What does that mean?  The makefile rules to build libgnat-6.dll, and
libgnarl-6.dll, don't use gnatdll; they use "gcc -shared ...", just as
any C language (or indeed any other language) DLL is built, and such
DLLs don't cease to be relocatable when stripped.

> I have no idea at present as to whether the part of the makefile
> that builds the gnat runtime invokes a library project or not;
> I would have to dig through the build log to find out, and I have
> not done that yet.

Viewing my build.log in "less", and searching with "/libgna[tr]l*-6",
is sufficient to show me those "gcc -shared ..." commands, and takes
only a few seconds.

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

iQIcBAEBAgAGBQJZM0HzAAoJEMCtNsY0flo/2pQP+gJ589yhEvCBxNZQTv83hlLA
qiCwcu6MZ/v9d1ENZPk+ZM/eZrWbVoXa+jmjvV3341ZbqTPJRwZ036+gGHupSnqg
BZ0Gp1Nm7Aoe1KyxOvwkuQYIE6Fd+w95FXriAbIWcmM3ab0jYCngeBwcUO//3pyT
TrnRZJmORke7Ihz/r7vRVvDwxvbc/W2rrkABZDaXia516PtQyzn5Eb2+24i3JGt5
vx5wPAGpgd4ZQ+c1z8Y00JLI1bT/FOjBrlHjUsmD3PtN+0K/+aAcN/UZuZVcYHI2
C4OVql8VnNLTabEmRP8MO2ImnlpM1F/usrSMVqYHHzhMui1QlJULZV51fI8mvVzU
Gl9e4+7MdNxwemzIIddGUvXwlO3dBsxaWrUj1mnL+MJNnGfu6N9BfrVNQGZZ7nZw
UFUD0e1S33RVytYrh8JCU4/U2dL5R2cOTIOBH5lc17EjKJ2UQB/ZYu4+MaeMl3me
wlRO0S4JmAVJlRA/wRAmntu8S+J6kUC26r2fF1g79niNE25mzJJsqOfGasyQsSw3
CbgmQkYjwbbgPbyhGgdNm9vgJvGmN133fn/9ScpBXoPYmwZlQtym3MXK9Powkm65
SgfpWdYAOyFnf3cm25BEXSBw4PqXySLX0a+gBS5xN22GKAAU9+Bmh5Ch4CEn3Yya
Zvpk1hY49Qd25U8CXkPo
=SaP7
-----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
|

Re: Building Ada System DLLs

Keith Marshall-3
In reply to this post by David Gressett-5
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/06/17 16:47, David Gressett wrote:
> Static linking is the default.  I never do dynamic linking, ...

I wonder how many MinGW users actually use Ada?  Of those who do, I
wonder if *any* link the gnat runtime dynamically?

> The libgnat and libgnarl DLL's should be left where "make install"
> puts them.

Looking back to the previous releases, which are still visible on our
FRS download pages[1], it was done thus up to v4.3.0, with just one
Ada package for each release; thereafter, the DLLs were moved their
own separate package, and in the process they were relocated from their
default $prefix/lib/gcc/mingw32/[version]/adalib installation path, to
$prefix/bin.  That relocation would have moved them away from where the
gnattools would have expected to link them, making it even less likely
that any Ada application would have been linked to depend on them; no
existing distribution has provided corresponding import libs, which
might have mitigated the effect of relocation.

> stripping an Ada DLL will cause it to lose its relocatability.

FWIW, I haven't checked them all, but the distributed libgnat-4.7.dll
*was* stripped; did that create problems for users of that release?  
I don't remember any having been reported, but maybe that's simply
because no one ever used them.

[1]: Those which actually included gnatlib DLLs; GCC-3.x appears not
to have done so; neither did any of my cross-compiled releases, from
GCC-4.8.2 onwards.  Furthermore, while GCC-3.x *did* include the
gnatdll.exe tool, that appears to be missing from the GCC-4.x and
later releases.

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

iQIcBAEBAgAGBQJZM/rcAAoJEMCtNsY0flo/E4MQALnKFy1yNkzzXEXgfC1Zu+xL
xUtjc5E+VF1hWpLzgl7cAhyRFX8N6Wr8jd1HyYMBrSgA4ZJvtJQMKjTpAKULD/Lw
5hQ6B4dd2d+bTmON/DGxpHW5ggluBwzMlZEaVCgHWzObhF2k7hrSxrW8vmO6Q5rE
Ob42oY+A+bPyX58HE9p1YD7QVhYPfk7fqosPWIfdrNLmpxZHrhXbQtr2lPFjqW51
qJOsF0dcy+1iM3glnNt5arkCJ/KiRL/NDFf7mJGDPJY2PacboCqSWOo+fndhNW40
8bmZ0P+RJtd/ruu3xjeYMCNguwADPnJRj+Idg8M5ERogdCtZ4iyxveko5udBC1KH
rt5dQgEbVwaDL+b3GaQ3e98I7JvS9OupSlq74QebS5jGYby42qmHKoXNaT0b74lG
Qf9Kc5O21d6AOzs/Hf+oeN4yrRu6VZKaq4sLHJhIEmNesq5G5Rq08SvxHe0jiKRr
zmEv/5zIetTfdNb/KFFZIyo6+4RaluLsQmWK/KLTaAQQDBElaTZDD/B5iqaGvz35
xWWK7UIaVkoWa6srW6HoJp9fmshUrgOYZqgF0jKj6IS4kGstCl78dLh7cZXv7Q3r
jhnTwxUoQfi5izJZxkhfog+jHtr4HrWOU8QZvoFPAn0VDryZh+kSspD+YE7NPG8T
Y/y4d/M1SkMeorJBUrTP
=DVeX
-----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