Nut upsuser - Dec 2022 - Compiling on Solaris 8 sparc - configure errors

One thing that popped up in this quest was that Solaris 8 libc does not
take kindly to code similar to:

    printf("%s", NULL);

...which ends up dereferencing that NULL to check strlen() - and I suppose
can happen when debug messages are logged with little regard to arguments
(newer libc's are smarter about this).

Can you check if there are any core dump files lying around after your
experiments (especially those at higher verbosity), or dmesg lines about
such segfaults?

I posted https://github.com/networkupstools/nut/pull/1737 to track the
problem, but it may need some effort to pepper the code with this
`NUT_STRARG()` macro or find some smarter solution. Best done and tested on
a platform that fails otherwise due to this ;P

Jim


On Thu, Dec 22, 2022 at 4:17 PM Jim Klimov <jimklimov+nut at gmail.com>
wrote:
> Prospective fixes posted to
> https://github.com/networkupstools/nut/pull/1738 - hoping the
> multi-platform CI would survive these changes elsewhere. Probably a few
> follow-up fixes will land over time...
>
> You can try to check out and build this branch :
> https://github.com/jimklimov/nut/tree/sol8
>
> Default build with `./ci_build.sh` autoconfigured and passed... Ok, not
> *too* default - tweaks and general VM preparation referenced in
> https://github.com/networkupstools/nut/issues/1736
>
> Notably, self-checks which execute `upsd` and `dummy-ups`, and query them
> with `upsc` (all within localhost) did pass.
>
> Hope this helps,
> Jim Klimov
>
> On Thu, Dec 22, 2022 at 11:57 AM Jim Klimov <jimklimov+nut at
gmail.com>
> wrote:
>
>> Cheers, trying to recreate this issue over the holidays to the best
>> extent I currently can (with an x86 VM) - that went well (problems
>> reproduced).
>>
>> Tracking some detailed discussion in
>> https://github.com/networkupstools/nut/issues/1736
>>
>> Regarding the `--without-nut-scanner` (named so in the end) option -
>> seems it was added in the master branch after 2.8.0 release.
>>
>> Jim
>>
>>
>> On Sun, Dec 18, 2022 at 5:35 PM vom513 via Nut-upsuser <
>> nut-upsuser at alioth-lists.debian.net> wrote:
>>
>>> Hello,
>>>
>>> Trying to build from source on Solaris 8/sparc.  I grabbed the
2.8.0
>>> release tarball from github.
>>>
>>> All I really need is upsmon to talk to another nut instance on the
>>> network.  So I don?t need any kind of drivers built.
>>>
>>> Here is the error I?m getting:
>>>
>>> checking which drivers to build... ./configure: line 13084: syntax
error
>>> near unexpected token `('
>>> ./configure: line 13084: `                      get_drvlist() (?
>>>
>>> Here was my command line (no idea if this is the right syntax to
get it
>>> to NOT build any drivers):
>>>
>>> ./configure --without-usb --without-serial --without-snmp
--without-neon
>>> --without-powerman --without-modbus --without-ipmi
--without-linux_i2c
>>> --without-macosx_ups
>>>
>>> Thanks in advance for any clue.
>>>
>>>
>>>
>>> _______________________________________________
>>> Nut-upsuser mailing list
>>> Nut-upsuser at alioth-lists.debian.net
>>>
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20221222/095c01be/attachment.htm>

> On Dec 22, 2022, at 10:23 AM, Jim Klimov <jimklimov+nut at gmail.com>
wrote:
> 
> One thing that popped up in this quest was that Solaris 8 libc does not
take kindly to code similar to:
> 
>     printf("%s", NULL);
> 
> ...which ends up dereferencing that NULL to check strlen() - and I suppose
can happen when debug messages are logged with little regard to arguments (newer
libc's are smarter about this).
> 
> Can you check if there are any core dump files lying around after your
experiments (especially those at higher verbosity), or dmesg lines about such
segfaults?
I actually do have a core file from upsmon.  Let me know if there?s somewhere I
can attach it or upload it.  I?ve never really dealt with analyzing core files
(is that a gdb thing ?).

# file core
core:           ELF 32-bit MSB core file SPARC Version 1, from 'upsmon'

One other thing I should come clean on.  When compiling 2.8.x - it always dies
with an error in common.c about left == operand (UINTPTR_MAX) has no value. 
This seems to be a 32/64 bit check.  I know I?m 32 bit, so I?ve been commenting
out the below block as shown.  Hopefully this isn't biting me in some other
place (it seemed to compile fine after this - and my binaries came out of the
oven as 32-bit sparc.)

/* Know which bitness we were built for,
 * to adjust the search paths for get_libname() */
#include "nut_stdint.h"
/*#if UINTPTR_MAX == 0xffffffffffffffffULL
# define BUILD_64   1
#else
# ifdef BUILD_64
#  undef BUILD_64
# endif
#endif */