Issues building chafa on CentOS 7

[ivanshatsky]

The first issue, for some reason chafa does not see libwebp installed on my system. I have the following packages installed:

/root/chafa# yum list installed|grep libwebp
libwebp.x86_64                   0.3.0-10.el7_9               @updates
libwebp-devel.x86_64             0.3.0-10.el7_9               @updates
libwebp7.x86_64                  1.0.3-1.el7.remi             @remi-safe

Seems ok to me, however this is CentOS, maybe libwebp version is too obsolete and not supported?

The second issue, building the chafa, I get the following error:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -Wall -Wextra -Wmissing-prototypes -Wwrite-strings -Wunused-macros -Wundef -Wpointer-arith -Werror=format-security -Wstack-usage=131072 -Wlogical-op -ffast-math -I.. -g -O2 -MT libnsgif_la-lzw.lo -MD -MP -MF .deps/libnsgif_la-lzw.Tpo -c lzw.c  -fPIC -DPIC -o .libs/libnsgif_la-lzw.o
lzw.c: In function 'lzw_decode_init':
lzw.c:290:2: error: 'for' loop initial declarations are only allowed in C99 mode
  for (uint32_t i = 0; i < ctx->clear_code; ++i) {
  ^
lzw.c:290:2: note: use option -std=c99 or -std=gnu99 to compile your code

Changing CFLAGS = -g -O2 line in the chafa/libnsgif/Makefile to CFLAGS = -g -O2 -std=c99 fixes it and allows chafa to build successfuly.

GCC version in the build toolchain is gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)

I also get a couple of warnings about m4 macros after running autogen.sh (I don't know is it related or not):

Running libtoolize...
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: You should add the contents of the following files to `aclocal.m4':
libtoolize:   `/usr/share/aclocal/libtool.m4'
libtoolize:   `/usr/share/aclocal/ltoptions.m4'
libtoolize:   `/usr/share/aclocal/ltversion.m4'
libtoolize:   `/usr/share/aclocal/ltsugar.m4'
libtoolize:   `/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
Missing optional tool: gtk-doc

Without this, no developer documentation will be generated.

Running aclocal...
aclocal: warning: couldn't open directory 'm4': No such file or directory
Running automake...
...

However, the only really important question to me from all of this "is there any way to build chafa with the WebP support?"

[hpjansson]

Hi, thanks for filing the report. Your package versions are a bit old, but WebP should still be supported on your system.

Could you please attach:

• The config.log that appears after running autogen.
• The output from rpm -ql libwebp-devel.

For the -std= option, we're using AC_PROG_CC which should set it to the newest available standard automatically. It's possible that your autoconf is a bit too old for that, though. I'd be curious to know which version you have.

[hpjansson]

You could test if it's an older autoconf causing the C standard problem by adding AC_PROG_CC_STDC below AC_PROG_CC in configure.ac.

[ivanshatsky]

Thank you for the really fast response!
CentOS 7 autoconf version is 2.69-11.el7
Indeed, adding AC_PROG_CC_STDC below AC_PROG_CC fixed build process.
Here is the information you requested.

# rpm -ql libwebp-devel
/usr/include/webp
/usr/include/webp/decode.h
/usr/include/webp/encode.h
/usr/include/webp/mux.h
/usr/include/webp/mux_types.h
/usr/include/webp/types.h
/usr/lib64/libwebp.so
/usr/lib64/libwebpmux.so
/usr/lib64/pkgconfig/libwebp.pc
/usr/lib64/pkgconfig/libwebpmux.pc

config.log

[hpjansson]

Looks like your webp-devel package is too old. We're looking for libwebpdemux.pc, which was separated out from libwebp.pc.

It might work if you edit configure.ac again and replace libwebpdemux with libwebp. If that solves it, we can fix the issue by using it as a fallback.

[ivanshatsky]

Unfortunately, looks like webp-devel is too old and completely incompatible.

webp-loader.c:31:24: fatal error: webp/demux.h: No such file or directory

And there are no any WebPAnimDecoder related stuff in existing files from 0.30, so we can give up here.

I think there is no easy way to statically compile chafa with a more recent external libwebp?

[hpjansson]

Hmm, right. I added the animation support in d263968, so it may be possible to revert that locally. I'd take a pull request to add fallback support for older libwebp versions, but I'm not sure it'd be worth the effort.

If you just need to run Chafa on x86_64 with (statically linked) WebP support, I do have static builds you could use. See https://hpjansson.org/chafa/download/ under "Stand-alone executable".

[ivanshatsky]

Right now a static build could be ok for my needs. Unfortunately your static build lacks SVG format support, which I also needed (BTW, don't you have a plans to add SVG support to your static builds?) I tried to build an immediately previous fe944a2. My first try was unsuccesful, I get the following error:

chafa-webp-loader.o: In function `webp_loader_destroy':
/root/chafa/chafa/tools/chafa/webp-loader.c:124: undefined reference to `WebPFree'

Digging further I found this:

WebPFree() was added in v0.5.0, older versions should use free().

After changing WebPFree to free this version build successfully, so now I finally have an universal binary I was needed, working with SVG and WebP. I don't think adding fallback would be worth the effort too. However adding SVG support to your static builds would be nice. Funny thing, animation support was also added in 0.5.0, so I think you can just mention this version as a minimal requirement for the WebP support.

---

P.S. Your library is really amazing by the picture quality it produces. I use it for picture preview in conjunction with far2l file manager (which have a TTY mode and can be used over SSH). A few days ago truecolor font support was finally merged into its master branch. Here is a screenshot from PuTTy remote SSH session, picture previews looks great!

[hpjansson]

Sweet, glad it's useful!

I'd like to have SVG support in the static builds, but the major libraries I've looked at (librsvg and resvg) are written in Rust. Now Rust is great, I like it, but it complicates things:

Currently I build and link against an old glibc so the final binaries can be used on older systems, and that would have to change. I'd also have to set up a Rust toolchain in the build env, and the final binaries would be something like 5x as big, so 80% SVG renderer, 20% everything else.

One possible solution would be to use an old C-only version of librsvg, but then I'd have to add extra code to support the old API, and it would probably have unresolved security issues.

For the Windows builds I use the MXE stack, which has the last C-only librsvg version (misremembered this initially as not having an SVG library, sorry), probably for similar reasons.

[ivanshatsky]

Finalizing this, I think solution to use latest C version of librsvg (2.40.21) for the static chafa build might be a reasonable compromise. Just checked its security state, besides its authors are strongly encourages users to move to the Rust library version, 2.40 branch still receiving updates against CVEs being found in librsvg. Of course, I understand it will require an additional code, so the final decision is up to you only.

Once again, thank you for your responses and your work! I saw you are already added workarounds for the CentOS 7 autoconf version, so I think we can close this for now. Just FYI, CentOS 7 EOL date is 2024-06-30 and its glibc version is exactly 2.17, so changing your static build glibc dependency to something newer before that date will break its compatibility for all CentOS 7 users.

[hpjansson]

Great. I'll look into building with librsvg 2.40.x. Feel free to report any other issues you come across 👍