close(2) on a PF_ROUTE socket returns -1 and sets errno to EOPNOTSUPP
Hi, close(2) on a PF_ROUTE socket returns -1 and sets errno to EOPNOTSUPP. I am testing 14.0-CURRENT (main branch) built today. On 13.1-RELEASE-p5 close returns 0. The problem looks to be related to 36b10ac2cd18a535cac20ccf51e3fc6c408671e8. The commit removed rts_disconnect and initialization for .pru_disconnect. After the change, .pr_disconnect is not initialized in rtsock.c so now it is set to pr_disconnect_notsupp. This causes flow of: soclose() sodisconnect() so->so_proto->pr_disconnect() pr_disconnect_notsupp() return EOPNOTSUPP On 13.1 it called the raw socket disconnect which returned ENOTCONN. Noticed in dhcpcd error: if_route (ADD): Operation not supported dhcpcd with privsep called write() which failed with EEXIST (expected since route already existed) and then close() which overwrote the errno to EOPNOTSUPP and the parent process received back EOPNOTSUPP instead of EEXIST. Simple test program (prints error on head, no error on 13.1): #include #include #include #include #include #include #include int main(int argc, char *argv[]) { int s = socket(PF_ROUTE, SOCK_RAW, 0); if (s == -1) err(1, "socket()"); if (close(s) == -1) err(1, "close()"); return 0; } Regards, Guy Yur
Re: Interrupted fputc followed by fprintf in _IOLBF mode causes core dump
On Fri, Mar 25, 2022 at 5:50 PM Mark Johnston wrote: > > On Fri, Mar 25, 2022 at 03:18:40PM +0300, Guy Yur wrote: > > Hi, > > > > dhcpcd on head (Mar 24) and 13.1-BETA2 crashes in fprintf/__sfvwrite. > > It doesn't crash if If I revert the __sflush/__sfvwrite commits: > > 86a16ada1ea608408cec370171d9f59353e97c77 and > > bafaa70b6f9098d83d074968c8e6747ecec1e118. > > > > ... > > Thanks for the reproducer. The bug is akin to that fixed by > bafaa70b6f9098d83d074968c8e6747ecec1e118. Could you please verify that > the patch below fixes the original bug? > > commit 11f817e847b2f06bd543d1bd6cfdff53d69842dc > Author: Mark Johnston > Date: Fri Mar 25 10:46:24 2022 -0400 > > libc: Restore fp state upon flush error in fputc > > diff --git a/lib/libc/stdio/wbuf.c b/lib/libc/stdio/wbuf.c > index e1aa70243e94..6cd75145a271 100644 > --- a/lib/libc/stdio/wbuf.c > +++ b/lib/libc/stdio/wbuf.c > @@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$"); > int > __swbuf(int c, FILE *fp) > { > + unsigned char *old_p; > int n; > > /* > @@ -87,8 +88,15 @@ __swbuf(int c, FILE *fp) > } > fp->_w--; > *fp->_p++ = c; > - if (++n == fp->_bf._size || (fp->_flags & __SLBF && c == '\n')) > - if (__fflush(fp)) > + old_p = fp->_p; > + if (++n == fp->_bf._size || (fp->_flags & __SLBF && c == '\n')) { > + if (__fflush(fp)) { > + if (fp->_p == old_p) { > + fp->_p--; > + fp->_w++; > + } > return (EOF); > + } > + } > return (c); > } Hi, With this patch applied, dhcpcd doesn't crash. Thanks, Guy
Interrupted fputc followed by fprintf in _IOLBF mode causes core dump
Hi, dhcpcd on head (Mar 24) and 13.1-BETA2 crashes in fprintf/__sfvwrite. It doesn't crash if If I revert the __sflush/__sfvwrite commits: 86a16ada1ea608408cec370171d9f59353e97c77 and bafaa70b6f9098d83d074968c8e6747ecec1e118. Stack trace: 0 memcpy () at /usr/src/lib/libc/amd64/string/memmove.S:314 #1 0x0008221c300a in __sfvwrite (fp=, uio=0x8207ad338) at /usr/src/lib/libc/stdio/fvwrite.c:182 #2 0x0008221cc631 in __sprint (fp=0x26fffe, uio=0x8207ad2d7, locale=) at /usr/src/lib/libc/stdio/vfprintf.c:166 #3 io_flush (iop=0x8207ad330, locale=) at /usr/src/lib/libc/stdio/printfcommon.h:157 #4 __vfprintf (fp=fp@entry=0x8222892d0, locale=locale@entry=0x822288ab8 <__xlocale_global_locale>, fmt0=, fmt0@entry=0x204182 "%s", ap=, ap@entry=0x8207ad4e0) at /usr/src/lib/libc/stdio/vfprintf.c:1033 #5 0x0008221c8aea in vfprintf_l (fp=0x8222892d0, locale=0x822288ab8 <__xlocale_global_locale>, fmt0=0x204182 "%s", ap=0x8207ad4e0) at /usr/src/lib/libc/stdio/vfprintf.c:285 #6 0x00222efa in vlogprintf_r (ctx=0x270820 <_logctx>, stream=0x8222892d0, fmt=0x204182 "%s", args=0x8207adad0) at logerr.c:186 ... (gdb) frame 5 #5 0x0008221c8aea in vfprintf_l (fp=0x8222892d0, locale=0x822288ab8 <__xlocale_global_locale>, fmt0=0x204182 "%s", ap=0x8207ad4e0) at /usr/src/lib/libc/stdio/vfprintf.c:285 285 ret = __vfprintf(fp, locale, fmt0, ap); (gdb) p *fp $1 = {_p = 0x27084f <_logctx+47> "e21:3e7c\n42a/64\n", _r = 0, _w = -1025, _flags = 2057, _file = 2, _bf = {_base = 0x270820 <_logctx> "*\"", _size = 1024}, _lbfsize = -1024, _cookie = 0x8222892d0, _close = 0x8221c7b40 <__sclose>, _read = 0x8221c7af0 <__sread>, _seek = 0x8221c7b30 <__sseek>, _write = 0x8221c7b10 <__swrite>, _ub = {_base = 0x0, _size = 0}, _up = 0x0, _ur = 0, _ubuf = "\000\000", _nbuf = "", _lb = {_base = 0x0, _size = 0}, _blksize = 4096, _offset = 0, _fl_mutex = 0x0, _fl_owner = 0x0, _fl_count = 0, _orientation = -1, _mbstate = {__mbstate8 = '\000' , _mbstateL = 0}, _flags2 = 0} (gdb) frame 1 #1 0x0008221c300a in __sfvwrite (fp=, uio=0x8207ad338) at /usr/src/lib/libc/stdio/fvwrite.c:182 182 COPY(w); (gdb) p w $4 = -1 The dhcpcd flow leading to the crash: 1. init with setvbuf _IOLBF on stderr https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/logerr.c#L453 2. fputc with newline called on stderr but is interrupted https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/logerr.c#L187 3. next event received, vfprintf is called on stderr and crashes https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/logerr.c#L186 Simple program that eventually crashes: #include #include #include static void alrm(int signo __unused) { alarm(1); } char buf[1024]; /* use global to not corrupt stack trace in core dump */ int main() { struct sigaction sa; sa.sa_handler = alrm; sigemptyset(_mask); sa.sa_flags = 0; sigaction(SIGALRM, , NULL); setvbuf(stderr, buf, _IOLBF, sizeof(buf)); alarm(1); while (!ferror(stderr)) { fputc('\n', stderr); } fprintf(stderr, "%s", "a"); return 0; } Regards, Guy Yur
no message of the day displayed by login after reboot when update_motd="NO"
Hi, login doesn't display the message of the day when update_motd="NO" after the change to read /var/run/motd instead of /etc/motd. When update_motd="NO": If you create /var/run/motd manually it will be deleted by cleanvar rc script after a reboot. If you keep /var/run as tmpfs nothing creates /var/run/motd. I updated bug 250081 that issue also exists for /var/run that is not tmpfs. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250081 My latest fix attempt was in motd rc script by copying motd.template if motd doesn't exist to solve the /var/run as tmpfs and first install issues, but I didn't know cleanvar also deletes the file, so I don't think it is a good solution for /var/run that is not tmpfs. https://reviews.freebsd.org/D26654 I think reverting /etc/motd change in login(1) and login.conf as suggested in https://reviews.freebsd.org/D26654#610447 is better. motd script will still need modification to always create ${COMPAT_MOTD} symlink. Otherwise, if template already exists, ${COMPAT_MOTD} won't be created and login(1) will not find /etc/motd. I think documentation changes are also required for update_motd="NO" case as was done in second diff: https://reviews.freebsd.org/D26654?id=78733 Regards, Guy Yur ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: adding existing ipv6 network route returns ENOMEM instead of EEXIST if loopback route also exists
Hi, On 25/11/20 1:12 pm, Alexander V. Chernikov wrote: 21.11.2020, 22:48, "Guy Yur" : Hi, When adding a route with a netmask, add_route() in route_ctl.c adds the route with destination address masked. If the add failed (for example, the route exists) it calls lookup_prefix() with the original unmasked destination. Thank you for the report! Indeed, there is a problem w.r.t non-masked dst handling. I'll look into that in the end of this week. Did you get a chance to look at it? I am currently using a workaround of setting RTAX_DST to the masked address before the call to lookup_prefix in add_route(): info->rti_info[RTAX_DST] = rt_key(rt); /* addition failed. Lookup prefix in the rib to determine the cause */ rt_orig = lookup_prefix(rnh, info, _orig); In a scenario where a loopback route was added followed by the network route being added, if the network route is added again and the network route destination is the same as the loopback route, lookup_prefix() will match on the loopback route, not finding the network route and add_route() will return ENOMEM instead of EEXIST. Adding the route with just the network part returns EEXIST as expected. Example: # route -6 add -host fd53:: -prefixlen 128 ::1 # route -6 add -net fd53:: -prefixlen 64 ::1 # route -6 add -net fd53:: -prefixlen 64 ::1 route: writing to routing socket: Cannot allocate memory add net fd53::: gateway ::1 fib 0: Cannot allocate memory # route -6 add -net fd53:: -prefixlen 64 ::1 add net fd53::: gateway ::1 fib 0: route already in table I was testing https://reviews.freebsd.org/D15406 changes applied to r367863. The changes call rtinit to add prefix route when interface address is added/updated and uses the interface address as the destination. rtinit returned ENOMEM instead of EEXIST causing dhcpcd to printCannot allocate memory. route commands above showing the problem were run in r367863 without D15406 changesas well. Thanks, Guy Yur ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Thanks, Guy Yur ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
adding existing ipv6 network route returns ENOMEM instead of EEXIST if loopback route also exists
Hi, When adding a route with a netmask, add_route() in route_ctl.c adds the route with destination address masked. If the add failed (for example, the route exists) it calls lookup_prefix() with the original unmasked destination. In a scenario where a loopback route was added followed by the network route being added, if the network route is added again and the network route destination is the same as the loopback route, lookup_prefix() will match on the loopback route, not finding the network route and add_route() will return ENOMEM instead of EEXIST. Adding the route with just the network part returns EEXIST as expected. Example: # route -6 add -host fd53:: -prefixlen 128 ::1 # route -6 add -net fd53:: -prefixlen 64 ::1 # route -6 add -net fd53:: -prefixlen 64 ::1 route: writing to routing socket: Cannot allocate memory add net fd53::: gateway ::1 fib 0: Cannot allocate memory # route -6 add -net fd53:: -prefixlen 64 ::1 add net fd53::: gateway ::1 fib 0: route already in table I was testing https://reviews.freebsd.org/D15406 changes applied to r367863. The changes call rtinit to add prefix route when interface address is added/updated and uses the interface address as the destination. rtinit returned ENOMEM instead of EEXIST causing dhcpcd to printCannot allocate memory. route commands above showing the problem were run in r367863 without D15406 changesas well. Thanks, Guy Yur ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg.c revision 367687 breaks pkg
On 15/11/20 8:55 pm, Scott Long wrote: This is fixed in revision 367701 Scott Hi, I am on revision 367710 (newer) and have the same problem. sysctlbyname() returns an empty string and length of 1. sysctl() with name converted to mib works fine. ssize_t tmplen; char path[1000] = { 0 }; tmplen = getlocalbase(path, sizeof(path)); printf("%s : %zd\n", path, tmplen); tmplen = sizeof(path); if (sysctlbyname("user.localbase", path, (size_t *), NULL, 0) == 0) printf("%s : %zd\n", path, tmplen); int mib[100] = { 0 }; size_t miblen; if (sysctlnametomib("user.localbase", mib, ) == 0) { for (int i = 0; i < miblen; i++) printf("%d ", mib[i]); printf("\n"); } tmplen = sizeof(path); if (sysctl(mib, miblen, path, (size_t *), NULL, 0) == 0) printf("%s : %zd\n", path, tmplen); prints: : 1 : 1 8 21 /usr/local : 11 Thanks, Guy Yur On Nov 15, 2020, at 11:52 AM, Manfred Antar wrote: pkg.c revision 367687 breaks pkg : (pkg)5052}pkg The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: This is after upgrading to the latest pkg and libutil. pkg.c version 367075 works: (pkg)5057}pkg pkg: not enough arguments Usage: pkg [-v] [-d] [-l] [-N] [-j |-c |-r ] [-C ] [-R ] [-o var=value] [-4|-6] [] For more information on available commands and options see 'pkg help’. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: emulators/qemu-user-static needs MAP_GUARD support
Hi Alan, On 1 July 2017 at 23:07, Alan Cox <alan.l@gmail.com> wrote: > > On Sat, Jul 1, 2017 at 2:46 PM, Guy Yur <guy...@gmail.com> wrote: >> >> Hi, >> >> I tried to run armv6 /bin/sh in a chroot on an >> amd64 host using qemu-arm-static. >> It failed on invalid argument to mmap. >> >> # cp /usr/local/bin/qemu-arm-static /chroots/armv6/root/ >> # chroot /chroots/armv6 /root/qemu-arm-static /bin/sh >> /lib/libedit.so.7: mmap of entire address space failed: Invalid argument >> >> ... snipped >> > > MAP_ANON should not be passed to mmap(2) at the same time as MAP_GUARD. > Passing MAP_FIXED at the same time is okay. > The problem is definitely in qemu user mode mmap emulation code. https://github.com/seanbruno/qemu-bsd-user/blob/bsd-user/bsd-user/mmap.c#L464 qemu adds MAP_FIXED | MAP_ANONYMOUS if MAP_FIXED is not set in flags when the emulated mmap call is done. So rtld-elf passes MAP_GUARD and the kernel receives MAP_GUARD and MAP_ANON and rejects the call. Do you know if the MAP_ANONYMOUS is needed in the call? I am currently using a workaround patch to convert MAP_GUARD to MAP_PRIVATE | MAP_ANON | MAP_NOCORE (like rtld-elf does if OS version doesn't support MAP_GUARD). https://github.com/guyyur/freebsd-ports_patches/blob/master/emulators_qemu-sbruno__MAP_GUARD_workaround.patch With the patch qemu-arm-static is working. I would prefer using a better fix that retains the MAP_GUARD protections. Thanks, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
running binary in chroot using qemu-arm-static fails to mmap after r320318
Hi, I tried to run armv6 /bin/sh in a chroot on an amd64 host using qemu-arm-static. It failed on invalid argument to mmap. # cp /usr/local/bin/qemu-arm-static /chroots/armv6/root/ # chroot /chroots/armv6 /root/qemu-arm-static /bin/sh /lib/libedit.so.7: mmap of entire address space failed: Invalid argument rtld-elf only passes MAP_GUARD but ktrace shows mmap is called with MAP_FIXED and MAP_ANON too. I think qemu-user-static adds the flags in bsd-user/mmap.c target_mmap(). Does the qemu-user-static port need patching to support MAP_GUARD? ktrace snipet: 1072 qemu-arm-static CALL openat(AT_FDCWD,0xf4ff9020,0x30) 1072 qemu-arm-static NAMI "/lib/libc.so.7" 1072 qemu-arm-static RET openat 3 1072 qemu-arm-static CALL fstat(0x3,0x7ffe9680) 1072 qemu-arm-static STRU struct stat {dev=687931144, ino=192007, mode=0100444, nlink=1, uid=0, gid=0, rdev=1548632, atime=1498921861.605975000, mtime=1498921861.608547000, ctime=1498921861.609724000, birthtime=1498921861.605973000, size=1720888, blksize=32768, blocks=3456, flags=0x2 } 1072 qemu-arm-static RET fstat 0 1072 qemu-arm-static CALL mmap(0xf4ff7000,0x1000,0x1,0x41012 ,0x,0) 1072 qemu-arm-static RET mmap 4110381056/0xf4ff7000 1072 qemu-arm-static CALL mmap(0xf4ff7000,0x1000,0x1,0x40012 ,0x3,0) 1072 qemu-arm-static RET mmap 4110381056/0xf4ff7000 1072 qemu-arm-static CALL mmap(0xf4e37000,0x1c,0,0x3010 ,0x,0) 1072 qemu-arm-static RET mmap -1 errno 22 Invalid argument Thanks, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: compiler-metadata.mk for main arch deleted when crossbuilding
On 23 June 2017 at 21:50, Bryan Drewery <bdrew...@freebsd.org> wrote: > On 6/23/2017 11:28 AM, Bryan Drewery wrote: >> On 6/23/2017 11:00 AM, Guy Yur wrote: >>> Hi Bryan, >>> >>> I use a script for building both amd64 and armv6 on an amd64 machine. >>> Basically, >>> export TARGET=amd64 TARGET_ARCH=amd64 >>> make -j2 -DNO_CLEAN buildworld >>> export TARGET=arm TARGET_ARCH=armv6 >>> make -j2 -DNO_CLEAN buildworld >>> >>> The amd64 build creates /usr/obj/usr/src/compiler-metadata.mk >>> The armv6 build deletes it and creates >>> /usr/obj/arm.armv6/usr/src/compiler-metadata.mk >>> >>> If I rebuild just amd64 I get /usr/obj/usr/src/compiler-metadata.mk again. >>> >>> Does _cross-tools target's "@rm -f ${.OBJDIR}/compiler-metadata.mk" >>> not respect TARGET and TARGET_ARCH? >>> >> >> Yes, it is fixed now in r320286. Thanks for the report! >> >> > > This may have been the reason release.sh failed earlier. Is release.sh > still failing for you now? Hi, It fixed my problem. My problem was that I couldn't do installworld or distributeworld for the main arch after buildworld + cross buildworld. I thought it was the same problem as the release.sh failure when I replied to the other thread, sorry for the confusion. > > -- > Regards, > Bryan Drewery > Thanks, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
compiler-metadata.mk for main arch deleted when crossbuilding
Hi Bryan, I use a script for building both amd64 and armv6 on an amd64 machine. Basically, export TARGET=amd64 TARGET_ARCH=amd64 make -j2 -DNO_CLEAN buildworld export TARGET=arm TARGET_ARCH=armv6 make -j2 -DNO_CLEAN buildworld The amd64 build creates /usr/obj/usr/src/compiler-metadata.mk The armv6 build deletes it and creates /usr/obj/arm.armv6/usr/src/compiler-metadata.mk If I rebuild just amd64 I get /usr/obj/usr/src/compiler-metadata.mk again. Does _cross-tools target's "@rm -f ${.OBJDIR}/compiler-metadata.mk" not respect TARGET and TARGET_ARCH? Thanks, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: release.sh: sh: head: not found \n Unable to determine linker type from LD=ld
On 23 June 2017 at 15:36, Alastair Hoggewrote: > Hi, > > My 12.0-CURRENT r320259 host is unable to complete a release.sh build of > a generic world: > > [...] > =/tmp/install.hb5C6cay PATH_LOCALE=/tmp/install.hb5C6cay/locale rm -rf > /tmp/install.hb5C6cay > sh: head: not found > make[4]: "/usr/src/share/mk/bsd.linker.mk" line 42: Unable to determine > linker type from LD=ld > *** Error code 1 > > ... > > To good health, > Alastair > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Hi, I got the same error with r320258. Is it because "head" is not part of the bootstrap tools? I was able to continue by replacing "| head 1" with "| sed -n 1p" in _ld_version!= ${${ld}} --version 2>/dev/null | head -n 1 || echo none head is not in /tmp/install.RANDOMVALUES but sed is. Regards, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
IPV6_ORIGDSTADDR documentation in ip6.4 man page was added commented out in r314722
Hi, Support for IPV6_ORIGDSTADDR was added in r314722 with the option documentation commented out in the ip6.4 man page. Should it be uncommented? Patch: https://github.com/guyyur/freebsd-src_patches/blob/master/man4_ip6_updates/uncomment_IPV6_ORIGDSTADDR.patch Also, if anyone is interested, OpenBSD updated their version of ip6.4 a few years ago with APIs/options from RFC3542. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/man/man4/ip6.4 I put a series of patches in bug 197256 taking revisions 1.25, 1.26, 1.29, 1.31, 1.32, 1.33, 1.34 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197256 Thanks, Guy Yur ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
resolvconf Makefile RESTARTCMD sed after r312992
Hi, In openresolv 3.9.0, the only RESTARTCMD pattern left is @RESTARTCMD@. The '@RESTARTCMD something@' pattern was dropped from pdns_recursor.in. r312992 removed RESTARTCMD_WITH_ARG for @RESTARTCMD something@ but reverted the sed to be '@RESTARTCMD \(.*\)@' and RESTARTCMD= to be the value of RESTARTCMD_WITH_ARG. After the change /sbin/resolvconf has 'RESTARTCMD=@RESTARTCMD@' again. Attaching patch to restore RESTARTCMD=, CMD1=, CMD2= and sed pattern to values before r312992. Thanks, Guy resolvconf_RESTARTCMD_sed.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: installworld fails on missing tzsetup when WITHOUT_DIALOG is set
On Sat, Oct 22, 2016 at 7:23 PM, Baptiste Daroussin <b...@freebsd.org> wrote: > On Sat, Oct 22, 2016 at 06:51:28PM +0300, Guy Yur wrote: >> Hi, >> ... > > My proposal is a bit different: build tzsetup without dialog support :) > > https://reviews.freebsd.org/D8325 > > Best regards, > Bapt Thanks. Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
installworld fails on missing tzsetup when WITHOUT_DIALOG is set
Hi, installworld fails on missing tzsetup when src.conf has WITHOUT_DIALOG= and delete-old was previously run to remove tzsetup from the system. mkdir -p /tmp/install.8gNIwAFV progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp date echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm sed services_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis; do if progpath=`which $prog`; then echo $progpath; else echo "Required tool $prog not found in PATH." >&2; exit 1; fi; done); libs=$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do set -- $line; if [ "$2 $3" != "not found" ]; then echo $2; else echo "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $progs /tmp/install.8gNIwAFV Required tool tzsetup not found in PATH. *** Error code 1 tzsetup is used in share/zoneinfo/Makefile when ${DESTDIR}/var/db/zoneinfo exists and some other conditions. In my case, I don't have /var/db/zoneinfo since I manually created a symlink from /usr/share/zoneinfo/... to /etc/localtime instead of using tzsetup. A possible fix is to add a WITHOUT_TZSETUP knob and not use tzsetup when the knob is enabled. https://github.com/guyyur/freebsd-src_patches/blob/master/without_tzsetup_knob.patch (patch doesn't include regenerating src.conf.5) Thanks, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic "wlock already held" when changing ipv6 default route
On Fri, Mar 25, 2016 at 8:14 AM, Alexander V. Chernikov <melif...@freebsd.org> wrote: > 25.03.2016, 02:11, "Guy Yur" <guy...@gmail.com>: >> Hi, >> >> When changing the ipv6 default route I get a panic on wlock already held. >> Could be related to r293424 lock changes, haven't checked an older version >> yet. > Hi, > Yes, there is a problem when the default route next hop is filled in > incorrectly, so lookup fails (e.g. matches previous one). > Will be fixed soon. > > Thanks for the report. >> >> route add -inet6 default fe80::7 >> route change -inet6 default fe80::7 >> >> panic: rw_rlock: wlock already held for rib head lock @ >> /usr/src/sys/net/route.c:445 >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe0050ee01d0 >> vpanic() at vpanic+0x182/frame 0xfe0050ee0250 >> kassert_panic() at kassert_panic+0x126/frame 0xfe0050ee02c0 >> __rw_rlock() at __rw_rlock+0xe7/frame 0xfe0050ee0360 >> rtalloc1_fib() at rtalloc1_fib+0x86/frame 0xfe0050ee0420 >> ifa_ifwithroute() at ifa_ifwithroute+0x83/frame 0xfe0050ee0460 >> rt_getifa_fib() at rt_getifa_fib+0xe7/frame 0xfe0050ee0480 >> rtrequest1_fib() at rtrequest1_fib+0x59c/frame 0xfe0050ee0570 >> route_output() at route_output+0x653/frame 0xfe0050ee07c0 >> sosend_generic() at sosend_generic+0x436/frame 0xfe0050ee0880 >> soo_write() at soo_write+0x42/frame 0xfe0050ee08b0 >> dofilewrite() at dofilewrite+0x87/frame 0xfe0050ee0900 >> kern_writev() at kern_writev+0x68/frame 0xfe0050ee0950 >> sys_write() at sys_write+0x60/frame 0xfe0050ee09a0 >> amd64_syscall() at amd64_syscall+0x2db/frame 0xfe0050ee0ab0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0050ee0ab0 >> --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x800977b7ba, rsp = >> 0x7fffe2d8, rbp = 0x7fffeb90 --- >> KDB: enter: panic >> [ thread pid 644 tid 100054 ] >> Stopped at kdb_enter+0x3b: movq $0,kdb_why >> Hi, Opened bug 211602 so this won't get lost. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211602 Also happens when the gateway route was deleted so not specific to link-local addresses. # route add -inet6 2001:db8:0::/64 fe80::7%lo0 # route add -inet6 2001:db8:1::/64 2001:db8:0::1 # route delete -inet6 2001:db8:0::/64 # route change -inet6 2001:db8:1::/64 2001:db8:0::1 I restored RTF_RNH_LOCKED locally as a workaround so rtalloc1_fib won't try to lock when rtrequest1_fib already took a lock before calling rtrequest1_fib_change. On a related note, also mentioned by Bjoern, should link-local gateway addresses without %IF zone index be accepted? This can be confusing when you forget the %IF and think you added the route correctly but it is acting as a black hole. I forgot the %IF when adding the default route and stumbled on this panic. On OpenBSD when the gateway is missing the zone index the route is rejected. # route add -inet6 default fe80::7 route: writing to routing socket: Network is unreachable add net default: gateway fe80::7: Network is unreachable Thanks, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062
On Sun, Jul 31, 2016 at 9:09 PM, Pedro Giffuni <p...@freebsd.org> wrote: > > > On 07/31/16 11:56, Guy Yur wrote: >> >> Hi, >> >> I meant for the RESTARTCMD_= statement to be added too. >> I should have sent a patch file. >> > > Ugh ... yeah I am really bad at "guessing" patches. > > I will play with your patch. Thanks. > > Pedro. Thanks. fix for pdns_recursor was applied upstream. http://roy.marples.name/projects/openresolv/info/4bb3467d4ac799f2 When a new openresolv release is made it will be possible to drop the _WITH_ARG vars. Guy. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062
On Sun, Jul 31, 2016 at 5:46 AM, Pedro Giffuniwrote: > > >>> Index: sbin/resolvconf/Makefile >>> === >>> --- sbin/resolvconf/Makefile(revision 303557) >>> +++ sbin/resolvconf/Makefile(working copy) >>> @@ -30,6 +30,7 @@ >>> -e 's:@LIBEXECDIR@:${FILESDIR}:g' \ >>> -e 's:@VARDIR@:${VARDIR}:g' \ >>> -e 's:@RESTARTCMD \(.*\)@:${RESTARTCMD}:g' \ >>> + -e 's:@RESTARTCMD@:${RESTARTCMD}:g' \ >>> -e 's:@RCDIR@:${RCDIR}:g' \ >>> -e 's: vpn : ng[0-9]*&:g' \ >>> ${DIST}/$@.in > $@ >> >> > > And the underscore was not a typo. > Thanks Guy! > > Pedro. Hi, I meant for the RESTARTCMD_= statement to be added too. I should have sent a patch file. Issue could be seen during boot if using dhcpcd which invokes resolvconf or by running 'resolvconf -r SERVICENAME' With r303567, RESTARTCMD is now empty in the script so dynamic detection for service command is done. Attaching new patch. 1. Renaming RESTARTCMD, CMD1, CMD2 to _WITH_ARG since it is only used by pdns_recursor.in. The other files have all moved to use $RESTARTCMD passed from resolvconf. I will send a patch upstream to do the same for pdns_recursor.in. The ugly _WITH_ARG vars can be removed when pdns_recursor.in is updated to new style. 2. Renaming RESTARTCMD_ to RESTARTCMD and adding the lines for new CMD1, CMD2, RESTARTCMD statements. Thanks, Guy resolvconf_RESTARTCMD.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
resolvconf needs @RESTARTCMD@ to be replaced after r303062
Hi, openresolv 3.8.1 added RESTARTCMD=@RESTARTCMD@ in contrib/openresolv/resolvconf.in. It is not replaced by the sed expressions in sbin/resolvconf/Makefile. Error seen is "eval: @RESTARTCMD@: not found". Current @RESTARTCMD \(.*\)@ sed expression needs to be kept for pdns_recursor.in and a new expression added to replace @RESTARTCMD@. The following worked for me: RESTARTCMD_="/usr/sbin/service \\$$1 onestatus >/dev/null 2>\&1 \&\& /usr/sbin/service \\$$1 restart" sed ... \ ... \ -e 's:@RESTARTCMD@:${RESTARTCMD_}:g' \ ... Regards, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: crossbuild buildworld on amd64 for arm fails to find KERNCONF GENERIC after r302865
On Fri, Jul 15, 2016 at 6:11 PM, Cy Schubert <cy.schub...@komquats.com> wrote: > In message <CAC67Hz-ZqcYR3p4fR+cBiBcju3JrOxtU+wTr6hwMn_eoo=Wedw@mail.gmail.c > om> > , Guy Yur writes: >> Hi, >> >> I am trying to crossbuild arm on an amd64 machine and buildworld >> is checking for KERNCONF and fails to find GENERIC kernel. >> I only set KERNCONF when I am doing buildkernel/installkernel >> so KERNCONF is the default set in Makefile.inc1. >> >> # make buildworld TARGET=arm TARGET_ARCH=armv6 >> make[1]: "/usr/src/Makefile.inc1" line 122: SYSTEM_COMPILER: >> Determined that CC=cc matches the source tree. Not bootstrapping a >> cross-compiler. >> make[1]: "/usr/src/Makefile.inc1" line 1144: Missing KERNCONF >> /usr/src/sys/arm/conf/GENERIC >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/src >> >> >> # uname -a >> FreeBSD vm4.localdomain 12.0-CURRENT FreeBSD 12.0-CURRENT #13 >> r302895M: Fri Jul 15 16:06:24 IDT 2016 >> root@vm4.localdomain:/usr/obj/usr/src/sys/VIRTUALBOX amd64 > > Thanks for the report. I've reverted it now until I get the time to look at > it more closely. > > > -- > Cheers, > Cy Schubert <cy.schub...@cschubert.com> > FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > Doing the missing check only for the kernel targets works for me. .if make(buildkernel) || \ make(installkernel) || make(installkernel.debug) || \ make(reinstallkernel) || make(reinstallkernel.debug) || \ make(distributekernel) || make(distributekernel.debug) || \ make(packagekernel) || make(create-kernel-packages) .error Missing KERNCONF ${KERNCONFDIR}/${_kernel} .endif It might be possible cover more of the section with the .if make. I think these are all the targets that use BUILDKERNELS, INSTALLKERNEL. .if make(buildkernel) || \ make(installkernel) || make(installkernel.debug) || \ make(reinstallkernel) || make(reinstallkernel.debug) || \ make(distributekernel) || make(distributekernel.debug) || \ make(packagekernel) || make(create-kernel-packages) BUILDKERNELS= ... .error Missing KERNCONF ${KERNCONFDIR}/${_kernel} .endif .endfor .endif Regards, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
crossbuild buildworld on amd64 for arm fails to find KERNCONF GENERIC after r302865
Hi, I am trying to crossbuild arm on an amd64 machine and buildworld is checking for KERNCONF and fails to find GENERIC kernel. I only set KERNCONF when I am doing buildkernel/installkernel so KERNCONF is the default set in Makefile.inc1. # make buildworld TARGET=arm TARGET_ARCH=armv6 make[1]: "/usr/src/Makefile.inc1" line 122: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 1144: Missing KERNCONF /usr/src/sys/arm/conf/GENERIC *** Error code 1 Stop. make: stopped in /usr/src # uname -a FreeBSD vm4.localdomain 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r302895M: Fri Jul 15 16:06:24 IDT 2016 root@vm4.localdomain:/usr/obj/usr/src/sys/VIRTUALBOX amd64 Thanks, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4
Hi, On Sat, Jun 25, 2016 at 12:20 PM, Konstantin Belousov <kostik...@gmail.com> wrote: > On Sat, Jun 25, 2016 at 11:49:39AM +0300, Konstantin Belousov wrote: >> On Sat, Jun 25, 2016 at 01:03:13AM +0300, Guy Yur wrote: >> > libtdb.so.1`tdb_runtime_check_for_robust_mutexes + 1475 at mutex.c:957 >> > ... >> >> The pointer to tdb_runtime_check_for_robust_mutexes() appeared to be >> most useful, thanks. >> >> The two patches below should fix samba use of robustness. First, >> kernel erronously reset robust lists locations on fork. Second, the >> pthread_mutex_trylock() for owned errorcheck mutex must return EDEADLK >> and not EBUSY. Try that. > > Correction, there was a reason why I initially put the rb list pointers > into zeroed region. It still needs to be zeroed on new thread creation. > Updated patch. > With the patch to the 3 files applied, smbd, nmbd and smbclient no longer crash on my machine. Tested with r302191+patch. Thanks, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4
Hi, I got the same crash on a VirtualBox VM with r302170 and samba43-4.3.9, tdb-1.3.9,1. Based on the smbd log, when I was on r301989 smbd didn't crash. smbd started crashing when I installed r302170 today. gdb 6.1.1 and 7.11.1 don't see the shared libraries for some reason so I don't get the symbols when opening the core file. lldb works fine. smbclient, smbd, nmbd all panic at the same location: tdb_runtime_check_for_robust_mutexes when calling _pthread_mutex_destroy. When running 'lldb /usr/local/bin/smbclient //HOST/Share', If I point a breakpoint at mutex_assert_not_owned and 'cont' each time, there is no crash (m_qe pointers are both null). Putting a breakpoint at mutex.c:957 and then breaking at mutex_assert_not_owned, I see m_qe.tqe_prev is not null. It points to a null pointer. Core file '/var/tmp/smbclient.50434.core' (x86_64) was loaded. (lldb) bt * thread #1: tid = 100179, 0x0008047bfcda libc.so.7`thr_kill + 10, name = 'smbclient', stop reason = signal SIGABRT * frame #0: 0x0008047bfcda libc.so.7`thr_kill + 10 frame #1: 0x0008047bfcab libc.so.7`__raise(s=6) + 59 at raise.c:52 [opt] frame #2: 0x0008047bfc19 libc.so.7`abort + 73 at abort.c:65 [opt] frame #3: 0x000801481d7a libthr.so.3`_thread_exitf(fname=, lineno=, fmt=) + 138 at thr_exit.c:190 [opt] frame #4: 0x00080147bcf9 libthr.so.3`mutex_assert_not_owned(curthread=, m=) + 121 at thr_mutex.c:152 [opt] frame #5: 0x00080147bc27 libthr.so.3`_pthread_mutex_destroy(mutex=0x0008012e9000) + 87 at thr_mutex.c:474 [opt] frame #6: 0x000809abdce3 libtdb.so.1`tdb_runtime_check_for_robust_mutexes + 1475 at mutex.c:957 ... (lldb) f 6 frame #6: 0x000809abdce3 libtdb.so.1`tdb_runtime_check_for_robust_mutexes + 1475 at mutex.c:957 954 } 955 } 956 if (m != NULL) { -> 957 pthread_mutex_destroy(m); 958 } 959 if (cleanup_ma) { 960 pthread_mutexattr_destroy(); lldb for smbclient with breakpoint: * thread #1: tid = 100104, 0x00080147bc8b libthr.so.3`mutex_assert_not_owned(curthread=0x000810816000, m=0x000801352000) + 11 at thr_mutex.c:150, stop reason = breakpoint 2.1 frame #0: 0x00080147bc8b libthr.so.3`mutex_assert_not_owned(curthread=0x000810816000, m=0x000801352000) + 11 at thr_mutex.c:150 [opt] 147 { 148 149 #if defined(_PTHREADS_INVARIANTS) -> 150 if (__predict_false(m->m_qe.tqe_prev != NULL || 151 m->m_qe.tqe_next != NULL)) 152 PANIC("mutex %p own %#x is on list %p %p", 153 m, m->m_lock.m_owner, m->m_qe.tqe_prev, m->m_qe.tqe_next); (lldb) p *m (pthread_mutex) $3 = { m_lock = { m_owner = 100180 m_flags = 17 m_ceilings = ([0] = 0, [1] = 0) m_rb_lnk = 0 m_spare = ([0] = 0, [1] = 0) } m_flags = 1 m_count = 0 m_spinloops = 0 m_yieldloops = 0 m_ps = 2 m_qe = { tqe_next = 0x tqe_prev = 0x0008108161a0 } m_pqe = { tqe_next = 0x tqe_prev = 0x } m_rb_prev = 0x } (lldb) p *m->m_qe.tqe_prev (pthread_mutex *) $5 = 0x Regards, Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic "wlock already held" when changing ipv6 default route
Hi, When changing the ipv6 default route I get a panic on wlock already held. Could be related to r293424 lock changes, haven't checked an older version yet. route add -inet6 default fe80::7 route change -inet6 default fe80::7 panic: rw_rlock: wlock already held for rib head lock @ /usr/src/sys/net/route.c:445 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0050ee01d0 vpanic() at vpanic+0x182/frame 0xfe0050ee0250 kassert_panic() at kassert_panic+0x126/frame 0xfe0050ee02c0 __rw_rlock() at __rw_rlock+0xe7/frame 0xfe0050ee0360 rtalloc1_fib() at rtalloc1_fib+0x86/frame 0xfe0050ee0420 ifa_ifwithroute() at ifa_ifwithroute+0x83/frame 0xfe0050ee0460 rt_getifa_fib() at rt_getifa_fib+0xe7/frame 0xfe0050ee0480 rtrequest1_fib() at rtrequest1_fib+0x59c/frame 0xfe0050ee0570 route_output() at route_output+0x653/frame 0xfe0050ee07c0 sosend_generic() at sosend_generic+0x436/frame 0xfe0050ee0880 soo_write() at soo_write+0x42/frame 0xfe0050ee08b0 dofilewrite() at dofilewrite+0x87/frame 0xfe0050ee0900 kern_writev() at kern_writev+0x68/frame 0xfe0050ee0950 sys_write() at sys_write+0x60/frame 0xfe0050ee09a0 amd64_syscall() at amd64_syscall+0x2db/frame 0xfe0050ee0ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0050ee0ab0 --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x800977b7ba, rsp = 0x7fffe2d8, rbp = 0x7fffeb90 --- KDB: enter: panic [ thread pid 644 tid 100054 ] Stopped at kdb_enter+0x3b: movq$0,kdb_why Booted into livecd with snapshot iso in a VirtualBox VM and ran the commands above. FreeBSD-11.0-CURRENT-amd64-20160308-r296485-bootonly.iso -- Guy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ncurses (non-w) is missing from _LIBRARIES= in src.libnames.mk
Hi, ncurses (non-w version) is missing from _LIBRARIES= in src.libnames.mk This causes libmenu, libpanel and libform to not list ncurses as a needed library. head r275469M i386: readelf -d /usr/lib/libmenu.so | grep NEEDED 0x0001 (NEEDED) Shared library: [libc.so.7] readelf -d /usr/lib/libmenuw.so | grep NEEDED 0x0001 (NEEDED) Shared library: [libncursesw.so.8] 0x0001 (NEEDED) Shared library: [libc.so.7] 10.1-RELEASE i386: readelf -d /usr/lib/libmenu.so | grep NEEDED 0x0001 (NEEDED) Shared library: [libncurses.so.8] 0x0001 (NEEDED) Shared library: [libc.so.7] net/samba41 builds samba-regedit with a dependency on libmenu, libpanel and libform. The missing ncurses causes the configure scripts to fail building the testprog and assume libmenu, libpanel and libform don't exist. samba config.log ... [2/2] Linking default/testprog /usr/lib/libmenu.so: undefined reference to `subpad' ... - Guy ___ 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: delete-old issue with src.opts.mk
Hi, On Sat, May 10, 2014 at 10:54 PM, Warner Losh i...@bsdimp.com wrote: On May 10, 2014, at 9:45 AM, Thomas Hoffmann trh...@gmail.com wrote: Three questions: 1. Why is delete-old repeatedly asking me if I want to remove /usr/share/mk/ src.opts.mk? It seems to keep getting installed. It shouldn’t be now that I’ve got things ironed out. src.opts.mk is still listed in share/mk/Makefile. Added in r265419 Listed twice after r265420 bsd.own.mk - src.opts.mk Listed once after r265628 src.opts.mk - bsd.own.mk Should it be removed? Index: share/mk/Makefile === --- share/mk/Makefile (revision 265856) +++ share/mk/Makefile (working copy) @@ -42,9 +42,6 @@ sys.mk \ version_gen.awk -# Installed for the moment, but not may not be in the future. -FILES+=src.opts.mk - NO_OBJ= FILESDIR= ${BINDIR}/mk - Guy ___ 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: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
Hi, On Fri, May 9, 2014 at 2:54 AM, Warner Losh i...@bsdimp.com wrote: On May 8, 2014, at 3:26 PM, Guy Yur guy...@gmail.com wrote: Hi, After the bsd.opts.mk / src.opts.mk split WITHOUT_NIS in src.conf doesn't work. It should still work… At least that’s the intention... src.conf is included in src.opts.mk after bsd.own.mk which includes bsd.opts.mk. Yea, that’s a problem… It should be included after. Your fix worked for me. Another issue that is probably very uncommon so I don't know if anything should be done about it: WITHOUT_NIS, WITHOUT_KERBEROS and WITHOUT_OPENSSH also affect bsd.libnames.mk definition of LIBPAM and MINUSLPAM in case you build programs with bsd make outside of /usr/src that use LIBPAM/MINUSLPAM and have NO_SHARED / LDFLAGS+=-static. The addition of ${LIBYPCLNT} / -lypclnt to LDFLAGS will fail to link if world was installed without NIS. A brief look in the ports tree doesn't show any program that does this. Thanks, Guy ___ 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
WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
Hi, After the bsd.opts.mk / src.opts.mk split WITHOUT_NIS in src.conf doesn't work. src.conf is included in src.opts.mk after bsd.own.mk which includes bsd.opts.mk. Should bsd.opts.mk options overrides now be set in make.conf instead of src.conf? Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN. Thanks, Guy ___ 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