troglobit/libite

That missing frog DNA you've been looking for

-lite | Frog DNA, basically

Table of Contents

• Introduction
• Using -lite
• API
  • Important Node
  • Helper Macros
  • Generic Functions
  • GNU Functions
  • OpenBSD/NetBSD/FreeBSD Functions
• Build & Install
• Origin & References

NOTE: Incompatible changes in v2.0 compared to v1.x!

Introduction

Libite is a lightweight library of frog DNA that can be used to fill the gaps in any dinosaur project. It holds useful functions and macros developed by both Finit and the OpenBSD project. Most notably the string functions: strlcpy(3), strlcat(3) and the highly useful *BSD sys/queue.h and sys/tree.h API's.

Libite holds many of the missing pieces in GNU libc, although -lite does not aim to become another GLIB. One noticeable gap in GLIBC is the _SAFE macros available in the BSD sys/queue.h API — highly recommended when traversing lists to delete/free nodes.

The code is open sourced under a mix of permissive Open Source licenses: MIT/X11 license, ISC license, and BSD licenses.

Tip: have a look at my blog post about other useful UNIX API's! https://troglobit.com/post/2020-02-22-useful-unix-apis/

Using -lite

Libite is by default installed as a library and a set of include files. To prevent clashing with include files of the same name -lite employs an include file namespace libite/, which is strongly recommended to use in your applications:

#include <libite/lite.h>
#include <libite/conio.h>
#include <libite/queue.h>
#include <libite/tree.h>

Note: prior to v2.5.0, the lite/ namespace was used for headers, which is still available in the default install. This clashed with the headers of the LiTE library from the DirectFB project.

The output from the pkg-config tool holds no surprises:

$ pkg-config --libs --static --cflags libite
-I/usr/local/include -D_LIBITE_LITE -L/usr/local/lib -lite

Note: _LIBITE_LITE is defined since v2.5.0, useful for software that want to be able to build against headers from an older libite:

#ifdef _LIBITE_LITE
# include <libite/lite.h>
#else
# include <lite/lite.h>
#endif

The prefix path /usr/local/ shown here is only the default. Use the configure script to select a different prefix when installing libite.

For GNU autotools based projects, use the following in configure.ac:

# Check for required libraries
PKG_CHECK_MODULES([lite], [libite >= 1.5.0])

and in your Makefile.am:

proggy_CFLAGS = $(lite_CFLAGS)
proggy_LDADD  = $(lite_LIBS)

API Documentaion: https://codedocs.xyz/troglobit/libite/

Build & Install

This library was initially built for and developed on GNU/Linux systems as a light weight utility library, these days NetBSD should also work.

$ ./configure
$ make -j5
$ sudo make install-strip
$ sudo ldconfig

Use ./configure --without-symlink to prevent the install step from creating the lite -> libite/ compatibility symlink for the header files, required for systems with DirectFB LiTE. The default, however, is to install the symlink to ensure compatibility with existing software that depends on the -lite library headers in their previous namespace.

Note: When checking out code from GIT, use ./autogen.sh to generate a configure script. It is a generated file and otherwise only included in released tarballs.

Origin & References

Much of the code in libite (-lite) is written by Claudio Matsuoka for the original Finit and released under the MIT/X11 license. Joachim Wiberg later improved on the Finit code base and included pieces of software released under the ISC and BSD licenses. See each respective file for license details.

libite's Issues

Removing the usage of __progname for compat with uclibc

I would like to remove the usage of __progname in pidfile.c in order to be able to use libite (and thus finit) on uclibc based devices. Work to remove __progname was already done in finit but since it's still used in libite, uclibc is unable to link finit.

If you would be supportive of that work, I have three suggestions for how we could do it:

1. Mimic the finit approach, where the user must set a global variable which holds progname (probably taken from argv[0])

2. Use readlink and basename on /proc/self/exe to extract the program name.

3. Change the pidfile API to require the parameter basename not be NULL

My vote would be option 2, and both option 1 and 3 could be seen as a breaking change.

strlite.h cannot be included on its own, warns about INT32_MAX and MIN()

makepath functions signature

Hi,

First, thanks for the very quick fix on the previous comment!

Back to code :-)

Wouldn'it be better to have const char *dir input parameter for these two functions?

libite/makepath.c

Line 32 in be6f276

int mkpath(char *dir, mode_t mode)

libite/makepath.c

Line 59 in be6f276

int makepath(char *dir)

When passing std:string::c_str() for example, it would work without any cast.

Minor remark, this include is useless:

libite/makepath.c

Line 22 in be6f276

#include "lite.h"

Regards,

lite/lite.h name clash with DirectFB project LiTE

When building watchdogd in Buildroot it was unveiled that -lite's include path (name space) clashes with that of the DirectFB LiTE project, which also use lite/lite.h.

http://autobuild.buildroot.net/results/185c753af2aa159b494b13f78b0826dddbe4aed6/build-end.log

This is far from ideal and it was decided on the Buildroot IRC that we should try and change the include path in libite. However, such a change affects not only Open Source projects such as Finit, watchdogd, and utftpd. It also affects companies and users this projects does not know about. So the change must be rolled out smooth without breaking embedded build farms left and right.

1. Move includes to $DESTDIR/$includedir/libite/*.h
2. Add a pkg-config CFLAG so projects that use -lite can set up conditional #include statements, e.g. -D_LIBITE_LITE
3. Add optional symlink $DESTDIR/$includedir/lite -> libite

debian: add lite -> libite include symlink with dh_link

Even though the lite -> libite symlink in /usr/include is there in the .deb package, Debian seems to filter it out on install. Possibly only allowing for explicitly declared symlinks, using dh_link.

This fix should go in v2.5.1

Tests broken on debian

FAIL: fexist
============

fexist: Failed fexist(/sbin/init): No such file or directory
File /etc/passwd does exist     => OK!
File /etc/kalle  does not exist => OK!
FAIL fexist (exit status: 1)

FAIL: which
===========

                  ls : hot dog --> /bin/ls
                free : Not hot dog
             modinfo : Not hot dog
             useradd : hot dog --> /usr/sbin/useradd
      /usr/bin/which : hot dog --> /usr/bin/which
         /bin/ps aux : Not hot dog
         /etc/passwd : Not hot dog
FAIL which (exit status: 3)

So it's really bad to bindly assume some files exist (for example /sbin/init, which is replaced by systemd in Debian). Better to use stat() or something to check their existence.

Bug#811572: FTBFS with GCC 6: statement indented as if it were guarded by

Hi,

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811572 was reported with the following content:

This package fails to build with GCC 6. GCC 6 has not been released
yet, but it's expected that GCC 6 will become the default compiler for
stretch.

Note that only the first error is reported; there might be more. You
can find a snapshot of GCC 6 in experimental. To build with GCC 6,
you can set CC=gcc-6 CXX=g++-6 explicitly.

> sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux
...
> make[1]: Entering directory '/<<PKGBUILDDIR>>'
>   CC      igmp.o
> In file included from defs.h:90:0,
>                  from igmp.c:43:
> libite/lite.h: In function 'fisslashdir':
> libite/lite.h:102:26: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
>                           return 0;
>                           ^~~~~~
>
> libite/lite.h:101:4: note: ...this 'if' clause, but it is not
>     if (strlen (dir) > 0) return dir[strlen (dir) - 1] == '/';
>     ^~
>
> cc1: all warnings being treated as errors
> Makefile:51: recipe for target 'igmp.o' failed
> make[1]: *** [igmp.o] Error 1

David Malcolm was so nice, that he followed up with

(I'm the upstream gcc author of -Wmisleading-indentation)

Looking at,
https://github.com/troglobit/libite/blob/master/lite.h#L134
the code in question seems to be:

static inline int fisslashdir(char *dir)
{
   if (!dir)             return 0;
   if (strlen (dir) > 0) return dir[strlen (dir) - 1] == '/';
                         return 0;
}

Tests broken on gentoo

at first I thought this has to do with the gcc version, but I now see it also fails with my gcc version.
But the failure is because of which?

========================================
   libite 2.0.0: tests/test-suite.log
========================================

# TOTAL: 14
# PASS:  13
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: which
===========

                  ls : hot dog --> /bin/ls
                free : hot dog --> /usr/bin/free
             modinfo : hot dog --> /sbin/modinfo
             useradd : hot dog --> /usr/sbin/useradd
          /bin/which : Not hot dog
         /bin/ps aux : hot dog --> /bin/ps
         /etc/passwd : Not hot dog
FAIL which (exit status: 1)

request: hpp or similar for interlinking with C++

In the tedious work of rewriting ndppd for C I reused some of libite/inadyn code for pidfile and log(it)-functionality. So it would be nice with C++ bindings for interlinking (and saving lots of space).

Just my few 'öre'.

autoreconf: no config.status: cannot re-make

@troglobit , you deserve a 🍺

Ran into the following issue when compiling pimd. It does not bother me. However, if it says it is missing we ought to fix it 😄

Cloning into 'pimd'...
  FIXDEP  libite/lite.h missing ... OK

My first run produces the following error:

Cloning into 'libite'...
./autogen.sh: line 3: autoreconf: command not found

Resolved by installing dependencies:

yum -y install automake autoconf

Another run ended up with error: Libtool library used but 'LIBTOOL' is undefined:

Cloning into 'libite'...
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force --warnings=portability -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force --warnings=portability
autoreconf: running: /usr/bin/autoheader --force --warnings=portability
autoreconf: running: automake --add-missing --force-missing --warnings=portability
configure.ac:11: installing './ar-lib'
configure.ac:2: installing './install-sh'
configure.ac:2: installing './missing'
Makefile.am:3: error: Libtool library used but 'LIBTOOL' is undefined
Makefile.am:3:   The usual way to define 'LIBTOOL' is to add 'LT_INIT'
Makefile.am:3:   to 'configure.ac' and run 'aclocal' and 'autoconf' again.
Makefile.am:3:   If 'LT_INIT' is in 'configure.ac', make sure
Makefile.am:3:   its definition is in aclocal's search path.
Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
autoreconf: automake failed with exit status: 1

Resolved the above with:

yum -y install libtool

Now, it failes with:

autoreconf: running: /usr/bin/autoconf --force --warnings=portability
autoreconf: running: /usr/bin/autoheader --force --warnings=portability
autoreconf: running: automake --add-missing --force-missing --warnings=portability
configure.ac:11: installing './ar-lib'
configure.ac:12: installing './config.guess'
configure.ac:12: installing './config.sub'
configure.ac:2: installing './install-sh'
configure.ac:2: installing './missing'
Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
autoreconf: no config.status: cannot re-make
autoreconf: Leaving directory `.'
make: *** No targets specified and no makefile found.  Stop.

touch() does not update mtime on an existing file

Documentation on the touch() helper function says:

Create a file, or update mtime. Errors on stderr

... but the touch() function in its current implementation will not update mtime if the file already exists.

mkpath return value inconsistency

Hi,

The comment explains that -1 is returned on error.
But in this specific case, positive 1 is returned.

libite/makepath.c

Line 38 in 6daebf4

return 1;

IMO, comment is correct or at least aligned with mkdir documentation.
So, the returned value should be -1 on error.

Regards,

testing for /usr/sbin/useradd works only for root

While this can be okay, when running the test as root, this will fail if running as normal user (if path is not set to contain /usr/sbin/.
Should this be patched?

Relative paths do not work with touch()