12:01:38 <jimklimov> Cheers, while updating NUT CI build agents, I've stumbled upon an old problem I swept under the rug a few years back and forgot about, logged now as https://github.com/networkupstools/nut/issues/2674
12:03:38 <jimklimov> In short, building against Mozilla NSS which in Solaris "since forever" has its libraries in a non-default location /usr/lib/($ARCH/)mps proved problematic, because the autotools/libtool recipes somehow lose the `-R/path/name` arguments and the resulting binary does not know where to find the shared objects at run-time (without gaming the LD_LIBRARY_PATH)
12:04:38 <jimklimov> I suppose this can be a common know-how problem with building autotools-based software for Solaris/illumos over the past 2-3 decades, so there gotta be ready solutions/workarounds to share? :D
12:08:07 <jimklimov> Also, in OpenIndiana builds, there is libgd for both 32-bit and 64-bit platforms, but the 32-bit one lacks further dependency binaries (libfontconfig, libfreetype) so builds pass and links/runs fail. I think I posted that bug some years back, but it still bites.
16:46:20 <jbk> it's a hack, but you can use elfedit to alter the rpath afterwards
16:47:18 <jimklimov> So far I've hand-picked a way to detect that the pkg-config served LIBS include `-R/some/path` tokens, stash them, and add into progname_LDFLAGS in a Makefile.am
16:47:45 <jimklimov> My take is that this situation overall is a libtool bug, though
16:49:11 <jimklimov> the NSS deps are for a shared library built as part of the project, not directly for the binary - but libtool adds them as shared objects required by both the library and the binary using it (but without -R for the latter, which I re-add explicitly now)
16:52:50 <jbk> that or autotools...
16:53:22 <jbk> i know the tpm2 tools have similar issues.. and i don't have the stomach to try to dig into the layers and layers of m4
16:53:39 <jbk> even I have my limits :)
16:54:50 <jbk> (the annoying part is the tpm2 stuff is already pretty damn portable... using autotools/libtools is largely overkill for the sake of 'doing what everyone else does'
16:55:50 <jbk> like there are no 1980s era systems from MCR with broken vprintf implementations that you have to worry about...
16:55:50 <jimklimov> well, NUT is also pretty portable - but autotools is a large part of helping that happen in practice, I suppose :)
16:56:52 <jbk> err NCR (not even sure, but just the habit of autotools to try to detect/deal with things that stopped being a serious concern before a lot of people were born)
16:57:02 <jimklimov> and we do hit things like `char * s = NULL; printf("%s", s);` exploding on some systems with SEGFAULT and calmly printing "(null)" or somesuch on others
16:57:43 <jimklimov> New California Republic? They (still/will) make computers also? ;D
16:58:29 <jbk> i was thinking more the place that built cash registers... i think they had a unix back in the 80s (like everyone) but had loooooong since gone by the wayside
16:58:56 <jimklimov> and there are also different libc's - musl, uClibc, etc. that come with caveats of their own
16:59:18 <jbk> yes.. one of the biggest mistakes linux did (imo) is just do a kernel
16:59:47 <jimklimov> well, in embedded world busybox-like shrunk libc does make sense
17:00:12 <jbk> you could build #ifdef a smaller libc though if you really needed to
17:00:37 <jimklimov> take something as huge as a router with say 64-256Mb RAM, and modern big distros would sneer at it
17:00:38 <jimklimov> or something as small as some Pi Zero
17:01:00 <jbk> i mean the tradeoff is that you have a bloated syscall layer because you have to support every failed experiment in the past 20 years
17:01:11 <jbk> (look at futex sometime)
17:01:56 <jbk> (like half the subcommands are of questionable utility, and aren't even used anymore, but are still there just in case)
17:06:29 <jbk> if it's in userland, easier to remove the code (or unless you're statically linking the world, just leave it and not have it take up ram because it's never getting loaded)
17:07:46 <jimklimov> well, storage size on routers is also a problem :)
17:38:52 <tsoome> if you can have tens of GB's on something of a size of your fingertip, then storage size can not be problem:P
17:40:14 <tsoome> but you may want to keep it small for other reasons anyhow. And keeping things small means quite specific design 
18:03:43 <sommerfeld> jimklimov: In this context, "NCR" was originally "National Cash Register".  made mechanical cash registers starting in the late 1800's, started making computers, were bought by AT&T in the early 90's, spun back out in late 90's.  
22:21:31 <jimklimov> Yeah, figured so. Just that the NCR from Fallout is more in my foremind... since last millennium, it seems.