close(2) on a PF_ROUTE socket returns -1 and sets errno to EOPNOTSUPP

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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"

[Guy Yur]

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

[Guy Yur]

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

[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.

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

On 23 June 2017 at 15:36, Alastair Hogge  wrote:
> 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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

On Sun, Jul 31, 2016 at 5:46 AM, Pedro Giffuni  wrote:
>
>
>>> 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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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

[Guy Yur]

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