Created attachment 763601 [details] build.log net-proxy/prioxy-3.0.33 failed to build on riscv hardware.
Created attachment 763613 [details] config.log
Created attachment 763614 [details] conftest.c
I can reproduce this while build conftest.c with passing -fsanitize=undefined if USE=sanitize enabled
configure:6314: riscv64-unknown-linux-gnu-gcc -o conftest -pipe -O2 -pipe -mabi=lp64d -DNDEBUG -fsanitize=undefined -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1 -Wl,-O1 -Wl,--as-needed -fsanitize=undefined conftest.c 1>&5 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.1/../../../../riscv64-unknown-linux-gnu/bin/ld: cannot find -lubsan collect2: error: ld returned 1 exit status --- Please verify USE=sanitize is enabled on GCC. I'm also not even sure if riscv has a sanitizers port yet...
(In reply to Sam James from comment #4) > Please verify USE=sanitize is enabled on GCC. > > I'm also not even sure if riscv has a sanitizers port yet... ya, I realized this, previously, USE=sanitize is not enabled on GCC.. will investigate this.. btw, on a sidetrack, should privoxy explicitly depend on this? USE: sanitize ? sys-devel/gcc[sanitize]
(In reply to Yixun Lan from comment #5) > (In reply to Sam James from comment #4) > > Please verify USE=sanitize is enabled on GCC. > > > > I'm also not even sure if riscv has a sanitizers port yet... > > ya, I realized this, previously, USE=sanitize is not enabled on GCC.. will > investigate this.. > My bet is they're not there yet but I'm not sure. > btw, on a sidetrack, should privoxy explicitly depend on this? > USE: sanitize ? sys-devel/gcc[sanitize] Nah, there's Clang sanitizers too. I don't think USE=sanitize should even be here. It's a *FLAGS option and it's not really intended for production use anyway. It should be masked if kept, as I accept it could be useful for development, but it's not something people should just toggle.
(In reply to Sam James from comment #6) > My bet is they're not there yet but I'm not sure. > I've enabled gcc[sanitize], and it actually solve this problem, so I will go ahead and unmask gcc[sanitize] > > btw, on a sidetrack, should privoxy explicitly depend on this? > > USE: sanitize ? sys-devel/gcc[sanitize] > > Nah, there's Clang sanitizers too. > it's true > I don't think USE=sanitize should even be here. It's a *FLAGS option and > it's not really intended for production use anyway. > > It should be masked if kept, as I accept it could be useful for development, > but it's not something people should just toggle. I will leave maintainer to handle this, also USE=fuzz is kind of similar (only useful for development)
