nut-scanner: additional multiarch libraries search path; general: fixes to (debug) logging#2082
Merged
jimklimov merged 16 commits intonetworkupstools:masterfrom Oct 1, 2023
Merged
Conversation
…ols#317] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
jimklimov
added
bug
enhancement
Windows
nut-scanner
portability
Also bumps public API version of libnutscan due to added symbol. Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…ts [networkupstools#317] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…ual search order of get_libname() with more locations possibly checked [networkupstools#317] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…RGET_ALIAS as/if suggested by compiler [networkupstools#317] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…thset string
It was unexpected to see just one entry in getenv("PATH") after the first loop...
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…rectory counter Be sure to bump the number, not the pointer! Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…later calls do not corrupt what we want to report; fix declarations-on-top for windows builds Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…e for longer printouts, e.g. PATH in upsdebugx_report_search_paths() [networkupstools#317] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…essage Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
jimklimov
force-pushed
the
issue-317
branch
from
5ba5f36 to
8c04c7f
Compare
Member
Author
Notably, there is further area of improvement to de-duplicate |
This comment was marked as resolved.
This comment was marked as resolved.
Member
Author
|
On native Ubuntu LTS both the Sample NUT config report for where it works: |
…o retry from one mode to another) Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…ore getaddrinfo() et al Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Member
Author
|
On Windows (semi-native build with MSYS2): |
This comment was marked as resolved.
This comment was marked as resolved.
Member
Author
|
With pre-filter (on Linux) over "hard-coded" paths: |
…er the usable set [networkupstools#317] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
jimklimov
force-pushed
the
issue-317
branch
from
0d80c76 to
54cc416
Compare
…ilable, and so xstrdup()/free() in general [networkupstools#317] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes: #317
On one hand, this PR does what issue #317 asked for, to consider "multiarch" path components (if suggested by compiler) when we consider dynamic library loading at run-time (
nut-scanner, eventually DMF, etc.) Resulting paths are constructed per https://wiki.debian.org/Multiarch/LibraryPathOverview (prefixing(/usr)/lib(bits)essentially).On another, it uncovered and addressed some earlier issues (bugs and annoyances):
get_libname_in_pathset()method (added after 2.8.0 release, largely as part of NUT for Windows effort) had some issues both with accounting the number of directories checked, and with looking at them in the reentrant fashion (strtok()involved in parsing mangled the original string, such asgetenv("PATH")original, adding0x00chars where it found separators).upsdebugx()=>vupslog()methods limited the printable reports toLARGEBUF(1024bytes currently) as compiled into the program. This truncated reports ofPATH(quite long on Windows) for example, and was not hard to replace by a dynamically growing buffer to fit the conversions. Default behavior should be same as before, and it should fit the majority of practical cases, but there should be fewer truncations now. Note that receivers like syslog may do their own truncations of very long lines.Something not addressed here was a lingering idea to check if the initially successfully prepared
bufstring length is comparable withbufsize(minus... how much?) and if it is - also extend, so that our later suffixes (errno details, etc.) would fit.