Bug 196712 - exp-run: Update lang/gcc from GCC 4.8 to GCC 4.9
Summary: exp-run: Update lang/gcc from GCC 4.8 to GCC 4.9
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Gerald Pfeifer
Depends on: 192025 196850 196853 196854 196855 196856 196912 196913 196914 196915 197889 197890 197891 197892 197893 197894 197895 197896 197897 197898 197901 197903 197905 197906 197908 197909 204150 204181 204384 204385 204387 204390 204395 204400 204461 212364 214863
Blocks: 214413 216707
  Show dependency treegraph
Reported: 2015-01-14 09:24 UTC by Gerald Pfeifer
Modified: 2017-02-04 08:51 UTC (History)
8 users (show)

See Also:

Patchset for Mk/bsd.gcc.mk, Mk/bsd.default-versions.mk, and lang/gcc (6.42 KB, patch)
2015-01-14 09:24 UTC, Gerald Pfeifer
no flags Details | Diff
v2 of the patchset (6.21 KB, patch)
2015-02-22 17:30 UTC, Gerald Pfeifer
no flags Details | Diff
Patch to fix OpenEXR depends (2.79 KB, patch)
2015-04-08 00:30 UTC, Dmitry Marakasov
no flags Details | Diff
Patch to fix OpenEXR depends (4.17 KB, patch)
2015-04-08 21:40 UTC, Dmitry Marakasov
no flags Details | Diff
v3 of the patch set. (6.54 KB, patch)
2015-10-24 12:05 UTC, Koop Mast
no flags Details | Diff
v4 of the patch set (18.08 KB, text/plain)
2016-11-01 21:23 UTC, Gerald Pfeifer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald Pfeifer freebsd_committer 2015-01-14 09:24:15 UTC
Created attachment 151613 [details]
Patchset for Mk/bsd.gcc.mk, Mk/bsd.default-versions.mk, and lang/gcc

Can you please review this (a second pair of eyes always is good) and
do an -exp run?
Comment 1 Antoine Brodin freebsd_committer 2015-01-14 18:27:24 UTC
Take for exp-run
Comment 2 Antoine Brodin freebsd_committer 2015-01-15 07:13:33 UTC
This line has to be changed too:

Mk/Uses/fortran.mk:21:.if ${_GCC_VER} == 48
Comment 3 Antoine Brodin freebsd_committer 2015-01-16 13:24:39 UTC
New failures on freebsd 10.1,  qemu,  x49gp and nhc98 are i386 specific:

Comment 4 Antoine Brodin freebsd_committer 2015-01-18 20:18:41 UTC
New failures on 9.3,  gnu-efi and dolphin-emu are amd64 only,  nhc98 is i386 only:

Comment 5 commit-hook freebsd_committer 2015-01-18 22:24:38 UTC
A commit references this bug:

Author: gerald
Date: Sun Jan 18 22:23:45 UTC 2015
New revision: 377353
URL: https://svnweb.freebsd.org/changeset/ports/377353

  Require building with GCC 4.8 due to non-conforming C++ code.

  PR:		196849, 196712

Comment 6 Antoine Brodin freebsd_committer 2015-01-18 22:29:10 UTC
On freebsd 9.3,  half of the failures look like this:

/usr/local/lib/libIlmImf.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'

graphics/OpenEXR has USE_GCC if cc is gcc 4.2
Comment 7 commit-hook freebsd_committer 2015-01-18 22:49:41 UTC
A commit references this bug:

Author: gerald
Date: Sun Jan 18 22:49:06 UTC 2015
New revision: 377368
URL: https://svnweb.freebsd.org/changeset/ports/377368

  Fails to build with newer versions of GCC (4.9 and above) due to
  non-compliant C++ code.

  PR:		196852, 196712

Comment 8 commit-hook freebsd_committer 2015-01-18 23:52:48 UTC
A commit references this bug:

Author: gerald
Date: Sun Jan 18 23:52:35 UTC 2015
New revision: 377374
URL: https://svnweb.freebsd.org/changeset/ports/377374

  Change USE_GCC=4.8+ to USE_GCC=4.8 since files/patch-Make.defaults
  actually hard-codes 48.

  PR:		196712

Comment 9 commit-hook freebsd_committer 2015-01-19 23:59:02 UTC
A commit references this bug:

Author: gerald
Date: Mon Jan 19 23:58:40 UTC 2015
New revision: 377489
URL: https://svnweb.freebsd.org/changeset/ports/377489

  USE_GCC=any was a lie, nail down to GCC 4.8 as the latest version
  that will build this on FreeBSD 10 and later (without GCC). [1]

  On the way remove an instance of @dirrm from pkg-plist.

  PR:		196913 [1], 196712 [1]

Comment 10 Gerald Pfeifer freebsd_committer 2015-01-20 00:17:46 UTC
Okay, so I am now through all failures on FreeBSD 10.1 (comment #3),
making workaround in some ports and filing a PR for every issue.
Comment 11 Gerald Pfeifer freebsd_committer 2015-02-22 01:12:04 UTC
(In reply to Antoine Brodin from comment #4)
> http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/fr-aster-

This looks like a false positive to me.  No reference to USE_GCC
or USES=compiler, and the error is not indicative of anything
related to GCC or clang.
Comment 12 Gerald Pfeifer freebsd_committer 2015-02-22 01:25:06 UTC
(In reply to Antoine Brodin from comment #6)
> On freebsd 9.3,  half of the failures look like this:
> /usr/local/lib/libIlmImf.so: undefined reference to 
> `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'
> graphics/OpenEXR has USE_GCC if cc is gcc 4.2

Yes, and all those ports using OpenEXR libraries, but not USE_GCC=yes
then use an older compiler and older run-time libraries -- and fail.
Painful. :-(
Comment 13 Gerald Pfeifer freebsd_committer 2015-02-22 02:08:48 UTC
Okay, now I made it through all failures on 9.1 as well, reporting a
bug for anything that was not failed based on the 10.1 run already.
17 new bugs altogether.
Comment 14 Matthias Andree freebsd_committer 2015-02-22 09:59:06 UTC
(In reply to Gerald Pfeifer from comment #12)
Is there anything that OpenEXR could do about the problem?  I think the proper way is to make OpenEXR use the default/canonical ports GCC (base gcc 4.2 is too bitrotted) and the slave ports, too?
Comment 15 Gerald Pfeifer freebsd_committer 2015-02-22 16:41:28 UTC
(In reply to Matthias Andree from comment #14)
> Is there anything that OpenEXR could do about the problem?  I think the
> proper way is to make OpenEXR use the default/canonical ports GCC (base
> gcc 4.2 is too bitrotted) and the slave ports, too?

Yes, I'm afraid this is the only practical approach: have OpenExr and
those ports linkedits libraries be built the same manner.

Instead of the current approach, USES=compiler:c++11-lang might be
shorter and somewhat more general?  Would that be worth a try?
Comment 16 Gerald Pfeifer freebsd_committer 2015-02-22 17:30:40 UTC
Created attachment 153323 [details]
v2 of the patchset
Comment 17 Dmitry Marakasov freebsd_committer 2015-02-23 22:05:22 UTC
I've tried adding compiler:c++11-lang to my ports which depend on OpenEXR and are failing with gcc4.9, but it didn't work out of box - I guess because OpenEXR uses custom logic (.if ${COMPILER_TYPE} == gcc ...). However, everything compiles fine if OpenEXR is switched to compiler:c++11-lang as well.

So as I see it, the choice is to either switch OpenEXR and its consumers to compiler:c++11-lang, or duplicate OpenEXR compiler selection logic in all consumers. I'd obviously prefer the former.

Another thing worries me: if I'm not mistaken (I may be, haven't rechecked), on < 10.x c++11-lang brings in clang, but c++11-lib brings in gcc. If that's the case, we may step into the same problem again as soon as some OpenEXR consumer requires c++11-lib. In that case it'll again be built with different compiler than OpenEXR which may lead to more linking failures. That said, I'd prefer to just switch everything to compiler:c++11-lib.
Comment 18 Matthias Andree freebsd_committer 2015-02-27 00:33:59 UTC
(In reply to Dmitry Marakasov from comment #17)
The only hope for C++ ports is to go with the default compiler's Standard C++ library.  Anything else goes out of hand and becomes unmanageable, because as soon as some other C++ library comes into play, it will also use the default compiler's Standard C++ library.  The compiler is secondary - except if it brings in its run-time library.

That means, on 8 and 9 we need to use GCC's libstdc++, and on 10 and newer for clang-enabled architectures, we need to use clang's libc++.

I don't mind using c++11-lang, but whether we use it or not, if a port switches the default C++ standard library, it's broken.

I am wondering if we need a mechanism to that a depending port can inherit some information from a requisite port, so that OpenEXR users could automatically pull in the proper newer GCC libraries.  Gerald?
Comment 19 commit-hook freebsd_committer 2015-02-28 11:56:46 UTC
A commit references this bug:

Author: gerald
Date: Sat Feb 28 11:56:25 UTC 2015
New revision: 380135
URL: https://svnweb.freebsd.org/changeset/ports/380135

  If building with GCC, force the use of a current version, since some
  dependencies do that now and the old GCC 4.2 system compiler fails to
  link with those.

  PR:		197907, 196712
  Submitted by:	FreeBSD@ShaneWare.Biz (maintainer)

Comment 20 Dmitry Marakasov freebsd_committer 2015-03-03 13:54:00 UTC
(In reply to Matthias Andree from comment #18)
> That means, on 8 and 9 we need to use GCC's libstdc++, and on 10 and newer for clang-enabled architectures, we need to use clang's libc++.

Yes. compiler:c++11-lib does that. I'd prefer it to be used for all ports by default, actually.
Comment 21 Dmitry Marakasov freebsd_committer 2015-03-05 15:48:16 UTC
So, Matthias, could we just switch OpenEXR to USES=compiler:c++11-lib to simplify things?
Comment 22 Matthias Andree freebsd_committer 2015-03-11 21:36:13 UTC
I fear this is overspecifying what we need. I don't need a C++11 compiler nor standard library, I only need to avoid a particular compiler shortcoming:

# If default compiler is GCC, upgrade it because
# g++ 4.2 is too old to auto-upgrade 0xffffffffffffffffl to
# a long long integer constant

And I would like to avoid inheriting future additions of requisite libraries or stuff if the framework changes.
Comment 23 Dmitry Marakasov freebsd_committer 2015-03-17 16:45:16 UTC
> And I would like to avoid inheriting future additions of requisite libraries or stuff if the framework changes.

The standard is not going to change, so there's no way any additional dependencies are added. As far as I remember, our discussion on IRC ended with you testing that c++11-lib actually does the thing. Also as I remember you didn't like that c++11-lib makes a false impression of that a port uses c++11. If that's still critical, will USES=compiler:modern or compiler:non-base thingy (which still does the same as compiler:c++11-lib) solve it?
Comment 24 Matthias Andree freebsd_committer 2015-03-17 22:26:13 UTC
Dmitri's recollection of the IRC conversation is correct. 

Is there a way I can use whichever newer compiler (i. e. "anything but base gcc 4.2") without pulling in additional link requisites, and tell that "whichever newer compiler" to use the base libstdc++ or libc++ whichever the system brings?
(I'm wondering if that is at all possible due to the necessary compiler support library that might be inseparable from the compiler output.)

For OpenEXR that "newer GCC with old libs" would probably suffice, and it would then avoid the need for additional requisites, dependencies, whatever, in the ports that /use/ (depend on) OpenEXR.

So, what is the magic incantation for "use a newer compiler but the base libs"? Newer does not mean C++11...
Comment 25 Matthias Andree freebsd_committer 2015-03-17 22:30:57 UTC
(Dmitry, I am also offering my apologies should the spelling of your name have offended you - this was not my intention. Sorry about that. BTW, is the original spelling Дмитрий?)
Comment 26 Gerald Pfeifer freebsd_committer 2015-03-21 14:47:55 UTC
PR 196851 now has a workaround and does not block any longer.
Comment 27 Gerald Pfeifer freebsd_committer 2015-03-21 14:51:07 UTC
Restore dependency on PR 196913 that was fixed already, now that I am
tracking "blocked" and "related" differently.
Comment 28 Gerald Pfeifer freebsd_committer 2015-03-21 14:52:54 UTC
PR 196857 is also related, and has a workaround in place (so does not block).
Comment 29 Dmitry Marakasov freebsd_committer 2015-03-30 20:40:03 UTC
(In reply to Matthias Andree from comment #24)

> Is there a way I can use whichever newer compiler (i. e. "anything but base
> gcc 4.2") without pulling in additional link requisites, and tell that
> "whichever newer compiler" to use the base libstdc++ or libc++ whichever the
> system brings?

Um, I'm not sure that's possible. As I understand, newer gcc from ports always bring their own libstdc++.

> (Dmitry, I am also offering my apologies should the spelling of your name
> have offended you - this was not my intention. Sorry about that. BTW, is the
> original spelling Дмитрий?)

There's absolutely no problem - there could be multiple translations, and though I use Dmitry, I don't really care what others use. Yes, it's originally Дмитрий.
Comment 30 Dmitry Marakasov freebsd_committer 2015-04-03 20:21:00 UTC
I've just had an idea suggested by this commit:


We could just use clang on < 10.x, which doesn't bring neither libc++ nor newer libstdc++. I'm currently testing.
Comment 31 Dmitry Marakasov freebsd_committer 2015-04-03 21:51:47 UTC
Partial success; 9.x is fine, but llvm36 is broken on 8.x. I'm currently retrying with llvm34. Also I'm worried about ABI incompatibility.
Comment 32 Matthias Andree freebsd_committer 2015-04-04 07:47:07 UTC
Regarding ABI, it would probably be good to try a C++ software that is itself GCC compiled but uses a clang-compiled OpenEXR, and see if OpenEXR-related functions still work (but do not crash).
Comment 33 Dmitry Marakasov freebsd_committer 2015-04-06 02:02:50 UTC
No success with clang34 unfortunately: it doesn't compile OpenEXR:


Which means that we'll have to wait 3 more months till 8.x EOL or find another solution.
Comment 34 Gerald Pfeifer freebsd_committer 2015-04-06 10:53:21 UTC
(In reply to Dmitry Marakasov from comment #33)
> Which means that we'll have to wait 3 more months till 8.x EOL or 
> find another solution.

Can we just go ahead and copy what OpenEXR uses into its dependent

I submitted this update in January, and still more than half of the
broken ports have not been addressed. :-(
Comment 35 Dmitry Marakasov freebsd_committer 2015-04-06 16:45:37 UTC
(In reply to Gerald Pfeifer from comment #34)
> Can we just go ahead and copy what OpenEXR uses into its dependent

I'm strictly against that.
Comment 36 Matthias Andree freebsd_committer 2015-04-07 00:37:15 UTC
(In reply to Dmitry Marakasov from comment #33)
You may need to add new binutils, too...
Comment 37 Dmitry Marakasov freebsd_committer 2015-04-08 00:29:36 UTC
> You may need to add new binutils, too...

USE_BINUTILS doesn't work. Maybe linker should be explicitly forced in some way.

However. (Now I'm not really sure why haven't we started with this.) Why haven't you tried to just fix OpenEXR with old gcc? I've just tried and succeeded, two simple changes are required: changing l constants to ull which they should've been, and disabling SSE on < 10.x (it doesn't seem to have support for it). 

With these changes OpenEXR builds fine on 8, 9, 10, 11 i386 and amd64, all tests pass, dependent ports build fine as well (only tried my lprof-devel and nvidia-texture-tools for now); no compiler magic is required any more - default compiler is used.
Comment 38 Dmitry Marakasov freebsd_committer 2015-04-08 00:30:36 UTC
Created attachment 155325 [details]
Patch to fix OpenEXR depends
Comment 39 Matthias Andree freebsd_committer 2015-04-08 08:07:14 UTC
Comment on attachment 155325 [details]
Patch to fix OpenEXR depends

It looked originally easier to use a better compiler. Your new approach of fixing the upstream code makes some sense, but I cannot currently oversee what performance (hence battery power for laptop) penalty disabling SSE2 incurs.
Comment 40 Dmitry Marakasov freebsd_committer 2015-04-08 21:40:05 UTC
Created attachment 155352 [details]
Patch to fix OpenEXR depends

Updated patch which preserves SSE support on pre-10.x.
Comment 41 Matthias Andree freebsd_committer 2015-04-08 23:09:19 UTC
(In reply to Dmitry Marakasov from comment #40)
Permission to commit this to OpenEXR conditionally granted providing that OpenEXR's self-tests pass on all Tier-1 platforms/architectures and supported releases.
Comment 42 commit-hook freebsd_committer 2015-04-09 10:00:20 UTC
A commit references this bug:

Author: amdmi3
Date: Thu Apr  9 09:59:41 UTC 2015
New revision: 383631
URL: https://svnweb.freebsd.org/changeset/ports/383631

  - Fix build with base gcc on 8.x and 9.x, remove USE_GCC

  PR:		196712
  Approved by:	mandree (maintainer)

Comment 43 Dmitry Marakasov freebsd_committer 2015-04-09 10:01:54 UTC
(In reply to Matthias Andree from comment #41)
Tests pass, fix committed. Ports dependent on OpenEXR now should build fine with updated gcc as well.
Comment 44 Matthias Andree freebsd_committer 2015-04-09 19:39:02 UTC
(In reply to Dmitry Marakasov from comment #43)
спасибо! Thank you!
Comment 45 Koop Mast freebsd_committer 2015-09-21 15:06:20 UTC
Hi, any news on the lang/gcc update to 4.9?

The only linked bug has a patch attached, which a note that it should be applied at the same time with this update. Are there any more snowstoppers?

The reason I'm asking is that a update of www/webkit2-gtk3 I'm working on needs atleast 4.9+. I can't manualy select another gcc version because the port uses compiler:c++11-lib.
Comment 46 Antoine Brodin freebsd_committer 2015-10-12 20:29:22 UTC
(In reply to Koop Mast from comment #45)
 We can do another exp-run if there is an updated patch.
Comment 47 Koop Mast freebsd_committer 2015-10-24 12:05:30 UTC
Created attachment 162416 [details]
v3 of the patch set.

Catch up with ports changes, and bump the version to 4.9.3.
Comment 48 Koop Mast freebsd_committer 2015-10-24 12:08:05 UTC
Over to portmgr for new exp-run, please apply the patch from bug 196914 also.
Comment 49 Antoine Brodin freebsd_committer 2015-10-25 22:29:27 UTC
Exp-run results on 10.1 amd64:


4 new failures:

+ {"origin"=>"devel/pure-stldict", "pkgname"=>"pure-stldict-0.5_4", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"devel/pure-stllib", "pkgname"=>"pure-stllib-0.5_2", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"math/saga", "pkgname"=>"saga-2.2.2", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"sysutils/xen-tools", "pkgname"=>"xen-tools-4.5.1_1", "phase"=>"build", "errortype"=>"arch"}

Failure logs:

Comment 50 Antoine Brodin freebsd_committer 2015-10-26 14:49:27 UTC
Exp-run results on 9.3 amd64:


9 new failures:

+ {"origin"=>"dns/dnstable", "pkgname"=>"dnstable-0.8.0", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"french/aster", "pkgname"=>"fr-aster-", "phase"=>"package", "errortype"=>"???"}
+ {"origin"=>"graphics/luminance-qt5", "pkgname"=>"luminance-hdr-qt5-2.4.0_6", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"lang/clang36", "pkgname"=>"clang36-3.6.2", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"lang/pure", "pkgname"=>"pure-0.64_3", "phase"=>"build", "errortype"=>"bad_C++_code"}
+ {"origin"=>"polish/kadu", "pkgname"=>"pl-kadu-2.1,1", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"sysutils/xen-tools", "pkgname"=>"xen-tools-4.5.1_1", "phase"=>"build", "errortype"=>"arch"}
+ {"origin"=>"www/chromium", "pkgname"=>"chromium-46.0.2490.80", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"www/httrack", "pkgname"=>"httrack-3.48.21_1", "phase"=>"build", "errortype"=>"missing_header"}

Failure logs:


For the clang36 failure,  I believe this commit could fix it:
Comment 51 Antoine Brodin freebsd_committer 2015-10-27 09:06:37 UTC
Exp-run results on 10.1 i386:


6 new failures:

+ {"origin"=>"devel/freeocl", "pkgname"=>"freeocl-0.3.6_6", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"devel/pure-stldict", "pkgname"=>"pure-stldict-0.5_4", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"devel/pure-stllib", "pkgname"=>"pure-stllib-0.5_2", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"emulators/x49gp", "pkgname"=>"x49gp-20100425", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"math/saga", "pkgname"=>"saga-2.2.2", "phase"=>"build", "errortype"=>"linker_error"}

Failure logs:

Comment 52 Antoine Brodin freebsd_committer 2015-10-27 17:47:19 UTC
Exp-run results on 9.3 i386:


8 new failures:

+ {"origin"=>"devel/freeocl", "pkgname"=>"freeocl-0.3.6_6", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"dns/dnstable", "pkgname"=>"dnstable-0.8.0", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"french/aster", "pkgname"=>"fr-aster-", "phase"=>"package", "errortype"=>"???"}
+ {"origin"=>"graphics/luminance-qt5", "pkgname"=>"luminance-hdr-qt5-2.4.0_6", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"lang/clang36", "pkgname"=>"clang36-3.6.2", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"lang/pure", "pkgname"=>"pure-0.64_3", "phase"=>"build", "errortype"=>"bad_C++_code"}
+ {"origin"=>"polish/kadu", "pkgname"=>"pl-kadu-2.1,1", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"www/chromium", "pkgname"=>"chromium-46.0.2490.80", "phase"=>"build", "errortype"=>"gcc4_error"}

The failures are the same as on 9.3 amd64 so I don't put a link to the failure log
Comment 53 commit-hook freebsd_committer 2015-10-29 22:14:42 UTC
A commit references this bug:

Author: kwm
Date: Thu Oct 29 22:14:35 UTC 2015
New revision: 400482
URL: https://svnweb.freebsd.org/changeset/ports/400482

  Include header for stderr to allow the build with gcc 4.9.

  error: 'stderr' was not declared in this scope

  PR:		196712

Comment 54 commit-hook freebsd_committer 2015-10-30 16:51:18 UTC
A commit references this bug:

Author: brooks
Date: Fri Oct 30 16:50:28 UTC 2015
New revision: 400548
URL: https://svnweb.freebsd.org/changeset/ports/400548

  Fix build with GCC 4.9.

  PR:		196712
  Submitted by:	kwm

Comment 55 Steve Wills freebsd_committer 2015-11-03 21:31:56 UTC
This may need to copy over files/patch-pie-support from lang/gcc49 to lang/gcc
Comment 56 Gerald Pfeifer freebsd_committer 2015-11-09 12:24:52 UTC
www/chromium was fixed by 

  r400625 | rene | 2015-11-01 17:00:37 +0000 (Sun, 01 Nov 2015) | 6 lines

  www/chromium: fix build with GCC 4.9 on FreeBSD 9.3

  PR:             204181
  Submitted by:   kwm

www/httrack looks like a false positive due to recent changes around iconv:

  htscharset.c:398:19: error: iconv.h: No such file or directory

Reading the svn log of www/httrack/Makefile confirms that.

I'll create separate bugs for the three ports not covered yet.
Comment 57 Gerald Pfeifer freebsd_committer 2015-11-09 15:53:16 UTC
french-aster also looks like a false positive?

pkg-static: Unable to access file /wrkdirs/usr/ports/french/aster/work/stage/usr/local/aster/11.7/aster_full_config.py: No such file or directory
pkg-static: Unable to access file /wrkdirs/usr/ports/french/aster/work/stage/usr/local/aster/11.7/aster_full_config.pyc: No such file or directory
pkg-static: Unable to access file /wrkdirs/usr/ports/french/aster/work/stage/usr/local/aster/11.7/aster_full_config.pyo: No such file or directory
pkg-static: Unable to access file /wrkdirs/usr/ports/french/aster/work/stage/usr/local/aster/11.7/lib/aster/elements: No such file or directory
Comment 58 Don Lewis freebsd_committer 2015-11-10 00:21:43 UTC
(In reply to Antoine Brodin from comment #50)

The dnstable linker error is caused by devel/libxs and archivers/snappy using different toolchains.  The former uses USE_GCC=yes, whereas the latter always uses the base compiler.  Dnstable is actually all pure C, but it has indirect dependencies on the above two ports.  The problem is even worse on FreeBSD 10 even though the build appears to be successful.  There the linker drags in both libc++ and libstdc++, which is always fatal at runtime in my experience.

See <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204400>
Comment 59 commit-hook freebsd_committer 2015-12-08 01:43:06 UTC
A commit references this bug:

Author: truckman
Date: Tue Dec  8 01:42:11 UTC 2015
New revision: 403247
URL: https://svnweb.freebsd.org/changeset/ports/403247

  Remove USE_GCC=yes from devel/libxs and always build with the base

  There is a defect in the libc++ header files bundled with clang < 3.6
  that broke the libxs build.  Because of this breakage, USE_GCC=yes
  was added to the port Makefile in r330486.

  Unfortunately that breaks dns/dnstable in two different ways.
  Dnstable itself is pure-C code, but it links to two different
  libraries that contain C++ code, libxs and archivers/snappy, the
  latter of which is built with the base c++ compiler.

    * On FreeBSD 9, snappy is generally built with g++ 4.2 from base
      and linked to libstdc++ in base, whereas libxs is built with g++
      from ports and linked to libstdc++ from ports.  When building
      dnstable, the linker seems to load libsnappy first, which brings
      in libstdc++ from base.  This seems to work fine with ports gcc
      4.8 or older, but when the default ports version is upgraded
      to 4.9, the linker fails with the error:
        "/usr/local/lib/libxs.so.2: undefined reference to
  	`std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'"

    * On FreeBSD >= 10 where clang is the base compiler and snappy
      is linked to libc++, the build succeeds but the resulting
      executables will fail at runtime because they link to both libc++
      from base and libstdc++ from ports.

  When building libxs on FreeBSD 10 with clang 3.4, the build error is:

    CXX    libxs_la-io_thread.lo
  --- libxs_la-encoder.lo ---
  In file included from encoder.cpp:23:
  In file included from ./encoder.hpp:28:
  In file included from /usr/include/c++/v1/algorithm:626:
  /usr/include/c++/v1/utility:254:9: error: field has incomplete type 'xs::io_thread_t::timer_info_t'
      _T2 second;

  Patching the code to work around the build failure does not look
  possible, so instead, fix the problem in a rather hackish way when
  compiling with clang < 3.6 and using its bundled c++ headers:

    * Make a local copy of the two defective header files.

    * Apply the upstream change to those files from
      "Allow declaration of map and multimap iterator with incomplete
      mapped type. Patch from eugenis"

    * Add the directory containing the updated header files to the

  This fix is not needed when building with base clang on FreeBSD 9
  because it uses the stdc++ headers.

  PR:		204461
  PR:		204400
  PR:		196712
  Approved by:	vg (maintainer)
  MFH:		2015Q4
  Sponsored by:	Farsight Security, Inc.

Comment 60 Gerald Pfeifer freebsd_committer 2016-11-01 21:23:48 UTC
Created attachment 176402 [details]
v4 of the patch set
Comment 61 Gerald Pfeifer freebsd_committer 2016-11-01 21:27:59 UTC
portmgr, I am trying to unstall this again (on nearly all dependencies
have been addressed).

Can you please do another, hopefully final exp-run, and we'll see how
to best take it from there?
Comment 62 Antoine Brodin freebsd_committer 2016-11-03 13:07:03 UTC
New failures on 9.3 amd64

+ {"origin"=>"cad/gspiceui", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"devel/creduce", "phase"=>"configure", "errortype"=>"configure_error"}
+ {"origin"=>"devel/flatbuffers", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"devel/linux-kernel", "phase"=>"build", "errortype"=>"arch"}
+ {"origin"=>"devel/llvm-cheri", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"devel/llvm-cheri128", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"french/aster", "phase"=>"package", "errortype"=>"???"}
+ {"origin"=>"games/tbe", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"graphics/blender", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"lang/pure", "phase"=>"build", "errortype"=>"bad_C++_code"}
+ {"origin"=>"misc/seabios", "phase"=>"build", "errortype"=>"arch"}
+ {"origin"=>"net-im/qTox", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"sysutils/android-file-transfer", "phase"=>"build", "errortype"=>"gcc4_error"}

Failure logs on 9.3 amd64:

Comment 63 Antoine Brodin freebsd_committer 2016-11-03 18:42:51 UTC
New failures on 9.3 i386:

 {"origin"=>"cad/gspiceui", "pkgname"=>"gspiceui-1.1.00", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"devel/creduce", "pkgname"=>"creduce-2.5.0", "phase"=>"configure", "errortype"=>"configure_error"}
+ {"origin"=>"devel/flatbuffers", "pkgname"=>"flatbuffers-1.4.0", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"devel/llvm-cheri", "pkgname"=>"llvm-cheri-3.8.d20160808", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"devel/llvm-cheri128", "pkgname"=>"llvm-cheri128-3.8.d20160808", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"games/tbe", "pkgname"=>"tbe-,1", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"graphics/cimg", "pkgname"=>"cimg-1.7.8,3", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"lang/pure", "pkgname"=>"pure-0.64_3", "phase"=>"build", "errortype"=>"bad_C++_code"}
+ {"origin"=>"math/gotoblas", "pkgname"=>"gotoblas-", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"net-im/qTox", "pkgname"=>"qTox-1.5.2", "phase"=>"build", "errortype"=>"gcc4_error"}
+ {"origin"=>"sysutils/android-file-transfer", "pkgname"=>"android-file-transfer-3.0.10_1", "phase"=>"build", "errortype"=>"gcc4_error"}

Failure logs:

Comment 64 Antoine Brodin freebsd_committer 2016-11-04 21:46:54 UTC
New failures on 10.1 amd64:

+ {"origin"=>"benchmarks/polygraph", "pkgname"=>"polygraph-4.9.0", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"cad/openvsp", "pkgname"=>"openvsp-3.9.1", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"devel/linux-kernel", "pkgname"=>"linux-kernel-4.7.9", "phase"=>"build", "errortype"=>"arch"}
+ {"origin"=>"math/ceres-solver", "pkgname"=>"ceres-solver-1.12.0.r1_1", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"math/saga", "pkgname"=>"saga-2.3.1_2", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"misc/seabios", "pkgname"=>"seabios-1.10.0", "phase"=>"build", "errortype"=>"arch"}
+ {"origin"=>"print/lilypond-devel", "pkgname"=>"lilypond-devel-2.19.48", "phase"=>"build", "errortype"=>"linker_error"}

Failure logs:

Comment 65 Antoine Brodin freebsd_committer 2016-11-05 07:05:47 UTC
New failures on 10.1 i386:

+ {"origin"=>"benchmarks/polygraph", "pkgname"=>"polygraph-4.9.0", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"cad/openvsp", "pkgname"=>"openvsp-3.9.1", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"emulators/x49gp", "pkgname"=>"x49gp-20100425", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"math/ceres-solver", "pkgname"=>"ceres-solver-1.12.0.r1_1", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"math/gotoblas", "pkgname"=>"gotoblas-", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"math/saga", "pkgname"=>"saga-2.3.1_2", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"print/lilypond-devel", "pkgname"=>"lilypond-devel-2.19.48", "phase"=>"build", "errortype"=>"linker_error"}

Failure logs:

Comment 66 Antoine Brodin freebsd_committer 2016-11-06 08:22:29 UTC
Comment on attachment 155352 [details]
Patch to fix OpenEXR depends

Committed in ports r383631
Comment 67 Antoine Brodin freebsd_committer 2016-11-06 08:28:06 UTC
New failures on 11.0 amd64:

+ {"origin"=>"benchmarks/polygraph", "pkgname"=>"polygraph-4.9.0", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"devel/linux-kernel", "pkgname"=>"linux-kernel-4.7.9", "phase"=>"build", "errortype"=>"arch"}
+ {"origin"=>"misc/seabios", "pkgname"=>"seabios-1.10.0", "phase"=>"build", "errortype"=>"arch"}

Failure logs


For polygraph, I found this patch (untested):

For seabios and linux-kernel,  there is this patch (royger@ tested it for seabios):
Comment 68 commit-hook freebsd_committer 2016-11-06 09:24:28 UTC
A commit references this bug:

Author: antoine
Date: Sun Nov  6 09:24:01 UTC 2016
New revision: 425476
URL: https://svnweb.freebsd.org/changeset/ports/425476

  Fix build with gcc 4.9

  PR:		196712

Comment 69 Antoine Brodin freebsd_committer 2016-11-06 15:21:23 UTC
New failures on 11.0 i386:

+ {"origin"=>"emulators/x49gp", "pkgname"=>"x49gp-20100425", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"math/gotoblas", "pkgname"=>"gotoblas-", "phase"=>"build", "errortype"=>"coredump"}

Failure logs:

Comment 70 commit-hook freebsd_committer 2016-11-11 18:40:27 UTC
A commit references this bug:

Author: antoine
Date: Fri Nov 11 18:39:57 UTC 2016
New revision: 425901
URL: https://svnweb.freebsd.org/changeset/ports/425901

  Fix build with gcc 4.9 by lowering optimization level

  See also:

  PR:		196712

Comment 71 commit-hook freebsd_committer 2016-11-11 19:35:34 UTC
A commit references this bug:

Author: antoine
Date: Fri Nov 11 19:34:36 UTC 2016
New revision: 425905
URL: https://svnweb.freebsd.org/changeset/ports/425905

  Fix build with gcc 4.9

  PR:		196712

Comment 72 Antoine Brodin freebsd_committer 2016-11-13 16:18:04 UTC

The update to GCC 4.9 is approved with the patch from https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00252.html applied.  I verified that it allows building misc/seabios and devel/linux-kernel.

There is a little fallout on old releases but we have to move forward.
Comment 73 commit-hook freebsd_committer 2016-11-20 09:15:35 UTC
A commit references this bug:

Author: gerald
Date: Sun Nov 20 09:15:20 UTC 2016
New revision: 426565
URL: https://svnweb.freebsd.org/changeset/ports/426565

  Long awaited, finally update the default version of GCC in the Ports
  Collection as well as the lang/gcc port from GCC 4.8.5 to GCC 4.9.4!

  See http://gcc.gnu.org/gcc-4.9/changes.html for an extensive list of
  changes and http://gcc.gnu.org/gcc-4.9/porting_to.html for information
  on how to port to that new version (if necessary).

  files/java-patch-hier required adjustments, gcc/files/patch-arm-libcpp
  is not needed any longer (merged upstream), and we're also loosing the
  local Stack Protector patches/backports.

  PR:		196712
  Tested by:	antoine (-exp runs)
  Supported by:	antoine, kwm, and others

Comment 74 commit-hook freebsd_committer 2016-11-20 20:34:50 UTC
A commit references this bug:

Author: gerald
Date: Sun Nov 20 20:34:39 UTC 2016
New revision: 426624
URL: https://svnweb.freebsd.org/changeset/ports/426624

  Move the conflict with lang/gcc from lang/gcc48 to lang/gcc49 now that
  we have updated lang/gcc to the GCC 4.9 series.  (The direction from
  lang/gcc49 to the respective port already has been addressed.)

  PR:		196712

Comment 75 commit-hook freebsd_committer 2016-11-20 21:40:06 UTC
A commit references this bug:

Author: antoine
Date: Sun Nov 20 21:39:25 UTC 2016
New revision: 426636
URL: https://svnweb.freebsd.org/changeset/ports/426636

  Fix build on 9.3 amd64 after lang/gcc upgrade by switching to USE_GCC=4.8

  gcc 4.9 fails to link on 9.3 amd64 with:
  /usr/local/lib/libtinyxml.so: error: undefined reference to 'std::istream::get()'
  /usr/local/lib/libtinyxml.so: error: undefined reference to 'std::__throw_out_of_range(char const*)'
  /usr/local/lib/libtinyxml.so: error: undefined reference to 'std::istream::peek()'

  PR:		196712

Comment 76 Gerald Pfeifer freebsd_committer 2016-11-20 21:54:31 UTC
Thanks to everyone who helped on this journey, in particular to Antoine
who in addition to the -exp runs helped us carry this baby to the finish
line. :-)

(Bug 204391 and bug 204393 still look like they'll need some love and
attention, just for reference.)
Comment 77 Jan Beich freebsd_committer 2016-11-23 06:05:37 UTC
Did you give up on 10.1 a few months before it reached EOL ? USES=compiler:gcc-c++11-lib ports are broken because of spurious references to libstdc++.

  $ cat a.cc
  int main()
    // exceprt from lilypond-devel
    int argc = 5;
    char **argv = new char*[argc + 2];
    return 0;

  $ pkg install -y gcc libc++
  $ g++49 -std=c++11 -nostdinc++ -isystem /usr/local/include/c++/v1 -L/usr/local/lib/c++ a.cc
  /tmp//ccZYfujU.o: In function `main':
  a.cc:(.text+0x2b): undefined reference to `__cxa_throw_bad_array_new_length'
  collect2: error: ld returned 1 exit status
Comment 78 commit-hook freebsd_committer 2016-11-24 06:29:31 UTC
A commit references this bug:

Author: jbeich
Date: Thu Nov 24 06:28:45 UTC 2016
New revision: 426992
URL: https://svnweb.freebsd.org/changeset/ports/426992

  sysutils/android-file-transfer: unbreak on 9.x after r426565

  In file included from cli/Session.cpp:22:0:
  ./cli/PosixStreams.h: In constructor 'cli::ObjectInputStream::ObjectInputStream(const string&)':
  ./cli/PosixStreams.h:72:18: error: 'perror' was not declared in this scope
  ./cli/PosixStreams.h: In constructor 'cli::ObjectOutputStream::ObjectOutputStream(const string&)':
  ./cli/PosixStreams.h:109:18: error: 'perror' was not declared in this scope

  Changes:	https://github.com/whoozle/android-file-transfer-linux/compare/40640fb...5a818d8
  PR:		196712
  Reported by:	pkg-fallout