Created attachment 150955 [details] sysutils/lsof build fix sysutils/lsof needs bool type defined. The last revision to the port tries to set CFLAGS to define NEED_BOOL_TYPEDEF, but that doesn't work; the build fails and the compiler is clearly invoked without that passed as a flag. The configure script already has a check for FreeBSD 10 which defines NEED_BOOL_TYPEDEF, but for some reason it also checks for arch i386. The bool type is needed regardless, so I patched out the arch check in the configure script and it builds correctly on amd64. This may also help arm but I have not checked that to see if there was another issue or just silly arch checks.
Notify maintainer.
I do NOT see any failure on amd64. Can you show me a log of the failure? The arm stuff should be good to go on 10 and 11 now with Ian Lepore's fixes to cpuconf.h.
I can't reproduce the failure with the current state of the ports tree. Can we close this?
Created attachment 151305 [details] build failure log The build.log attachment shows the failure with current ports tree and no modifications. A good build with my changes follows. Build fail is same on numerous independent systems.
what EXACT svn rev is your source tree at?
(In reply to Larry Rosenman from comment #5) Quoting from `svn info` in the log: Revision: 376173 I updated from svn just prior to running the builds again with logging to confirm the current state is still incorrect.
That's the PORTS TREE svn, I'm looking for for the /usr/src svn rev
(In reply to Larry Rosenman from comment #7) Sorry, since you had only asked about the source version, in the context of a port I interpreted that as /usr/ports revision. Now that you have cleared the ambiguity, /usr/src on the system the log is from is Revision: 276191. Another system here has /usr/src at Revision: 276321. The build failure started with 4.89a version of the port. Those systems have had their /usr/src updated since then and the build continues to fail without my patch to Configure, which is the root of the problem. Maybe I should just send that patch upstream since their Configure script is clearly wrong.
(In reply to matthew from comment #8) The big problem is I can't reproduce the failure in my poudriere jails or my 10.1 amd64 box that are fairly current. I will play with the specific revs you have and see if I can reproduce it, but I'm not sure what's going on here...
I can't make a stable/10@276191 jail on my poudriere host since it doesn't have bapt@'s changes for makeinfo & friends. I suspect the issue is fixed in later 10/stable commits.
Can you check your /etc/make.conf for CFLAGS= and change it to CFLAGS+=?
Created attachment 151380 [details] second build log I updated one of my systems yesterday and repaeted the tests today. Unsurprisingly, the results are the same; build failure without my patch. I notice there is something odd about this build. The first piece of CFLAGS is separated into DEBUG and then not used when executing the compiler, while the rest are carried along and used. There's something fishy with CFLAGS handling so maybe just the fact I set a couple basic flags in make.conf has something to do with it.
(In reply to Larry Rosenman from comment #11) I noticed this reply only after posting my secong log. Sure enough, that is the culprit. I've been using CFLAGS= in make.conf for well over a decade and never before had a problem with it. The example file does shown CFLAGS+= although it lacks an explanation like CXXFLAGS has for the different effect of = and +=. Still, it would be nice to get Configure patched upstream to do the right thing.
I seriously doubt this needs to be fixed in the script. CFLAGS= in /etc/make.conf is DANGEROUS.
It's good that the origin of the issue has been identified and resolved. The port works as intended, closing this issue. @Larry: It would be great if you could pass this on to the upstream developer(s). In a perfect world, it should not be necessary for a port to set special CFLAGS to make it compile.