LCDproc development and user support list

Text archives Help

[Lcdproc] Problems compiling LCDproc 0.5.6 with MUSL

Chronological Thread 
  • From: harald at (Harald Geyer)
  • Subject: [Lcdproc] Problems compiling LCDproc 0.5.6 with MUSL
  • Date: Fri, 20 Jan 2017 15:36:33 +0100

Philip Prindeville writes:

> I added:
> TARGET_CFLAGS += -Wall -Werror
> to my Makefile just to see what it would shake out.
> It may be highlighting some potential bugs. Or it might be noise.

Yes, lcdproc is mostly quite old and rusty code. Patches are welcome
of course.

> configfile.c: In function 'process_config': configfile.c:500:13:
> warning: variable 'k' set but not used [-Wunused-but-set-variable]
> ConfigKey *k; ^
> it does indeed get assigned on line 698 as:
> else { /* Store the value*/ k =
> add_key(*current_section, keyname,
> value); }
> but it’s then subsequently unreferenced.

I have been thinking that it probably would be best to drop our custom
configuration handling code and move to libelektra. Looks like we are
very lucky and a student might be doing the actual work even:

> Looking in I see:
> AC_CHECK_FUNCS(select socket strdup strerror strtol uname cfmakeraw
> snprintf)
> but when building against MUSL, I get inconsistent results:
> #define HAVE_CFMAKERAW 1 #define HAVE_SELECT 1 /* #undef HAVE_SNPRINTF
> */ #define HAVE_SOCKET 1 /* #undef HAVE_STRDUP */ #define HAVE_STRERROR
> 1 #define HAVE_STRTOL 1 #define HAVE_UNAME 1 $
> these should ALL be defined.

Hm, is this with 0.5.6 or 0.5.8?

> Regarding providing your own snprintf()… Please don’t. The stdio
> library is a notorious attack surface (the first major internet outage
> in 1989 exploited the finger daemon calling gets() and it hasn’t
> stopped since).
> If a platform doesn’t provide adequate run-time functionality I would
> suggest punting it.

According to the mailinglist archive this was added 15 years ago to
support an even then ancient Solaris Version ... however the people
engaging in the discussion back then are still active in the community
nowadays, so I will leave judgement to them.

It really shouldn't get included anywhere now, short of build system
bugs of course.

> > My current state is here:
> >
> I’ll see if I can diff out versions and find anything significant you
> could pick up from my version…

I won't mind if you merged this toghether and submitted it as maintainer.
Especially, if you want to support uci - I probably won't work on that.

> That’s if I can get it working on my hardware to test it!

What hardware and what's not working?


If you want to support my work:
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w

Archive powered by MHonArc 2.6.18.

Top of page