I found many weeks again that math/reduce wouldn't build on GCC5. It turns out that it won't build on gcc48 either. To reproduce, put "USE_GCC=yes" in the makefile and "make check-plist" It segfaults during the build so a critical file is never produced. Surely this must be known upstream and a fix already provided?
(In reply to John Marino from comment #0) The report is rather incomplete .. *what* segfaults, gcc48 or the reduce binary? The situation is this: there are two different versions of reduce in the same tarball: we are using the C version because we want this running on all platforms, also the native-lisp version was not supported on FreeBSD when the release was made (2011). Upstream developers prefer using the lisp native version as it is faster, so bugs in gcc can go unnoticed. I will try to update reduce to the recent snapshot (2014) but there is no guarantee that it will fix any bug related to gcc and from my point of view as long as works with clang it's not really a bug.
if gcc48 segfaulted, wouldn't that be an issue for gcc? one of the executables that is created segfaults. It's easily reproducible, just add "USE_GCC=yes" to the makefile and watch it go. here's a log (won't stay forever): http://muscles.dragonflybsd.org/bulk/bleeding-edge-potential/latest-per-pkg/reduce-20110414_2.log. It uses gcc48, but the same thing happens with gcc5
"from my point of view as long as works with clang it's not really a bug." There is no decree that ports are clang-only. In fact, people still want ports building on modern gcc. The point of view you have is not shared by ports leadership. It's a variation of "screw dragonfly" but there are plenty of freebsd users that override and use GCC to compile ports.
(In reply to John Marino from comment #3) *Please* I have nothing against dragonfly (I have huge respect for Matt and I have even contributed patches). I will welcome patches for any port I maintain but you do have to understand that gcc bugs are not my priority. Thanks for the log.
you have to realize I get a lot "screw dragonfly" sentiment; it's fairly common. I think it's not good policy to not priority gcc, especially the latest gcc, because if its choking on the code, there is probably something wrong with the code. That's been our experience with gcc5. Almost everything it flag was a real problem. The fact it passes on clang isn't an indictment on gcc, it's an indictment on clang for not catching it. (normally -- there are always exceptions to any rule). Also, just so you understand my position: this is one of 22,000 ports that I maintain *by myself*. As soon as a port gives my any trouble, I just cut it. If somebody complains, they need to fix it. So I don't particularly care about reduce, I'm just reporting it like a good citizen. It's really no skin of my nose either way.
(In reply to John Marino from comment #5) I used to see a lot of similar anti-BSD sentiment, in particular in the GCC camp. It's sad that it happens but you have to learn to grow a hard skin. Beyond political considerations, there are good reason to avoid GCC on FreeBSD: the STL compatibility issues hit really hard, specially on complex ports like OpenOffice. In this case this is not the issue but (from the log) the program compiles just fine, while the executable segfaults. Generally, but not necessarily, this would be a compiler issue and it will take someone more qualified than me to hunt it down. I prefer to spend my time updating the port instead of hunting a non-obvious bug (which can be in the compiler). Yes, it's good to avoid depending on a unique compiler. A word of advise since you are the only maintainer in DragonFly: in FreeBSD we have ports that don't work with clang so we have a USE_GCC knob, you should just consider having a USE_CLANG, and don't be afraid to use it. Now, if the program also fails with clang ... we may have an architectural issue.
(In reply to Pedro F. Giffuni from comment #6) Hmm, given that it segfaults on gcc48, gcc49, and gcc5, I really don't think it's a compiler flaw. I'd be more included to think that if the issue was limited to gcc5 though, but this isn't a recent issue. FreeBSD is in worse shape that DragonFly though by supporting clang with libc++ and gcc with libstdc++. They aren't compatible so there there's tons of problem. DragonFly would have less problems that FreeBSD because we share the same c++ library, but still seeing what FreeBSD is going through is a good reason not repeat the same approach. To be truthful, I don't really trust programs that don't compile on multiple compilers (excluding specialty stuff like opengomp, etc). If Reduce simply doesn't and the upstream doesn't care and you won't be able to do anything about it, then I'll just classify Reduce as fundamentally broken and remove it (regardless of how debatable my rationale may be). I'm not pro- or anti-clang, nor am I pro- or anti-gcc. Maybe by Release 4.4 DragonFly will have both clang and gcc in base but I definitely want them to be interchangeable.
(In reply to John Marino from comment #7) The port was developed in gcc42, and it used to work fine there. Bugs in gcc (any version) are not uncommon. Our gcc integration was never really very good and from the guts of gcc-4.2 that I have had to look at, I really prefer to keep away from anything derived from it. clang and libc++ are a great combination, I am really glad we went that path. Yes, there has been some pain in the process but upstream packages have been very receptive and we are in pretty good shape nowadays. I am updating the port but it will take some time. For now let's close this PR.
(In reply to Pedro F. Giffuni from comment #8) > The port was developed in gcc42, and it used to work fine there. Things have changed a lot in 8 years. > Bugs in gcc (any version) are not uncommon. Granted, but it's not common for a serious regression to endure over 3 releases. possible? yes. First choice of diagnosis? not in my opinion. By the way, I looked up my notes. On GCC5, math/reduce locked up. The build never even finished. That's why it was set for gcc47 in the first place. > Our gcc integration was never really very good and from the guts of gcc-4.2 > that I have had to look at, I really prefer to keep away from anything > derived from it. If that work was in context of backing fixes to 4.2.1, that's not really a normal situation. Yes, GCC code is brutal and there are bugs but it's not *that* bad. > I am updating the port but it will take some time. > For now let's close this PR. Okay, we'll close the PR. For my part, I have removed math/reduce for dports completely. If/when it builds again, it will be automatically reimported by the normal bulk build process. Give the segfaults and lock-ups, the port is just a liability in my eyes. I've done my reporting duty!
It was faster than I thought and yes, the update builds fine with gcc.
(In reply to Pedro F. Giffuni from comment #10) I tested in poudriere on amd64, FreeBSD 10. It did not pass, it failed just like the log I provided. Do you want me to attach that log too? What did you test it on?
ah, sorry, you are talking about a new version.
A commit references this bug: Author: marino Date: Sat May 2 15:48:09 UTC 2015 New revision: 385182 URL: https://svnweb.freebsd.org/changeset/ports/385182 Log: math/reduce: upgrade version 20110414 => 20141130 This version can be built by system compilers (gcc 4.2 & clang) and also ports gcc compilers, unlike its predecessor which would segfault and even lock up during build. PR: 199832, 199853 Submitted by: pfg (maintainer) Changes: head/math/reduce/Makefile head/math/reduce/distinfo head/math/reduce/files/patch-csl_cslbase_headers.h