Bug 222373 - lang/gcc46, lang/gcc47, lang/gcc48, lang/gcc49: Mark DEPRECATED and set EXPIRATION_DATE
Summary: lang/gcc46, lang/gcc47, lang/gcc48, lang/gcc49: Mark DEPRECATED and set EXPIR...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Gerald Pfeifer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-16 18:57 UTC by Yasuhiro KIMURA
Modified: 2017-10-04 20:47 UTC (History)
1 user (show)

See Also:


Attachments
patch file (1.65 KB, patch)
2017-09-16 18:57 UTC, Yasuhiro KIMURA
no flags Details | Diff
updated patch file (1.64 KB, patch)
2017-09-16 21:41 UTC, Yasuhiro KIMURA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yasuhiro KIMURA 2017-09-16 18:57:25 UTC
Created attachment 186435 [details]
patch file

Mark DEPRECATED and set EXPIRATION_DATE to unsupported version of GCC.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2017-09-16 20:04:48 UTC
Unfortunately gcc49 is the latest version that I can get to work properly on sparc64.  All later versions segfault as soon as they try to invoke the first-built binary.

So I would like to request gcc49 stay for now.
Comment 2 Yasuhiro KIMURA 2017-09-16 21:41:03 UTC
Created attachment 186439 [details]
updated patch file

(In reply to Mark Linimon from comment #1)

Update patch so

* DEPRECATE lang/gcc49 only when ${ARCH} is not "sparc64".
* Don't set EXPIRATION_DATE to lang/gcc49.

So please commit attached patch instead of original one.
Comment 3 Gerald Pfeifer freebsd_committer 2017-09-17 19:13:39 UTC
As Mark noted not only do we need to retain lang/gcc49 for the sake
of SPARC, but there are explicit dependencies on lang/gcc48 in the tree:

audio/beast/Makefile:USE_GCC=	4.8
devel/api-sanity-autotest/Makefile:USE_GCC=	4.8 # same as devel/elfutils
devel/elfutils/Makefile:USE_GCC=	4.8	# fails to build with newer versions
graphics/blender/Makefile:USE_GCC=	4.8+
news/nget/Makefile:USE_GCC=	4.8
sysutils/memtest86+/Makefile:USE_GCC=	4.8
sysutils/uefi-edk2-bhyve/Makefile:USE_GCC=	4.8

In the past I have been more aggressive purging older versions of these
ports, but I got strong feedback by some that they prefer to retain those
and gcc46 and 47 have been very little effort (nor seen many problem
reports over the last year or two).

That said, GCC 4.6 was first released in March 2011 and that release
branch was closed in April 2013, and it has been requiring some effort
(e.g., files/patch-gcc-doc-gcc.texi), so it does seem time to wrap it up
four-and-a-half years later.

I'll commit a patch to that extent in a minute.
Comment 4 commit-hook freebsd_committer 2017-09-17 19:33:21 UTC
A commit references this bug:

Author: gerald
Date: Sun Sep 17 19:32:17 UTC 2017
New revision: 450021
URL: https://svnweb.freebsd.org/changeset/ports/450021

Log:
  Mark DEPRECATED with an EXPIRATION_DATE of 2017-11-30 [1] since this
  version of GCC has not been maintained upstream for nearly four-and-a-half
  years and is not used anywhere in the tree.

  Move ONLY_FOR_ARCHS to its appropriate place.

  PR:		222373 [1]
  Submitted by:	Yasuhiro KIMURA <yasu@utahime.org> [1]

Changes:
  head/lang/gcc46/Makefile
Comment 5 Gerald Pfeifer freebsd_committer 2017-09-17 19:38:46 UTC
Note that I set an expiration date two-and-a-half months from now; going
for a full half year felt a little much.

Also note that I did bump PORTREVISION to make sure users are notified.


Would you like to see the similar change for lang/gcc47?

As Mark and me explained, lang/gcc48 and lang/gcc49 are still necessary,
though marking them as DEPRECATED without an EXPIRATION_DATE is something
we can do. 

Perhaps I should ask: What is your motivation to see those changes?
Understanding that may help guide (additional) appropriate steps...
Comment 6 Yasuhiro KIMURA 2017-09-17 22:16:19 UTC
(In reply to Gerald Pfeifer from comment #5)

In summer of 2013 my friend wrote an application. It was written for some minor and specific purpose but was very useful at least for him and me. I tried to build the source code on my FreeBSD 8.3(?) PC with base system compiler but it failed. When I asked him he said maybe version of compiler was too old and he used GCC 4.8 to compile it. So I installed lang/gcc48 from ports, tried build with it and succeeded.

I continued to use the application. Each time when FreeBSD is major updated I reinstalled OS, install lang/gcc48 and build the source code.

And last Monday the author suddenly told me he update the application. He also said he almost rewrite it. I get source code and tried to build it with GCC 4.8 but it failed. When I asked him again he said new version requires more modern compiler. I tried base system compiler of 11.1-RELEASE but it didn't work well again. So I installed lang/gcc7 and use it. Then 3rd trial succeeded.

While installing GCC 7 I checked home page of GCC and learned GCC 4.x is not supported anymore. And I wondered if these old versions are still necessary.

That is why I submitted this PR. Very long but far from serious. Sorry. So I am not necessarily stuck with removing these ports. But marking lang/gcc4[789]  as DEPRECATED and bump PORTREVISION may be good idea because it lets users of these ports know they are now unsupported and promotes their migration to newer version of GCC.
Comment 7 Gerald Pfeifer freebsd_committer 2017-10-04 20:33:41 UTC
Thank you for the detailed background, Yasuhiro-san.  This is good to
understand, it's a glimpse into the situation and needs of our users,
which is unvaluable.

I will shortly apply patches for the other lang/gcc4* ports per your
recommendation.  (One change I'll make is to do so for lang/gcc49
unconditionally, also on sparc64, given that we're omitting the
expiration date now.)
Comment 8 commit-hook freebsd_committer 2017-10-04 20:36:31 UTC
A commit references this bug:

Author: gerald
Date: Wed Oct  4 20:36:14 UTC 2017
New revision: 451246
URL: https://svnweb.freebsd.org/changeset/ports/451246

Log:
  Add deprecation notes for lang/gcc47, lang/gcc48, and lang/gcc49,
  but no expiration date at this point (since at least the latter two
  still have users in the ports tree and sparc64 relies on the latter).

  PR:		222373
  Submitted by:	Yasuhiro KIMURA <yasu@utahime.org>

Changes:
  head/lang/gcc47/Makefile
  head/lang/gcc48/Makefile
  head/lang/gcc49/Makefile
Comment 9 Gerald Pfeifer freebsd_committer 2017-10-04 20:47:42 UTC
Thank you for your contribution!