<div dir="auto">Thanks for the update. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 30, 2022, 17:55 Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com" target="_blank" rel="noreferrer">jimklimov+nut@gmail.com</a>> writes:<br>
<br>
>   Just went online to say that I'd like to release a NUT 2.8.0 (nee 2.7.5)<br>
> soon, or at least an RC1 of that, so another round of community testing<br>
> with current master (and reminders of what missed ideas better get in<br>
> before release) would be great. And saw your message, must be hailing from<br>
> the future :)<br>
<br>
Now that I'm set up doing test builds/reports is easier.<br>
<br>
>   I'll try to spin a NetBSD VM to try some builds too.<br>
<br>
That would be great.  I realize it has a lot fewer users than GNU/Linux<br>
but as I realize you know testing on a few disparate systems shakes out<br>
bugs that would manifest on a number of the next 20 not yet tested on.<br>
<br>
>   One thing that pops up in your make log is that it looks into system<br>
> includes before (some of) the source includes - and apparently sees an<br>
> older NUT there to confuse things, e.g.:<br>
<br>
Ah, I will look into this.  I didn't realize I had nut installed; I'm<br>
doing test builds on a machine that's not my production server/upsd<br>
machine.<br>
<br>
If that is what's wrong, then it's a nut build system bug.  It's very<br>
normal in the packaging world to have the old version install while<br>
building the new version.  But it should be fairly easy to fix by moving<br>
the includes of things in nut sources to before all the configure and<br>
found includes.<br>
<br>
> Maybe indirectly - e.g. if detection or use of certain libusb variant got<br>
> confused.<br>
<br>
Anything seems possible; I posted because I was at a point in<br>
understanding the code where it suddenly got a lot harder.<br>
<br>
>   For a bigger picture, NUT has a few large areas impacted by the libusb<br>
> API or modeled after it, including some HID and SHUT libs and drivers. The<br>
> two direct libusb APIs (0.1 and 1.0) differ notably in method arguments and<br>
> data types used (witdth and sign of ints involved), so to simplify NUT<br>
> codebase maintenance, those types were typedef'ed (and some similar methods<br>
> aliased) and the platform differences are concentrated in nut_libusb.h,<br>
> libhid.h and such, depending on configure-script choice of the library (and<br>
> ifdef's are used there).<br>
<br>
That makes sens.<br>
<br>
>   This approach was tested to work well with many generations of linux<br>
> x86/arm and illumos/solaris distros vs. UPS HW; builds at least pass<br>
> regularly on CI farms with freebsd, openbsd and macosx... So really curious<br>
> what needs tuning for netbsd - hopefully some nuance and nothing major :)<br>
<br>
Given what you are running on already, it really seems like it has to be<br>
minor.<br>
<br>
The mystery is that tools/nut-scanner/nutscan-usb.h seems to have code<br>
for libusb0 hardcoded.  It turns out that I had done a build without<br>
objdir back in October, and forgotten that.  Doing an objdir build<br>
apparently used that old file, even though it seems like it should have<br>
been rebuilt.<br>
<br>
With my git tree totally cleaned ("git status --ignored" shows only<br>
_build which is a symlink to my build script), the build completed ok.<br>
<br>
<br>
Thanks very much for the hints; between your help and a fresh look I<br>
have a build and I understand better a small thing that's wrong.  I'll<br>
start a new thread now that I can be coherent about the small thing.<br>
</blockquote></div>