Re: cmake hang solution?

[Chuck Silvers <chuq%chuq.com@localhost>]

On Mon, May 02, 2022 at 08:16:42PM +0200, Manuel Bouyer wrote:
> On Mon, May 02, 2022 at 11:13:45AM -0700, Chuck Silvers wrote:
> > it looks like the diff won't apply as-is, but I think the concept still applies.
> > 
> > note that there have been a LOT of changes in libpthread since netbsd-9,
> > and some of those changes also claim to fix problems where threads hang
> > waiting on locks and/or condvars.  it would be more useful to test
> > with a HEAD libpthread (which I'll guess requires a HEAD libc too).
> 
> the goal is to build the official netbsd-9 packages, so that's not an option

it's possible to have individual binaries use shared libraries from a
non-standard location, such that you could have cmake itself use the
HEAD shared libraries to run, but that everything that the build process
builds would use link against the netbsd-9 shared libraries in the
normal location.  I've done this kind of thing before by just editing
an executable binary to change the RPATH in the ELF headers
(or if the target executable has no RPATH then editing the binary
to use an alterate ld.elf_so, and having the alternate ld.elf_so use
an alternate default RPATH.)  if you don't like that then you could also
change the cmake build to link the cmake executable with an alternate rpath.

I'm only suggesting all of this as a way to test if all of these hang bugs
are fixed in HEAD, not that you should run your netbsd-9 userland system
with this hacky setup indefinitely.

-Chuck