On Fri, 2015-03-27 at 10:17 -0500, Michael Tuexen wrote:
> > On 26 Mar 2015, at 21:36, Mark Millard <mar...@dsl-only.net> wrote:
> > 
> > Basic context:
> > 
> > # freebsd-version -ku; uname -apKU
> > 11.0-CURRENT
> > 11.0-CURRENT
> > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21 
> > 05:15:23 PDT 2015     
> > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG  powerpc 
> > powerpc64 1100062 1100062
> > 
> > 
> > The problem:
> > 
> > Summary of the details that are listed later. Both of the following exist:
> > 
> > /usr/src/sys/netinet/sctp.h
> > /usr/include/netinet/sctp.h
> > 
> > The first can be newer than the 2nd during buildworld.
> > 
> > The buildworld compile of /head/lib/libc/net/sctp_sys_calls.c from an 
> > updated /usr/src can/does end up using the second instead of the first, at 
> > least for the powerpc64-xtoolchain-gcc style of buildworld activity that I 
> > am trying.
> > 
> > The recent addition of SCTP_MAX_CWND ends up with its definition missing 
> > because of this: during the build /usr/include/netinet/sctp.h ends up being 
> > the file included and the compile fails from the missing additional 
> > definition.
> > 
> > Either the #include paths in /head/lib/libc/net/sctp_sys_calls.c or the 
> > command line arguments should force the /usr/src/sys/netinet/sctp.h vintage 
> > file to be found. The 3 netinet/ relevant includes are shown below...
> > 
> >> ...
> >> #include <netinet/in.h>
> >> #include <arpa/inet.h>
> >> #include <netinet/sctp_uio.h>
> >> #include <netinet/sctp.h>
> > 
> > More than sctp.h might have such issues since there are 3 netinet/ include 
> > paths in /head/lib/libc/net/sctp_sys_calls.c .
> > 
> > I have not checked for other .c files with similar issues for <netinet/...> 
> > usage during buildworld.
> I guess there is something wrong with the build system / Makefiles such that 
> the entries in the search
> path for include files are in the wrong order. I don't think this is related 
> to the concrete patch
> you are referring to. It only exposes the problem. As I see, you experience 
> similar problems in
> other situations to.
> 
> Maybe someone knowing the build system has to look into it. And it seems to 
> be somewhat platform specific,
> since I have not observed this problem when testing the build on amd64 and 
> arm.
> 
> Best regards
> Michael

This and the other similar reports on current@ appear to be problems
with the xtoolchain ports, not the base build system, and probably
should have been reported to the port's maintainer, or on ports@.  Or
perhaps it's some sort of usage error, I don't know anything about the
xtoolchain stuff.  In any case, there doesn't seem to be anything wrong
with the base build using the supported build mechanisms.

-- Ian


_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to