Re: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598
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
Re: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598
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
The problem details:
/head/lib/libc/net/sctp_sys_calls.c -r279859 added:
case SCTP_MAX_CWND:
((struct sctp_assoc_value *)arg)-assoc_id = id;
break;
and head (20150325 r280598) contains it.
But the SCTP_MAX_CWND reference blocks buildworld (for at least
/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc (powerpc64-xtoolchain=gcc)
use):
/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 -pipe
-I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include
-I/usr/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE
-I/usr/src/lib/libc/../../contrib/gdtoa
-I/usr/src/lib/libc/../../contrib/libc-vis -DINET6
-I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE
-DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd
-I/usr/src/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION
-I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime
-I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN
-I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING
-DSYSCALL_COMPAT -std=gnu99 -fstack-protector -Wsystem-headers -Wall
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c
/usr/src/lib/libc/net/sctp_sys_calls.c -o sctp_sys_calls.So
/usr/src/lib/libc/net/sctp_sys_calls.c: In function 'sctp_opt_info':
/usr/src/lib/libc/net/sctp_sys_calls.c:386:7: error: 'SCTP_MAX_CWND'
undeclared (first use in this function)
case SCTP_MAX_CWND:
^
Looking to see where usage and definitions might be in /usr/src for -r280598
...
# pwd
/usr/src
$ find . \( -type d -name .svn -prune \) -or \( -type f -exec grep
SCTP_MAX_CWND {} \; -print \) | more
case SCTP_MAX_CWND:
./lib/libc/net/sctp_sys_calls.c
case SCTP_MAX_CWND:
case SCTP_MAX_CWND:
./sys/netinet/sctp_usrreq.c
#define SCTP_MAX_CWND 0x0032
./sys/netinet/sctp.h
And looking at the list of includes in /head/lib/libc/net/sctp_sys_calls.c
for -r279859 shows:
#include sys/cdefs.h
__FBSDID($FreeBSD$);
#include stdio.h
#include string.h
#include errno.h
#include stdlib.h
#include unistd.h
#include sys/types.h
#include sys/socket.h
#include sys/errno.h
#include sys/syscall.h
#include sys/uio.h
#include netinet/in.h
#include arpa/inet.h
#include netinet/sctp_uio.h
#include netinet/sctp.h
That there was no complaint about sctp.h being missing suggests that a
netinet/sctp.h was found but did not contain a SCTP_MAX_CWND definition: so
a different one than the above find/grep reported.
Using a find to report other sctp.h files shows:
# find / \( -type d -name .svn -prune \) -or \( -type f -name sctp.h -print
\) | more
/usr/src/sys/netinet/sctp.h
/usr/include/netinet/sctp.h
The diff of those shows the problem if the wrong file is found and used:
# diff
