> On 26 Mar 2015, at 21:36, Mark Millard <markmi_at_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_at_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 0x00000032 >> ./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 /usr/include/netinet/sctp.h /usr/src/sys/netinet/sctp.h >> 34c34 >> < __FBSDID("$FreeBSD: head/sys/netinet/sctp.h 269945 2014-08-13 15:50:16Z tuexen $"); >> --- >>> __FBSDID("$FreeBSD: head/sys/netinet/sctp.h 279859 2015-03-10 19:49:25Z tuexen $"); >> 130a131 >>> #define SCTP_MAX_CWND 0x00000032 > > > > > Context details: > >> make -j 8 CROSS_TOOLCHAIN=powerpc64-gcc >> WITHOUT_CLANG_BOOTSTRAP= WITHOUT_CLANG= WITHOUT_CLANG_IS_CC= \ >> WITHOUT_LLDB= \ >> WITH_GCC_BOOTSTRAP= WITH_GCC= WITHOUT_GNUCXX= \ >> WITHOUT_BOOT= WITHOUT_LIB32= \ >> buildworld buildkernel \ >> KERNCONF=GENERIC64vtsc-NODEBUG >> TARGET=powerpc TARGET_ARCH=powerpc64 > >> # svnlite info /usr/src >> Path: . >> Working Copy Root Path: /usr/src >> URL: https://svn0.us-west.freebsd.org/base/head >> Relative URL: ^/head >> Repository Root: https://svn0.us-west.freebsd.org/base >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> Revision: 280615 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: hselasky >> Last Changed Rev: 280598 >> Last Changed Date: 2015-03-25 06:32:27 -0700 (Wed, 25 Mar 2015) > > signals.h and pthread.h have been updated to more recent than -r280598 in order to avoid the __nonnull issues that exist as of -r280598. > >> # svnlite st /usr/src --no-ignore >> ? /usr/src/.snap >> ? /usr/src/restoresymtable >> M /usr/src/sys/ddb/db_main.c >> M /usr/src/sys/ddb/db_script.c >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >> M /usr/src/sys/powerpc/ofw/ofwcall64.S > > (The .c/.S changes are tied to a PowerMac-G5-specific boot-problem fix and getting information from early boot failures if I get any more. The GENERIC<?>'s remove ps3 in order to have both vt and sc at the same time.) > >> # more /etc/src.conf >> NO_WERROR= >> WITH_LIBCPLUSPLUS= >> CC=/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc >> CXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ >> CPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp >> CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-freebsd/bin/ >> X_COMPILER_TYPE=gcc >> CXXFLAGS+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=gnu++11 -L/usr/obj/usr/srcC/lib/libc++/. >> CXXFLAGS+=-I/usr/include/c++/v1/. -std=gnu++11 -L/usr/lib/. > > (The above and just below experiments with mostly(?) avoiding use of gcc 4.2.1, even for CC/CXX/CPP contexts.) > >> # ls -FPal /usr/bin/g[+c]* >> lrwxr-xr-x 1 root wheel 48 Mar 20 02:03 /usr/bin/g++_at_ -> /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ >> lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc_at_ -> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > >> # more /etc/make.conf >> WRKDIRPREFIX=/usr/obj/portswork >> #WITH_DEBUG= >> MALLOC_PRODUCTION= > > === > Mark Millard > markmi at dsl-only.net > >Received on Fri Mar 27 2015 - 14:17:55 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC