GCC-6 and beyond

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

GCC-6 and beyond

MinGW - User mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Folks,

Some of you may have already noticed that GCC-6.3 packages have been
available, in our FRS, for some weeks now.  I'd now like to integrate
these into the mingw-get delivery system, before I move on to looking
at GCC-7, but in the process, I'd also like to (finally) eliminate
the legacy of the degenerately broken package structure, which was
introduced for GCC-4.8.1, (and has not been reproduced thereafter).

To clarify: GCC-4.8.1 unnecessarily (and illogically) introduced a "dev"
component package category, splitting the content of the "bin" component
packages into two mutually interdependent (and logically inseparable)
sub-packages; (all previous, and all subsequent, versions have simply
delivered such logically inseparable content in the form of a single integrated "bin" component package per compiler language).  The problem,
created by the GCC-4.8.1 packages, is the XML gymnastics required to
remove the residual content, left behind by those "dev" packages, lest
that should interfere with an upgrade to a later version, (or roll back
to an earlier version).

So, do any of you still have MinGW.org's GCC-4.8.1 installed?  If so,
are you willing to accept a procedural instruction to remove its "dev"
component packages, before upgrading (or rolling back) to any other
version?  Or otherwise, are you willing to accept, and deal with the
swathe of "conflict" error diagnostics which mingw-get will emit, if I
don't engage in the aforementioned XML gymnastics?

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

iQIcBAEBAgAGBQJZbKZMAAoJEMCtNsY0flo/7ZIP/0GQZa9ZQSIEHzfrIobcoVQ/
yeEH4/aWaGqPF//GJkMV9Iz068MfrGL2lrCetiXvUCzDP0+N5XtsVgWny6i8AwbD
KCRLPBhZLzVVgC9rRlnvCWeK8s+pTbquYaMJScfXIxasxZLYv/tm0U6EijSWKcx9
xFLhABmXZ79nPCCAe09sFQyBLEwiAGA5/WhghKRn984F/2zqylvVSYY4vlNKDPzc
8T/GHbvAvjS/9dhBPg9ccj1lcJWksqoTyPL6PS0gZZ3G4xN0hYlo78saH6gzwkDz
QJLo3M1/shtlieQNEQ/dBXnJuf5eqGYIhTJaY9z3dYdvU993Oq/QQhdnzbZwPDtH
+47jl81L/1ANRtp9VlMkUgVb195sG24YzRpOY8GJeEb81yLDkH5ea+FvLFPNTTBv
dut6BEXpz7vDQjY7e9EpnzZwmgm2gmYkHzz2NigSJKlCNYjdlurg6cLTg2gOXjcN
07eFOzNswp2CP9ofMWYH5B2n++GYH4DYPLVYa4oSAzOGe3FoMzqQT+VgkagyS7Wd
YVcj9rNgkl/a3iPLBVotfjxZiSkDPsPNhcI8rQi4eAnGXoowNRAOTuTcJuKMqvd5
PfdgMM+XDsg49P8DQfEJpN6T5INWoRq88YID5OrGAUSzqGG6vQBkKkk1PdmPWNMG
V3oKkI+w8IFF0dssb5aD
=z8iF
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get (was: GCC-6 and beyond)

MinGW - User mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/07/17 12:58, Keith Marshall via MinGW-users wrote:
> Some of you may have already noticed that GCC-6.3 packages have been
> available, in our FRS, for some weeks now.  I'd now like to integrate
> these into the mingw-get delivery system,

This is now completed, and published; please see below, for guidance on
the (somewhat unconventional) upgrade procedure.

> before I move on to looking at GCC-7, but in the process, I'd also
> like to (finally) eliminate the legacy of the degenerately broken
> package structure, which was introduced for GCC-4.8.1, (and has not
> been reproduced thereafter).

I've laid some groundwork, towards this objective; to do a thorough job
may require modifications within mingw-get itself.

> So, do any of you still have MinGW.org's GCC-4.8.1 installed?  If so,
> are you willing to accept a procedural instruction to remove its "dev"
> component packages, before upgrading (or rolling back) to any other
> version?  Or otherwise, are you willing to accept, and deal with the
> swathe of "conflict" error diagnostics which mingw-get will emit, if I
> don't engage in the aforementioned XML gymnastics?

Given the lack of response, I'm assuming that you either don't care, or
you don't expect to be affected.  I've tried to keep the likely  fallout
as painless as possible, if you use the GUI interface to mingw-get, and
you follow this upgrade procedure:

1) Update the catalogue, (via the "Installation" menu).

2) Navigate to the

     MinGW
       MinGW Base System
         MinGW Compiler Suite
           GCC Upgrade Blockers

   package category, (in the left hand pane).

3) If any packages, in this category, are marked as "installed", (or
   "installed/upgradeable"), select each one, mark for removal, and
   apply the changes, (again, via the "Installation" menu).

4) Backtrack up the navigation tree, to the "MinGW Compiler Suite",
   (or to "All Packages", if you prefer), select any packages you wish,
   and mark them for upgrade, or installation, as appropriate, (or use
   the "Mark All Upgrades" option, from the "Installation" menu, for a
   blanket upgrade of all previously installed packages), then apply
   the changes once more.

5) Repeat step (2), to revisit the "GCC Upgrade Blockers" category; if
   any packages there show up as "installed" again, (there should be a
   few), then repeat step (3) to remove them again; (they serve only to
   resolve dependencies during installation/upgrade, but will be in the
   way of future upgrades; I plan to modify mingw-get, to remove them
   automatically, following installation/upgrade processing, but for
   the time being we must rely on manual removal).
   
- --
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)

iQIcBAEBAgAGBQJZdeQsAAoJEMCtNsY0flo/aqcQAKwbxGTs1BpLoXupXw5zEYJa
jF1ARz7EGdD1b115AIZ/kOBqmcSuxzC6csnViFRmYDI0/bOHPPCl54k72eIHvYa1
PLiIv8SeMbOG0wqQ1MI+Sh0zvH6D/6mgy59+tbnm49ZEpbNmg0TEe1RkO2LIicQH
EvBDEpT4hjFrcxBiu5ibU+CfEq9I7F4YuIUhiPnXEXzedWMKCE+pIqPwfCYrq3H5
rJkkq8YZPCnifMWGHCm86LhKQdUex+oDeoyeK5U1RuHnfXQzCuVrbOf/v68dimg3
+sDtqFrrZt1j6l/RpVueZmQsoJrTWhetoEMGbEjJJVmxkCbNihITp53NKNEd16ty
853sLB1zcrlVGM21tgsKFZJA8yuVVR61khfQbpiWgHzzXG9q0JZ/m4+P8iVYMmXQ
YtnPb18kwfrwXuBOknJC88DwgwVg88QhS37t14fI/8j4JfcRdNYJ3U/qY+83garB
rwvDB7GEffPmGwvxghXacM0CnrWttorW5ooNL+eSZXWQALgLrXhr6fqPvQmnW71i
j6uNcMNhaBRB7NnIB3FyPktS+JtfR7E00DMMA/HYCcZWm16XymSwrwbCXw0v6yaX
9tp482FgQHvQ6BLYasY8xRkmzkn9g9u5qqWxMBbboxtHev7XKEbAAYZgXP2pachR
SkbcJGE93fjL/mQm0CNF
=PJv4
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get (was: GCC-6 and beyond)

David Gressett-6
on Monday, July 24, 2017 7:12 AM  Keith Marshall wrote:
... snip ..
>> So, do any of you still have MinGW.org's GCC-4.8.1 installed?

... snip ...

Given the lack of response, I'm assuming that you either don't care ...

For me, 4.8.1 is long gone. I'm working on getting 6.4 and 7.1 going.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

MinGW - User mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/07/17 16:21, David Gressett wrote:
> on Monday, July 24, 2017 7:12 AM  Keith Marshall wrote:
> ... snip ..
>>> So, do any of you still have MinGW.org's GCC-4.8.1 installed?
>
> ... snip ...
>
>> Given the lack of response, I'm assuming that you either don't care ...
>
> For me, 4.8.1 is long gone.

But the legacy of its malformed package structure isn't; the catalogues
still require XML gymnastics to circumvent that legacy.  I've reduced
the impact of that somewhat, but at the expense of a requirement for
some manual pre-install, and post-install user intervention.

> I'm working on getting 6.4 and 7.1 going.

I know :-)  Other users may not, and rely on us to furnish these updated
versions.

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

iQIcBAEBAgAGBQJZdhhpAAoJEMCtNsY0flo/xFwP/RPRV3oswmJhPs4du1Q5QcjT
K4C3t6RKz9v+SxlY5UTClI07UwfApPk2Y1VuvPHBz7Xeh5F2T41R8GCc5XFJ7GAs
J0soFnQVqgDqm+adJfEGWwVFBL+byEO0jFLeXdMVY6F+B5VoQuGu91tYogi2SpBB
+OjGPyeQX/qaW0Uw1CQFYe6Qpoco0ZKLxD1kh04Gdn6nE+dPUqJCiw8kcurkgFNz
prR1YbprVdjWShsx9Qy8PpbUtl5/7a+6TwZWESnPp+wPv3/oxfgjbQ04j4mghL81
K9q6J1XSsTnt45G+0q0lyLXH9aoixkpOU0BuufpIR3xA40ZeKlDzAtiy3P8lAq6A
tGcBzM7kNThretBpXCfbWdMuOfg0XyQ9ijI6piMjtdtyn5/tP3TAfQxTC+sryC9l
W3QgnVPL5tNgabaqsBYWnKyZfXa59+/IyU2jYQokd1EoGLP1/ADyLUtEPXNeuFDJ
4AU8J/cXm583tfENf/kiW83I7jvN5E1phiScR+nPDR1IdtenyVsX9RDFX58aPzja
2BMBTtvNeZ7eRpiC2PRQ3uvYYzYBHiitV7yJd/xNfMA3sXZIxpQc19vfgRExRPlJ
rIdCG117X/PybrH0c0kHVO0x6kU/c4UROlx11dwhFbhG1qBwj7wUYMfAE+sKS3IM
Xw4vO26i7PkBNc19NGzD
=OoRJ
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get (was: GCC-6 and beyond)

Jannick
In reply to this post by MinGW - User mailing list
On Mon, 24 Jul 2017 13:12:28 +0100, Keith Marshall via MinGW-users wrote:

> Given the lack of response, I'm assuming that you either don't care, or
you
> don't expect to be affected.  I've tried to keep the likely  fallout as
painless as
> possible, if you use the GUI interface to mingw-get, and you follow this
> upgrade procedure:

Thanks - this is helpful. Was just upgrading the MinGW32 suite to GCC6.

> 1) Update the catalogue, (via the "Installation" menu).

[snip]

> 5) Repeat step (2), to revisit the "GCC Upgrade Blockers" category; if
>    any packages there show up as "installed" again, (there should be a
>    few), then repeat step (3) to remove them again; (they serve only to
>    resolve dependencies during installation/upgrade, but will be in the
>    way of future upgrades; I plan to modify mingw-get, to remove them
>    automatically, following installation/upgrade processing, but for
>    the time being we must rely on manual removal).

Just as a separate note: libmingwex-0.dll appears to be a dependency to GCC6
which GCC6 complains about not to find upon compilation. The GUI interface
to mingw-get does not automatically download it by default, but a manual
installation fixes the issue.  

> Regards,
> Keith.

Best,
J.


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

MinGW - User mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/07/17 09:37, Jannick wrote:
> Just as a separate note: libmingwex-0.dll appears to be a dependency
> to GCC6 ...

You are correct[*].  It was not intended to be so, but is that so bad?  
We have two choices: quickest, and easiest, would be to update the XML
catalogue, to include the dependency; alternatively, I could rebuild the
whole kit and caboodle, to eliminate the dependency, which would take
rather a longer time.

Which would you prefer?

[*]: Checking in my build directory:

$ mingw32-ldd dist/staged/libexec/gcc/mingw32/6.3.0/cc1.exe
dist/staged/libexec/gcc/mingw32/6.3.0/cc1.exe
 +- ADVAPI32.DLL
 +- KERNEL32.dll
 +- libmingwex-0.dll
 |   +- msvcrt.dll
 |   +- msvcrt.dll
 |   +- ADVAPI32.DLL
 |   +- KERNEL32.dll
 +- msvcrt.dll
 +- msvcrt.dll
 +- USER32.dll
 +- libgmp-10.dll
 |   +- libgcc_s_dw2-1.dll
 |   |   +- KERNEL32.dll
 |   |   +- msvcrt.dll
 |   +- KERNEL32.dll
 |   +- msvcrt.dll
 |   +- msvcrt.dll
 +- libiconv-2.dll
 |   +- kernel32.dll
 |   +- msvcrt.dll
 |   +- msvcrt.dll
 +- libisl-15.dll
 |   +- libgcc_s_dw2-1.dll
 |   |   +- KERNEL32.dll
 |   |   +- msvcrt.dll
 |   +- KERNEL32.dll
 |   +- msvcrt.dll
 |   +- msvcrt.dll
 |   +- libgmp-10.dll
 |       +- libgcc_s_dw2-1.dll
 |       |   +- KERNEL32.dll
 |       |   +- msvcrt.dll
 |       +- KERNEL32.dll
 |       +- msvcrt.dll
 |       +- msvcrt.dll
 +- libmpc-3.dll
 |   +- KERNEL32.dll
 |   +- msvcrt.dll
 |   +- libgmp-10.dll
 |   |   +- libgcc_s_dw2-1.dll
 |   |   |   +- KERNEL32.dll
 |   |   |   +- msvcrt.dll
 |   |   +- KERNEL32.dll
 |   |   +- msvcrt.dll
 |   |   +- msvcrt.dll
 |   +- libmpfr-4.dll
 |       +- KERNEL32.dll
 |       +- msvcrt.dll
 |       +- libgmp-10.dll
 |           +- libgcc_s_dw2-1.dll
 |           |   +- KERNEL32.dll
 |           |   +- msvcrt.dll
 |           +- KERNEL32.dll
 |           +- msvcrt.dll
 |           +- msvcrt.dll
 +- libmpfr-4.dll
     +- KERNEL32.dll
     +- msvcrt.dll
     +- libgmp-10.dll
         +- libgcc_s_dw2-1.dll
         |   +- KERNEL32.dll
         |   +- msvcrt.dll
         +- KERNEL32.dll
         +- msvcrt.dll
         +- msvcrt.dll


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

iQIcBAEBAgAGBQJZdx9fAAoJEMCtNsY0flo/0KwP/ik1VELDR4NaLuCInUqSrplk
NOgp1CCrZ9+I18E7KrPu7VruuTOqUbmLyYXanUOKnDPKn5CRfh3OBRc+8NTxLtnI
YTldsKJa9SDEgtfqHYLJncFqNYp1VOF9ziO4wNPRrhGMW8fbuRU9tFWVq4/SNb07
ctU++jVxRAfaVqmCXam8IhcnKEBOxEslNsvgCYGrywmyGU5zUUt0V9ydfnQdI6XH
+lIimQrxxbAxMV7C3TyqhXrFCOctY7T8XL4QRpdafNsujW5NwDuEu0sTgbevELPq
vGhzKkFNw8uAgB272GDZpOPQLE0qAd1ZC7X9+qH2OMNEluwyK3/fD0Wr1tMATD6c
NABkEucWhQxZb+9WP7nkP/tZTN1CBHS9WG1YySa6JQa70MjXmxIdiumnJpMzC6yp
5Y9ixF5M2GR/jUTACaLBAJyPDtxnlHxBYjzkgZqxEI3calcVmbbqv+mgsjDsf306
OgaMSrrgVNI/027CaCA2XqNQns0yneazDv8ADm7ToxuXTcLk5jVBLFsD9z5RABAE
LtOTnL7OBnerEzp4Y8FPXP0CaVoPdnKkqODFyQlU9f0uEvbJ58FalAuU0rEW4xFu
DW81PSTI8GX4B+Ut4tiPIWS4E4jRIWxg+5Gcq985igpCW5xCOKKtFF8pylCDEa4w
AZlafccNpywfIPC5Ps36
=EJlH
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

Jannick
On Tue, 25 Jul 2017 11:37:20 +0100, Keith Marshall via MinGW-users wrote:
> On 25/07/17 09:37, Jannick wrote:
> > Just as a separate note: libmingwex-0.dll appears to be a dependency
> > to GCC6 ...
>
> You are correct[*].  It was not intended to be so, but is that so bad?
> We have two choices: quickest, and easiest, would be to update the XML
> catalogue, to include the dependency; alternatively, I could rebuild the
whole
> kit and caboodle, to eliminate the dependency, which would take rather a
> longer time.
>
> Which would you prefer?

For this GCC version I would go with the easiest solution to change the XML,
of course - and given that the re-compilation sounds like more than a bunch
of lengthy work steps.
 
> Regards,
> Keith.

Best & thank you for all your efforts, Keith,
J.


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

Jannick
On Tue, 25 Jul 2017 13:34:02 +0200, Jannick wrote:

> On Tue, 25 Jul 2017 11:37:20 +0100, Keith Marshall via MinGW-users wrote:
> > On 25/07/17 09:37, Jannick wrote:
> > > Just as a separate note: libmingwex-0.dll appears to be a dependency
> > > to GCC6 ...
> >
> > You are correct[*].  It was not intended to be so, but is that so bad?
> > We have two choices: quickest, and easiest, would be to update the XML
> > catalogue, to include the dependency; alternatively, I could rebuild
> > the
> whole
> > kit and caboodle, to eliminate the dependency, which would take rather
> > a longer time.
> >
> > Which would you prefer?
>
> For this GCC version I would go with the easiest solution to change the
XML,
> of course - and given that the re-compilation sounds like more than a
bunch
> of lengthy work steps.

Just a second: Would that mean that the compiled executables will be
dependent on .dlls even if linked with '-static' - if possible? I must admit
that in the beginning I was assuming that the mentioned .dll is required at
compile time only, but not at runtime. If this was true, this would not what
I wanted to opt for. Would you be able to shed some light on this?

Thanks,
J.


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

Eli Zaretskii
In reply to this post by MinGW - User mailing list
> Date: Tue, 25 Jul 2017 11:37:20 +0100
> From: Keith Marshall via MinGW-users <[hidden email]>
> Cc: Keith Marshall <[hidden email]>
>
> You are correct[*].  It was not intended to be so, but is that so bad?  
> We have two choices: quickest, and easiest, would be to update the XML
> catalogue, to include the dependency; alternatively, I could rebuild the
> whole kit and caboodle, to eliminate the dependency, which would take
> rather a longer time.
>
> Which would you prefer?
>
> [*]: Checking in my build directory:
>
> $ mingw32-ldd dist/staged/libexec/gcc/mingw32/6.3.0/cc1.exe
> dist/staged/libexec/gcc/mingw32/6.3.0/cc1.exe
>  +- ADVAPI32.DLL
>  +- KERNEL32.dll
>  +- libmingwex-0.dll
>  |   +- msvcrt.dll
>  |   +- msvcrt.dll
>  |   +- ADVAPI32.DLL
>  |   +- KERNEL32.dll

If you are going to leave cc1.exe dependent on libmingwex-0.dll,
please put that DLL under libexec, where cc1.exe lives, so that it is
not visible to "normal" MinGW builds, in case people don't want to
link against the DLL by default.  That's what I do here.

Thanks.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

MinGW - User mailing list
On 7/25/2017 10:39 AM, Eli Zaretskii wrote:

>> Date: Tue, 25 Jul 2017 11:37:20 +0100
>> From: Keith Marshall via MinGW-users <[hidden email]>
>> Cc: Keith Marshall <[hidden email]>
>>
>> You are correct[*].  It was not intended to be so, but is that so bad?  
>> We have two choices: quickest, and easiest, would be to update the XML
>> catalogue, to include the dependency; alternatively, I could rebuild the
>> whole kit and caboodle, to eliminate the dependency, which would take
>> rather a longer time.
>>
>> Which would you prefer?
>>
>> [*]: Checking in my build directory:
>>
>> $ mingw32-ldd dist/staged/libexec/gcc/mingw32/6.3.0/cc1.exe
>> dist/staged/libexec/gcc/mingw32/6.3.0/cc1.exe
>>  +- ADVAPI32.DLL
>>  +- KERNEL32.dll
>>  +- libmingwex-0.dll
>>  |   +- msvcrt.dll
>>  |   +- msvcrt.dll
>>  |   +- ADVAPI32.DLL
>>  |   +- KERNEL32.dll
>
> If you are going to leave cc1.exe dependent on libmingwex-0.dll,
> please put that DLL under libexec, where cc1.exe lives, so that it is
> not visible to "normal" MinGW builds, in case people don't want to
> link against the DLL by default.  That's what I do here.
>

Why would making the DLL public from /mingw/bin make it a requirement if
the user uses -static builds?  If the user wants to ensure that the DLL
is never required then removing/renaming libmingwex.dll.a would be more
of the answer than hiding the DLL itself.

Why the aversion to the DLL anyway?  It seems to me that the users would
prefer the DLL in practice.  There is nothing preventing the users from
distributing that DLL with their application binaries.  Is it that
packaging the required DLL needs work?

--
Earnie

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

MinGW - User mailing list
In reply to this post by Eli Zaretskii
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/07/17 15:39, Eli Zaretskii wrote:
> If you are going to leave cc1.exe dependent on libmingwex-0.dll,
> please put that DLL under libexec, where cc1.exe lives, so that it is
> not visible to "normal" MinGW builds,

Why?  The natural location is $MINGW_ROOT/bin, and I've no intention of
building degenerate packages to put it elsewhere.

> in case people don't want to link against the DLL by default.

Why would putting libmingwex-0.dll in $MINGW_ROOT/bin affect them?  If
the compiler flag is -lmingwex, (as it is in the default, built-in, GCC
specs), the linker will look, in $MINGW_ROOT/lib, for libmingwex.dll.a,
mingwex.dll.a, libmingwex.a, libmingwex.dll, and finally mingwex.dll,
in precisely this order, (and will stop at the first matching name it
finds); it will *not* look in $MINGW_ROOT/bin at all, (unless the user
adds that to the library search path), and it will *never* look for the
ABI version qualified libmingwex-0.dll, (unless the user specifies that
library name explicitly).  So, unless you've exercised the option to
install the "libmingwex-dev" package, (which installs libmingwex.dll.a
into $MINGW_ROOT/lib), the issue you perceive simply will not arise.

> That's what I do here.

That's your prerogative, but it's non-standard, and unnecessary.

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

iQIcBAEBAgAGBQJZd3XbAAoJEMCtNsY0flo/i7YP/iX6X6vu4IOWOQzhw/y8KS17
m2sHhuNotScO2wK90OLx4OrYuuwq8dOkFNUnaqAJNj27ii1g+xGiuORz5jYzrFYO
19sJDnhbz4ctzlIE8/eXUL1kceqIa2ym2J4IBiFKSw+xuSZMV1Fi/IepcYxLyYNX
qdd9TnFCEyYKE+PpR8+RwWM1fgfzRFb5m7XQOtl49FgyEG6e8b+7Anlts1J/Jjq1
r/gvRNmCpfqmksr8zWemiTEbTSqpKiFJfSYAW0mB9gF48Z7UzbqQIKd6UZuMYibH
0E7w+ih4w/BmfsaQM4PfW0eYJa22ft3yCv4cCT1H1V6M/q+BBbmeyShA0lQsyEM0
J5UAWp8HTnFurhLwPMdaacyt/+YTJtTfcRlKsO1uACmiFSr6c12LWgiKZ31/lhCC
aJwtPBJniEvFVxLAchoSmop1B/KKhIprnpl1YlkHVMoSgtixCuAfVQVlVySR3TNp
lqGzJ/ubDfiUpX+rX5MlURD5LXU+xzuzYYFb67q5eZ3umjCX0ORWrHVRYZTlp7n0
aSdgD9YYR5JIXe4Srh8KSzjIHCboUYrAygee5aCs7GLW4ykxmut4PN79/xMGsM93
8Vix384bOjNd0JPP+0mE23T51mbn4BnlOni3OSnJ5vGNitZS1lKVXReRLpI637uM
50KEHJThfCpBXsR9Jyxg
=z+OV
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

MinGW - User mailing list
In reply to this post by Jannick
On 7/25/2017 10:08 AM, Jannick wrote:

> On Tue, 25 Jul 2017 13:34:02 +0200, Jannick wrote:
>> On Tue, 25 Jul 2017 11:37:20 +0100, Keith Marshall via MinGW-users wrote:
>>> On 25/07/17 09:37, Jannick wrote:
>>>> Just as a separate note: libmingwex-0.dll appears to be a dependency
>>>> to GCC6 ...
>>>
>>> You are correct[*].  It was not intended to be so, but is that so bad?
>>> We have two choices: quickest, and easiest, would be to update the XML
>>> catalogue, to include the dependency; alternatively, I could rebuild
>>> the
>> whole
>>> kit and caboodle, to eliminate the dependency, which would take rather
>>> a longer time.
>>>
>>> Which would you prefer?
>>
>> For this GCC version I would go with the easiest solution to change the
> XML,
>> of course - and given that the re-compilation sounds like more than a
> bunch
>> of lengthy work steps.
>
> Just a second: Would that mean that the compiled executables will be
> dependent on .dlls even if linked with '-static' - if possible? I must admit
> that in the beginning I was assuming that the mentioned .dll is required at
> compile time only, but not at runtime. If this was true, this would not what
> I wanted to opt for. Would you be able to shed some light on this?
>

Using the -static would use the static version of the library in your
builds.  But what is the aversion to supplying libmingwex-0.dll with
your packaged applications?

--
Earnie

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

MinGW - User mailing list
In reply to this post by MinGW - User mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/07/17 17:44, Earnie via MinGW-users wrote:
> Why would making the DLL public from /mingw/bin make it a requirement
> if the user uses -static builds?

It wouldn't; see my earlier reply to Eli's post, (which was sent at
almost the same time as yours).

> If the user wants to ensure that the DLL is never required then
> removing/renaming libmingwex.dll.a would be more of the answer than
> hiding the DLL itself.

Or simply doesn't install it, in the first place.  It isn't included
in the standard mingwrt development kit; it requires an explicit user
choice to install the auxiliary libmingwex development kit.  This is
entirely optional, and without it, static libmingwex.a will be used.

Installing $MINGW_ROOT/bin/libmingwex-0.dll, to support applications
which require it, is orthogonal to making it the default for end user
built applications.

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

iQIcBAEBAgAGBQJZd3p8AAoJEMCtNsY0flo/W5sP/iw5h2fHMSeODK+n4E6J6/RJ
w+T4sUDpcnz1xr+XSJ4MMpGwZsD71KOMbLLXb+iPRgmr/HAtcSkbh7qYCdSYlUdG
a4YAUUuYdMa5WwjECo/KuGGPMWClD1Ra5CQMSZnhLlqxS+jogCcT+IBbphcEDSUX
sGxfzo36aiAdUynvIlt4TICCErx/zrn/t5ZCMQZqbBGwTODnVWaVm5tG48nirJkb
mB/0UXrFt3j+Hwb9i2jEkn+UvlvV8BoLHRCrcSV0cAhCp5S06+Vp0YDPas0Ncsu2
ghxpIn5EXuYaE/DmReuGiXZV7C3Va68zpzrcBBYt6ESOQAIi+KSWLY0M1z2LctoT
/0oe5+2ZdSkury3B8R1u5AELfOCXvq6UWi1qGJJxp/k2r0It3nMTd663kQ6Fblec
04yedFwszZhWjG4/aHNhwa6TxW/1YetC+oX2vxraVSMjYMJJTscv0oGBvjBXBo+a
XNdncfdt1icKXuQ9X0mGcJIegMMvOt0Qmm3o5NjRDj3LyrEKVP0pIvyJ2Ahos/vk
7pJ2f/46w4ShjGNyS1PxxMMQkKIo6dYX0wJtVKvKChLC81Kgr+qqpaSaWFAgVp94
NhKbi3PZbNnOa7DojxXGcbikStmcqlNQ9NlSrL0mBs3QRsRi1VhnpwVuR0nY5OEz
8+NpgMq0aOmwgwH2HzxZ
=WcKM
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

Eli Zaretskii
In reply to this post by MinGW - User mailing list
> Date: Tue, 25 Jul 2017 12:44:34 -0400
> From: Earnie via MinGW-users <[hidden email]>
> Cc: Earnie <[hidden email]>
>
> > If you are going to leave cc1.exe dependent on libmingwex-0.dll,
> > please put that DLL under libexec, where cc1.exe lives, so that it is
> > not visible to "normal" MinGW builds, in case people don't want to
> > link against the DLL by default.  That's what I do here.
> >
>
> Why would making the DLL public from /mingw/bin make it a requirement if
> the user uses -static builds?  If the user wants to ensure that the DLL
> is never required then removing/renaming libmingwex.dll.a would be more
> of the answer than hiding the DLL itself.

I didn't say it was a requirement.  But having a DLL on PATH that is
actually needed only by executables that are not on PATH means you are
a step closer than necessary to a DLL hell.  It doesn't seem
economical to me, and it makes system maintenance a tad more complex.

> Why the aversion to the DLL anyway?  It seems to me that the users would
> prefer the DLL in practice.  There is nothing preventing the users from
> distributing that DLL with their application binaries.  Is it that
> packaging the required DLL needs work?

See above.  In addition, distributing such executables might mean one
has to make the source of the DLL available nearby, which is one more
hassle.  Maybe in this case it isn't so, but your question was a
general one.  E.g., a dependency on the libgcc DLL is a _major_
hassle, because you need to make the entire GCC source tarball
available, per the GPL.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

Eli Zaretskii
In reply to this post by MinGW - User mailing list
> Date: Tue, 25 Jul 2017 17:46:20 +0100
> From: Keith Marshall via MinGW-users <[hidden email]>
> Cc: Keith Marshall <[hidden email]>
>
> > If you are going to leave cc1.exe dependent on libmingwex-0.dll,
> > please put that DLL under libexec, where cc1.exe lives, so that it is
> > not visible to "normal" MinGW builds,
>
> Why?  The natural location is $MINGW_ROOT/bin, and I've no intention of
> building degenerate packages to put it elsewhere.

I don't see why this makes the package degenerate in any sense of the
word.  If anything, cc1.exe will load a bit faster, and nothing else
will suffer.  What am I missing here?

> > That's what I do here.
>
> That's your prerogative, but it's non-standard, and unnecessary.

I think compartmentalizing DLLs that are only needed by programs not
on PATH makes a system that is safer and less complex to maintain.
But it's okay to disagree, as I always can move the DLL after
installing the package.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

MinGW - User mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/07/17 19:26, Eli Zaretskii wrote:

>> Date: Tue, 25 Jul 2017 17:46:20 +0100
>> From: Keith Marshall via MinGW-users <[hidden email]>
>>> If you are going to leave cc1.exe dependent on libmingwex-0.dll,
>>> please put that DLL under libexec, where cc1.exe lives, so that it is
>>> not visible to "normal" MinGW builds,
>>
>> Why?  The natural location is $MINGW_ROOT/bin, and I've no intention of
>> building degenerate packages to put it elsewhere.
>
> I don't see why this makes the package degenerate in any sense of the
> word.  If anything, cc1.exe will load a bit faster, and nothing else
> will suffer.  What am I missing here?

It makes the package degenerate because libmingwex-0.dll is *not* part
of GCC ... it is an optional part of mingwrt, (or MinGW.org WSL, if you
consider it to be a part of our w32api/mingwrt composite).  As such, its
natural installation path is somewhere within /mingw/{bin,include,lib},
*not* hidden away in some GCC private directory.

And yes, if it were to be hidden away in a private GCC directory, it
*would* break *any* user-built application, where the user has exercised
the option to link against libmingwex.dll.a, and that application is
then installed, as a standard MinGW-built application, in /mingw/bin.

> But it's okay to disagree, as I always can move the DLL after
> installing the package.

Sure.  For the convenience of users who prefer to use mingw-get to
manage their installations, and who may wish to link libmingex-0.dll
into their own applications too, I will package it for installation
as $MINGW_ROOT/bin/libmingwex-0.dll.  I know you don't use mingw-get
anyway, and as you say, you can always move it anywhere else you may
prefer to put it.

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

iQIcBAEBAgAGBQJZd5kbAAoJEMCtNsY0flo/RCIQAMnnzE+55wuSqdas3WlZ04E/
Fg6t3R09+jOtneAHsQRF7weh2FCPcf1/TQ3WLrzOzcd9M8DN5qihhDKP7dXh3S6K
oo1YKlj3lL3eeAxSvPw2LfylN2SemCQQ54cF5hK3GYddk8CpUSQD9BZZgiki7li5
2TVJoRkZx6+/DopBdouhp3GpvDJSZeY790U5T496iZTD4Vg9dDpGYosA20xaZqg5
H+NRwi/btqndS6WsG6d3EBrCUMEVOlwbuRuvYABoUmL7YzNbPEB3pBs1CFpfy86Y
jjtjZosKUwKBjMwGrfzbCYOmG61EvDcKGkbzuwQjqB8QLQalCtntmpf3sP0tfBu4
j6mBKtmsBcG818/7DwOXCfAOeOxe2Jw7EVFc88dAnxle0PHii2CShiduM9HaoJnG
UFuUTS8JjG+KPcrINxVJOCCBesovtng6Wq3Mj89afC9WVTnGvq78Yr+AWp1R18ED
dRMnasnvwVUvZTzsbQY2TKWwyx0Um6Ic7fmL1tLTf9WWWEoUH6hfvLscFGzJ35Zu
tvHSzOmUydqq461t4c+viQlfkVdi+zdjneTxgcSKzE9HAS8x5MdZLIvQxl9GGx/l
K1YJPJ1eJpEt+d4ozOSkb/Ph4JSfoph9cbA+2O/DP2IpM6ebg7hcyEirpwvtJ3qt
mXeQqG8hrt6UeiYpxm8W
=JmMN
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

MinGW - User mailing list
In reply to this post by Eli Zaretskii
On 7/25/2017 2:21 PM, Eli Zaretskii wrote:

>> From: Earnie via MinGW-users <[hidden email]>
>>
>> Why the aversion to the DLL anyway?  It seems to me that the users would
>> prefer the DLL in practice.  There is nothing preventing the users from
>> distributing that DLL with their application binaries.  Is it that
>> packaging the required DLL needs work?
>
> See above.  In addition, distributing such executables might mean one
> has to make the source of the DLL available nearby, which is one more
> hassle.  Maybe in this case it isn't so, but your question was a
> general one.  E.g., a dependency on the libgcc DLL is a _major_
> hassle, because you need to make the entire GCC source tarball
> available, per the GPL.
>

Well the distribution of software source is a prerequisite to most of
the open source binaries you might distribute.  Requiring the source
distribution for a binary distribution is what GNU is about.  The
aversion to that would be to choose to not use open source.  But I know
you know that already so I'm stating this for those who might stumble on
this post.  I will also state that distributing libmingex-0.dll does not
have the GPL restriction to distribute its source as its license isn't
covered by the GPL.

--
Earnie

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GCC-6.3 now available via mingw-get

Eli Zaretskii
> Date: Wed, 26 Jul 2017 09:27:47 -0400
> From: Earnie via MinGW-users <[hidden email]>
> Cc: Earnie <[hidden email]>
>
> > See above.  In addition, distributing such executables might mean one
> > has to make the source of the DLL available nearby, which is one more
> > hassle.  Maybe in this case it isn't so, but your question was a
> > general one.  E.g., a dependency on the libgcc DLL is a _major_
> > hassle, because you need to make the entire GCC source tarball
> > available, per the GPL.
> >
>
> Well the distribution of software source is a prerequisite to most of
> the open source binaries you might distribute.  Requiring the source
> distribution for a binary distribution is what GNU is about.  The
> aversion to that would be to choose to not use open source.  But I know
> you know that already so I'm stating this for those who might stumble on
> this post.  I will also state that distributing libmingex-0.dll does not
> have the GPL restriction to distribute its source as its license isn't
> covered by the GPL.

I gave a specific (though a bit extreme) example of libgcc, when using
a very small library that isn't even directly called by the program
anywhere, requires one to provide the entire multi-megabyte GCC source
tarball (and do that for every version of GCC used to build some of
the binaries).  I think you can understand why avoiding that might be
desirable.

And with some libraries (again, probably not with libmingex), you have
a good chance of getting your users into a small DLL hell, e.g., if a
library by the same name is produced by different toolchains in a way
that makes the results incompatible.  And even if they are compatible,
unpacking an archive with a DLL when there is already a DLL by that
name will scare many users, and I can understand them.

IME, linking against DLLs only makes sense when those DLLs implement
part of the program's required functionality.  Dependencies which you
"inherit" because the compiler forces this on you (e.g., like g++
forces the dependency on libstdc++) are to be avoided if you want to
allow your users easy installation and upgrades.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Loading...