-
-
Notifications
You must be signed in to change notification settings - Fork 342
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collectd with Musl build failure since NUT version 2.8.0 #1638
Comments
Thanks, this does not sound right indeed. A few weeks back I had some PRs to revise public headers (#1616, #1615) - does the problem still happen with current master-branch NUT? What header(s) declare |
So, it seems that currently it would still at best include (Hm, guess our CI needs some test cases to build stuff against public headers and libs without knowledge of NUT build workspace) |
As for the build log, I suppose most of the error noise about
further due to this:
Not sure why
In fact, for that build log I do not see mention of However some other changes to less loose data types, like |
Also FWIW there are some caveats noted in https://musl.libc.org/time64.html and the file is apparently here http://git.musl-libc.org/cgit/musl/tree/include/time.h |
FWIW, recording a quick reproducer:
|
… by NUT headers since v2.8.0 release Inspired by discussion at networkupstools/nut#1638
Note: also posted a PR to collectd to fix the int-type discrepancies (actually to detect which types suit the NUT API the consumer is building against, and transparently use those in the consumer codebase). |
…d against Either use the stricter int types required by NUT headers since v2.8.0 release, or the relaxed (arch-dependent) types required by older NUT releases - depending on which NUT API version the collectd is building against at the moment. Inspired by discussion at networkupstools/nut#1638
…d against Either use the stricter int types required by NUT headers since v2.8.0 release, or the relaxed (arch-dependent) types required by older NUT releases - depending on which NUT API version the collectd is building against at the moment. Inspired by discussion at networkupstools/nut#1638
…d against Either use the stricter int types required by NUT headers since v2.8.0 release, or the relaxed (arch-dependent) types required by older NUT releases - depending on which NUT API version the collectd is building against at the moment. Inspired by discussion at networkupstools/nut#1638
@ffontaine : hopefully fixed on my side; if you can stage a build with NUT and collectd codebases as of PRs above, to see how it goes (if the issues are resolved by these modifications), that would be great. UPDATE: The NUT change is in master branch now. Your collectd sources may need patch from that collectd/collectd#4043 PR. |
@ffontaine : side note - at the https://collectd.org/wiki/index.php/Plugin:NUT plugin page, maybe makes sense to point "libupsclient" to https://networkupstools.org/docs/man/upsclient.html and not just site root? |
…d against Either use the stricter int types required by NUT headers since v2.8.0 release, or the relaxed (arch-dependent) types required by older NUT releases - depending on which NUT API version the collectd is building against at the moment. Inspired by discussion at networkupstools/nut#1638
@ffontaine : FYI : both current NUT and collectd "master" branch codebases should already include respective proposed fixes. Please check that they play well together for your packaging effort, and feel free to close this issue if resolved. And thanks for bringing this up :) |
I'll wait for the next NUT release to test this as I'm unable to properly run autoreconf on buildroot side. |
That might take a while, hope to make sense of CPS regression at least, before that. You can |
…d against Either use the stricter int types required by NUT headers since v2.8.0 release, or the relaxed (arch-dependent) types required by older NUT releases - depending on which NUT API version the collectd is building against at the moment. Inspired by discussion at networkupstools/nut#1638
Hopefully this can get properly tested after NUT 2.8.1 gets released and propagated to the environment in question. |
…d against Either use the stricter int types required by NUT headers since v2.8.0 release, or the relaxed (arch-dependent) types required by older NUT releases - depending on which NUT API version the collectd is building against at the moment. Inspired by discussion at networkupstools/nut#1638
…d against Either use the stricter int types required by NUT headers since v2.8.0 release, or the relaxed (arch-dependent) types required by older NUT releases - depending on which NUT API version the collectd is building against at the moment. Inspired by discussion at networkupstools/nut#1638
@octo, @ffontaine : NUT v2.8.1 and recently v2.8.2 were released with recipe fixes mentioned above. Did you have a chance to test any of those? |
Yes, everything is building fine on buildroot since https://git.buildroot.net/buildroot/commit/?id=02c8901791d8d65094ecf56d9773babe74dd1845 where we applied commit cafd779. I'll close this issue. |
collectd fails to link with nut on musl since version 2.8.0 and 4f760ba on:
I don't know what is the proper way to fix this failure,
timehead.h
can't be included as this is an internal header that depends onconfig.h
.Full build log: http://autobuild.buildroot.org/results/22b758097e8fb72c68e41329cbc7abc748d81ca6/build-end.log
The text was updated successfully, but these errors were encountered: