sanitizers broken (was RE: libc/libsys split coming soon)

Hi, I updated yesterday and now event a minimal program with cc -fsanitize=address produces ld: error: undefined symbol: __elf_aux_vector >>> referenced by sanitizer_linux_libcdep.cpp:950 >>> (/usr/src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:950) >>>

RE: Is "/usr/bin/sscop" still relevant? (related to ATM)

Yes. harti From: Warner Losh Sent: Tuesday, November 10, 2020 10:27 PM To: Brandt, Hartmut Cc: mj-mailingl...@gmx.de; FreeBSD Current Subject: Re: Is "/usr/bin/sscop" still relevant? (related to ATM) So both the kernel and userland parts can go away? ./contrib/ngatm/sscop ./sys/modules/netgr

RE: Is "/usr/bin/sscop" still relevant? (related to ATM)

Hi, this can go away. It is the transport protocol underlying ATM signaling. harti -Original Message- From: owner-freebsd-curr...@freebsd.org On Behalf Of mj-mailingl...@gmx.de Sent: Monday, November 9, 2020 10:07 PM To: freebsd-current@freebsd.org Subject: Is "/usr/bin/sscop" still re

make problem

Hi, what is wrong with the following Makefile? FILES= a.in b.in a b FILESDIR= /tmp/foo .include .SUFFIXES: .in .in: cp $(.IMPSRC) $(.TARGET) Given that a.in and b.in exist and 'make' has been executed, 'make install' gives the following error: # sudo make install installing DIRS FI

RiscV tinderbox fails

Hi, is it supposed not to fail? I get: /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In function `__gedf2': /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:101: multiple definition of `__gedf2' /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(gedf2.o):/usr/src/li

RE: int128_t and uint128_t typeinfo

Now that appears to work. Thanks, harti -Original Message- From: Dimitry Andric [mailto:d...@freebsd.org] Sent: Wednesday, February 22, 2017 7:49 PM To: Brandt, Hartmut Cc: curr...@freebsd.org Subject: Re: int128_t and uint128_t typeinfo I had to commit a follow-up fix in r314104: when

RE: int128_t and uint128_t typeinfo

Looks like they are still not there. I've rebuilt world. nm -D -C /usr/lib/libcxxrt.so | grep 128 should show me the symbols, right? It does not. harti -Original Message- From: Dimitry Andric [mailto:d...@freebsd.org] Sent: Tuesday, February 21, 2017 10:52 PM To: Brandt, Hartmut Cc: c

asio and kqueue (2nd trye) (was: RE: (boost::)asio and kqueue problem)

Hi all, here is the 2nd try taking into account the comments I received. Since I'm not familiar with the locking in the sockets area I ask somebody with that knowledge to check it before I commit it. Thanks, harti From: Scott Mitchell [mailto:scott.k.mit...@gmail.com] Sent: Friday, October

RE: (boost::)asio and kqueue problem

I have a fix that works and is better and simpler than the previous and will try to put it together in the next few days. harti From: Scott Mitchell [mailto:scott.k.mit...@gmail.com] Sent: Friday, October 14, 2016 2:16 AM To: freebsd-current@freebsd.org Cc: sepher...@gmail.com; kostik...@gmail.c

RE: files disappearing from ls on NFS

Now I've also changed NFS_DIRBLKSIZ to 4k - no change. harti -Original Message- From: Rick Macklem [mailto:rmack...@uoguelph.ca] Sent: Tuesday, May 14, 2013 2:50 PM To: Brandt, Hartmut Cc: curr...@freebsd.org Subject: Re: files disappearing from ls on NFS Hartmut Brandt wrote: > On Mon,

RE: files disappearing from ls on NFS

Hi Rick, sorry for top-posting - this is Outlook :-( Attached is the system configuration. I use this more or less unchanged since years. The machine is an 8-core AMD64 with 144GByte memory. The nfsstats -m output for the two file systems I'm testing with is: knopfs01:/OP_UserUnix on /home nfs

RE: files disappearing from ls on NFS

Hi Rick, the patch doesn't help. So how can I help to fix that? Of course, I can use the work-around with oldnfs, but ... harti -Original Message- From: Rick Macklem [mailto:rmack...@uoguelph.ca] Sent: Saturday, May 04, 2013 11:33 PM To: Brandt, Hartmut Cc: curr...@freebsd.org; Andrzej

RE: files disappearing from ls on NFS

Looks like the problem is in the new NFS code - the old code does the right thing. I've still to try your patch... harti From: Rick Macklem [rmack...@uoguelph.ca] Sent: Sunday, May 05, 2013 12:49 AM To: Brandt, Hartmut Cc: curr...@freebsd.org Subject: Re: