On Fri, 2023-05-05 at 23:42 +0800, lux wrote: > On Fri, 2023-04-28 at 01:00 +0800, lux wrote: > > On Sat, 2023-04-15 at 21:02 +0200, Omar Polo wrote: > > > On 2023/04/14 21:30:26 +0800, lux <l...@shellcodes.org> wrote: > > > > On Wed, 2023-04-12 at 21:58 +0200, Omar Polo wrote: > > > > > I haven't tested it, but the build ends with a > > > > > > > > > > : zsyscall_openbsd_amd64.s:213 > > > > > : (syscall/zsyscall_openbsd_amd64.s:213)([...]/go-link- > > > > > 1246028766/go.o: > > > > > : (syscall.libc_syscall_trampoline.abi0)): warning: syscall() > > > > > may > > > > > go > > > > > : away, please rewrite code to use direct calls > > > > > > > > > > which hints that it may broke a runtime. > > > > > > > > > > > > > This warning comes from lib/libc/dlfcn/init.c: > > > > > > > > #if defined(APIWARN) > > > > __warn_references(syscall, > > > > "syscall() may go away, please rewrite code to use direct > > > > calls"); > > > > #endif > > > > > > > > I think we may need to wait for the Go language upstream code > > > > to > > > > make > > > > changes. > > > > > > Yep, it comes since some dependency of nuclei is calling > > > syscall() > > > directly. Don't know how to tell which it is. However, that > > > doesn't > > > imply that the port is broken, it's just a hint that it *might* > > > be > > > so. > > > I haven't tested, beside a very brief test, so can't say for > > > sure. > > > If > > > you've tested it throughfully then it's fine. > > > > > > (this error may even go away when upstream updates their deps.) > > > > > > > > > > Ping. > > > > Update to 2.9.2 > > Ping, and update to 2.9.3 > > Changelog: > https://github.com/projectdiscovery/nuclei/releases/tag/v2.9.3 > > ok?
Ping, I tested it with no problem, ok?
