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?
Take for exp-run
This line has to be changed too: Mk/Uses/fortran.mk:21:.if ${_GCC_VER} == 48
New failures on freebsd 10.1, qemu, x49gp and nhc98 are i386 specific: http://package18.nyi.freebsd.org/data/101amd64-default-PR196712/2015-01-16_07h05m42s/logs/errors/beast-0.7.8_8.log http://package18.nyi.freebsd.org/data/101amd64-default-PR196712/2015-01-16_07h05m42s/logs/errors/musicpd-0.18.11_5.log http://package18.nyi.freebsd.org/data/101amd64-default-PR196712/2015-01-16_07h05m42s/logs/errors/seqan-1.3.1_3.log http://package18.nyi.freebsd.org/data/101amd64-default-PR196712/2015-01-16_07h05m42s/logs/errors/libbobcat-3.18.01_1.log http://package18.nyi.freebsd.org/data/101amd64-default-PR196712/2015-01-16_07h05m42s/logs/errors/libcwd-1.0.4_1.log http://package18.nyi.freebsd.org/data/101amd64-default-PR196712/2015-01-16_07h05m42s/logs/errors/psptoolchain-binutils-2.22_1.log http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2015-01-16_07h04m40s/logs/errors/qemu-0.11.1_18.log http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2015-01-16_07h04m40s/logs/errors/x49gp-20100425.log http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2015-01-16_07h04m40s/logs/errors/nhc98-1.22_1.log http://package18.nyi.freebsd.org/data/101amd64-default-PR196712/2015-01-16_07h05m42s/logs/errors/apache-openoffice-4.1.1_3.log http://package18.nyi.freebsd.org/data/101amd64-default-PR196712/2015-01-16_07h05m42s/logs/errors/apache-openoffice-devel-4.1.1560773_5,2.log http://package18.nyi.freebsd.org/data/101amd64-default-PR196712/2015-01-16_07h05m42s/logs/errors/nget-0.27.1_2.log http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2015-01-16_07h04m40s/logs/errors/dlpolyclassic-1.8_8.log http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2015-01-16_07h04m40s/logs/errors/pnetcdf-1.5.0_7.log
New failures on 9.3, gnu-efi and dolphin-emu are amd64 only, nhc98 is i386 only: http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/beast-0.7.8_8.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/musicpd-0.18.11_5.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/seqan-1.3.1_3.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2015-01-18_12h28m08s/logs/errors/gnu-efi-3.0w.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/calligra-2.7.5_14.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/apache-openoffice-4.1.1_3.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/apache-openoffice-devel-4.1.1560773_5,2.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2015-01-18_12h28m08s/logs/errors/dolphin-emu-4.0.2_2.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/fr-aster-11.6.0.1_3.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/ampasCTL-1.5_4.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/aqsis-1.8.2_9.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/cinepaint-1.0.4_8.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/exact-image-0.8.9_9.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/exrtools-0.4_12.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/fyre-1.0.1_7.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/gle-graphics-4.2.4.c_2.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/hugin-2013.0.0_5.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/lprof-devel-20080514_12.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/luminance-hdr-2.3.1_4.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/luminance-hdr-qt5-2.4.0_5.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/luxrender-1.3.1_4.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/nvidia-texture-tools-2.0.8.1_7.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/openimageio-1.4.14_2.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/vips-7.42.1.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/clang-devel-3.6.r225991.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/nhc98-1.22_1.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/dlpolyclassic-1.8_8.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/pnetcdf-1.5.0_7.log http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/obfsclient-0.0.2_1.log
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 Log: Require building with GCC 4.8 due to non-conforming C++ code. PR: 196849, 196712 Changes: head/audio/beast/Makefile
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
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 Log: Fails to build with newer versions of GCC (4.9 and above) due to non-compliant C++ code. PR: 196852, 196712 Changes: head/devel/libcwd/Makefile
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 Log: Change USE_GCC=4.8+ to USE_GCC=4.8 since files/patch-Make.defaults actually hard-codes 48. PR: 196712 Changes: head/devel/gnu-efi/Makefile
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 Log: 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] Changes: head/news/nget/Makefile head/news/nget/pkg-plist
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.
(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-11.6.0.1_3.log 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.
(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. :-(
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.
(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?
(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?
Created attachment 153323 [details] v2 of the patchset
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.
(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?
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 Log: 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) Changes: head/graphics/openimageio/Makefile
(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.
So, Matthias, could we just switch OpenEXR to USES=compiler:c++11-lib to simplify things?
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.
> 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?
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...
(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 Дмитрий?)
PR 196851 now has a workaround and does not block any longer.
Restore dependency on PR 196913 that was fixed already, now that I am tracking "blocked" and "related" differently.
PR 196857 is also related, and has a workaround in place (so does not block).
(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 Дмитрий.
I've just had an idea suggested by this commit: https://svnweb.freebsd.org/ports/head/deskutils/taskwarrior/Makefile?r1=383042&r2=383041&pathrev=383042 We could just use clang on < 10.x, which doesn't bring neither libc++ nor newer libstdc++. I'm currently testing.
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.
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).
No success with clang34 unfortunately: it doesn't compile OpenEXR: https://people.freebsd.org/~amdmi3/openexr.log Which means that we'll have to wait 3 more months till 8.x EOL or find another solution.
(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 port? I submitted this update in January, and still more than half of the broken ports have not been addressed. :-(
(In reply to Gerald Pfeifer from comment #34) > Can we just go ahead and copy what OpenEXR uses into its dependent port? I'm strictly against that.
(In reply to Dmitry Marakasov from comment #33) You may need to add new binutils, too...
> 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.
Created attachment 155325 [details] Patch to fix OpenEXR depends
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.
Created attachment 155352 [details] Patch to fix OpenEXR depends Updated patch which preserves SSE support on pre-10.x.
(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.
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 Log: - Fix build with base gcc on 8.x and 9.x, remove USE_GCC PR: 196712 Approved by: mandree (maintainer) Changes: head/graphics/OpenEXR/Makefile head/graphics/OpenEXR/files/patch-IlmImf_ImfFastHuf.cpp head/graphics/OpenEXR/files/patch-IlmImf__ImfSystemSpecific.cpp
(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.
(In reply to Dmitry Marakasov from comment #43) спасибо! Thank you!
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.
(In reply to Koop Mast from comment #45) We can do another exp-run if there is an updated patch.
Created attachment 162416 [details] v3 of the patch set. Catch up with ports changes, and bump the version to 4.9.3.
Over to portmgr for new exp-run, please apply the patch from bug 196914 also.
Exp-run results on 10.1 amd64: http://package22.nyi.freebsd.org/jail.html?mastername=101amd64-default-PR196712 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: http://package22.nyi.freebsd.org/data/101amd64-default-PR196712/2015-10-25_21h38m31s/logs/errors/pure-stldict-0.5_4.log http://package22.nyi.freebsd.org/data/101amd64-default-PR196712/2015-10-25_21h38m31s/logs/errors/pure-stllib-0.5_2.log http://package22.nyi.freebsd.org/data/101amd64-default-PR196712/2015-10-25_21h38m31s/logs/errors/saga-2.2.2.log http://package22.nyi.freebsd.org/data/101amd64-default-PR196712/2015-10-25_21h38m31s/logs/errors/xen-tools-4.5.1_1.log
Exp-run results on 9.3 amd64: http://package18.nyi.freebsd.org/jail.html?mastername=93amd64-default-PR196712 9 new failures: + {"origin"=>"dns/dnstable", "pkgname"=>"dnstable-0.8.0", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"french/aster", "pkgname"=>"fr-aster-11.7.0.1_1", "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: http://package18.nyi.freebsd.org/data/93amd64-default-PR196712/2015-10-26_13h36m37s/logs/errors/dnstable-0.8.0.log http://package18.nyi.freebsd.org/data/93amd64-default-PR196712/2015-10-26_13h36m37s/logs/errors/fr-aster-11.7.0.1_1.log http://package18.nyi.freebsd.org/data/93amd64-default-PR196712/2015-10-26_13h36m37s/logs/errors/luminance-hdr-qt5-2.4.0_6.log http://package18.nyi.freebsd.org/data/93amd64-default-PR196712/2015-10-26_13h36m37s/logs/errors/clang36-3.6.2.log http://package18.nyi.freebsd.org/data/93amd64-default-PR196712/2015-10-26_13h36m37s/logs/errors/pure-0.64_3.log http://package18.nyi.freebsd.org/data/93amd64-default-PR196712/2015-10-26_13h36m37s/logs/errors/pl-kadu-2.1,1.log http://package18.nyi.freebsd.org/data/93amd64-default-PR196712/2015-10-26_13h36m37s/logs/errors/xen-tools-4.5.1_1.log http://package18.nyi.freebsd.org/data/93amd64-default-PR196712/2015-10-26_13h36m37s/logs/errors/chromium-46.0.2490.80.log http://package18.nyi.freebsd.org/data/93amd64-default-PR196712/2015-10-26_13h36m37s/logs/errors/httrack-3.48.21_1.log For the clang36 failure, I believe this commit could fix it: http://llvm.org/viewvc/llvm-project?view=revision&revision=226925
Exp-run results on 10.1 i386: http://package22.nyi.freebsd.org/jail.html?mastername=101i386-default-PR196712 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: http://package22.nyi.freebsd.org/data/101i386-default-PR196712/2015-10-27_08h38m03s/logs/errors/freeocl-0.3.6_6.log http://package22.nyi.freebsd.org/data/101i386-default-PR196712/2015-10-27_08h38m03s/logs/errors/x49gp-20100425.log
Exp-run results on 9.3 i386: http://package23.nyi.freebsd.org/jail.html?mastername=93i386-default-PR196712 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-11.7.0.1_1", "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
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 Log: Include header for stderr to allow the build with gcc 4.9. error: 'stderr' was not declared in this scope PR: 196712 Changes: head/graphics/luminance-qt5/files/patch-src_Libpfs_maninp_projection.cpp
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 Log: Fix build with GCC 4.9. PR: 196712 Submitted by: kwm Changes: head/lang/clang36/Makefile head/lang/clang36/files/patch-svn-226925
This may need to copy over files/patch-pie-support from lang/gcc49 to lang/gcc
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.
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
(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>
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 Log: Remove USE_GCC=yes from devel/libxs and always build with the base compiler. 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 <http://llvm.org/viewvc/llvm-project?view=revision&revision=231119> "Allow declaration of map and multimap iterator with incomplete mapped type. Patch from eugenis" * Add the directory containing the updated header files to the CPPFLAGS. 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. Changes: head/devel/libxs/Makefile head/devel/libxs/files/ head/devel/libxs/files/extra-patch-map
Created attachment 176402 [details] v4 of the patch set
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?
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: http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/gspiceui-1.1.00.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/creduce-2.5.0.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/flatbuffers-1.4.0.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/linux-kernel-4.7.9.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/llvm-cheri-3.8.d20160808.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/llvm-cheri128-3.8.d20160808.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/fr-aster-11.7.0.1_2.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/tbe-0.9.2.1_1,1.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/blender-2.77a.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/pure-0.64_3.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/seabios-1.10.0.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/qTox-1.5.2.log http://package22.nyi.freebsd.org/data/93amd64-default-PR196712/2016-11-03_11h22m35s/logs/errors/android-file-transfer-3.0.10_1.log
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-0.9.2.1_1,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-2.1.13.3.4.0_6", "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: http://package23.nyi.freebsd.org/data/93i386-default-PR196712/2016-11-03_16h53m11s/logs/errors/gspiceui-1.1.00.log http://package23.nyi.freebsd.org/data/93i386-default-PR196712/2016-11-03_16h53m11s/logs/errors/creduce-2.5.0.log http://package23.nyi.freebsd.org/data/93i386-default-PR196712/2016-11-03_16h53m11s/logs/errors/flatbuffers-1.4.0.log http://package23.nyi.freebsd.org/data/93i386-default-PR196712/2016-11-03_16h53m11s/logs/errors/llvm-cheri-3.8.d20160808.log http://package23.nyi.freebsd.org/data/93i386-default-PR196712/2016-11-03_16h53m11s/logs/errors/llvm-cheri128-3.8.d20160808.log http://package23.nyi.freebsd.org/data/93i386-default-PR196712/2016-11-03_16h53m11s/logs/errors/tbe-0.9.2.1_1,1.log http://package23.nyi.freebsd.org/data/93i386-default-PR196712/2016-11-03_16h53m11s/logs/errors/cimg-1.7.8,3.log http://package23.nyi.freebsd.org/data/93i386-default-PR196712/2016-11-03_16h53m11s/logs/errors/pure-0.64_3.log http://package23.nyi.freebsd.org/data/93i386-default-PR196712/2016-11-03_16h53m11s/logs/errors/gotoblas-2.1.13.3.4.0_6.log http://package23.nyi.freebsd.org/data/93i386-default-PR196712/2016-11-03_16h53m11s/logs/errors/qTox-1.5.2.log http://package23.nyi.freebsd.org/data/93i386-default-PR196712/2016-11-03_16h53m11s/logs/errors/android-file-transfer-3.0.10_1.log
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: http://package22.nyi.freebsd.org/data/101amd64-default-PR196712/2016-11-04_20h32m59s/logs/errors/polygraph-4.9.0.log http://package22.nyi.freebsd.org/data/101amd64-default-PR196712/2016-11-04_20h32m59s/logs/errors/openvsp-3.9.1.log http://package22.nyi.freebsd.org/data/101amd64-default-PR196712/2016-11-04_20h32m59s/logs/errors/linux-kernel-4.7.9.log http://package22.nyi.freebsd.org/data/101amd64-default-PR196712/2016-11-04_20h32m59s/logs/errors/ceres-solver-1.12.0.r1_1.log http://package22.nyi.freebsd.org/data/101amd64-default-PR196712/2016-11-04_20h32m59s/logs/errors/saga-2.3.1_2.log http://package22.nyi.freebsd.org/data/101amd64-default-PR196712/2016-11-04_20h32m59s/logs/errors/seabios-1.10.0.log http://package22.nyi.freebsd.org/data/101amd64-default-PR196712/2016-11-04_20h32m59s/logs/errors/lilypond-devel-2.19.48.log
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-2.1.13.3.4.0_6", "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: http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2016-11-05_06h18m49s/logs/errors/polygraph-4.9.0.log http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2016-11-05_06h18m49s/logs/errors/openvsp-3.9.1.log http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2016-11-05_06h18m49s/logs/errors/x49gp-20100425.log http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2016-11-05_06h18m49s/logs/errors/ceres-solver-1.12.0.r1_1.log http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2016-11-05_06h18m49s/logs/errors/gotoblas-2.1.13.3.4.0_6.log http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2016-11-05_06h18m49s/logs/errors/saga-2.3.1_2.log http://package23.nyi.freebsd.org/data/101i386-default-PR196712/2016-11-05_06h18m49s/logs/errors/lilypond-devel-2.19.48.log
Comment on attachment 155352 [details] Patch to fix OpenEXR depends Committed in ports r383631
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 http://package22.nyi.freebsd.org/data/110amd64-default-PR196712/2016-11-06_08h07m38s/logs/errors/polygraph-4.9.0.log http://package22.nyi.freebsd.org/data/110amd64-default-PR196712/2016-11-06_08h07m38s/logs/errors/linux-kernel-4.7.9.log http://package22.nyi.freebsd.org/data/110amd64-default-PR196712/2016-11-06_08h07m38s/logs/errors/seabios-1.10.0.log For polygraph, I found this patch (untested): https://launchpadlibrarian.net/233322218/POLY-43-lp1380660-make-failed-if-gcc-49-a1b938b.patch For seabios and linux-kernel, there is this patch (royger@ tested it for seabios): https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00252.html
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 Log: Fix build with gcc 4.9 PR: 196712 Changes: head/benchmarks/polygraph/files/patch-src_xstd_Ring.h
New failures on 11.0 i386: + {"origin"=>"emulators/x49gp", "pkgname"=>"x49gp-20100425", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"math/gotoblas", "pkgname"=>"gotoblas-2.1.13.3.4.0_6", "phase"=>"build", "errortype"=>"coredump"} Failure logs: http://package23.nyi.freebsd.org/data/110i386-default-PR196712/2016-11-06_14h47m59s/logs/errors/x49gp-20100425.log http://package23.nyi.freebsd.org/data/110i386-default-PR196712/2016-11-06_14h47m59s/logs/errors/gotoblas-2.1.13.3.4.0_6.log
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 Log: Fix build with gcc 4.9 by lowering optimization level See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750743 https://bugs.gentoo.org/show_bug.cgi?id=553968 PR: 196712 Changes: head/cad/gspiceui/Makefile
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 Log: Fix build with gcc 4.9 PR: 196712 Changes: head/devel/flatbuffers/files/ head/devel/flatbuffers/files/patch-samples_sample__binary.cpp head/devel/llvm-cheri/files/patch-tools_clang_lib_Sema_SemaChecking.cpp head/games/tbe/files/patch-src_main.cpp
Hi, 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.
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 Log: 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 Changes: head/Mk/bsd.default-versions.mk head/lang/gcc/Makefile head/lang/gcc/distinfo head/lang/gcc/files/java-patch-hier head/lang/gcc/files/patch-arm-libcpp head/lang/gcc/files/patch-stackprotector-gcc head/lang/gcc/files/patch-stackprotector-gcc_c-family head/lang/gcc/files/patch-stackprotector-gcc_doc head/lang/gcc/files/patch-stackprotector-gcc_testsuite head/lang/gcc/files/patch-x86-64-fix-m16 head/lang/gcc/pkg-descr head/lang/gcc/pkg-plist
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 Log: 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 Changes: head/lang/gcc48/Makefile head/lang/gcc49/Makefile
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 Log: 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 Changes: head/graphics/blender/Makefile
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.)
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
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 Log: 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 perror("open"); ^ ./cli/PosixStreams.h: In constructor 'cli::ObjectOutputStream::ObjectOutputStream(const string&)': ./cli/PosixStreams.h:109:18: error: 'perror' was not declared in this scope perror("open"); ^ Changes: https://github.com/whoozle/android-file-transfer-linux/compare/40640fb...5a818d8 PR: 196712 Reported by: pkg-fallout Changes: head/sysutils/android-file-transfer/Makefile head/sysutils/android-file-transfer/distinfo