xmobar 0.45 fails to build with musl libc #656

New Issue

Open

opened 2022-11-12 07:23:03 +00:00 by slotThe · 1 comment

slotThe commented

2022-11-12 07:23:03 +00:00

This is more of a heads-up, in case people run into this: due to the new pango dependency, we also depend on the glib library for bindings. However, this fails to build on musl libc with an error along the lines of

glib    > Configuring glib-0.13.8.2...
glib    > build
glib    > Preprocessing library for glib-0.13.8.2..
glib    > setup: Error in C header file.
glib    > 
glib    > /usr/include/stdlib.h:44: (column 11) [FATAL] 
glib    >   >>> Syntax error!
glib    >   The symbol `void' does not fit here.
glib    >

The tl;dr is that musl uses valid C11 in its stdlib.h, but the parser that gtk2hs-buildtools uses is a custom version of c2hs, which is only C99 (plus a bit) compatible. I reckon the chances of someone ~~writing~~ integrating a competely new parser ~~for~~ into c2hs are close to zero, so this is likely an issue that'll stay with us for a while.

This is more of a heads-up, in case people run into this: due to the new pango dependency, we also depend on the [glib](https://hackage.haskell.org/package/glib) library for bindings. However, this [fails to build](https://github.com/gtk2hs/gtk2hs/issues/262) on musl libc with an error along the lines of ``` glib > Configuring glib-0.13.8.2... glib > build glib > Preprocessing library for glib-0.13.8.2.. glib > setup: Error in C header file. glib > glib > /usr/include/stdlib.h:44: (column 11) [FATAL] glib > >>> Syntax error! glib > The symbol `void' does not fit here. glib > ``` The tl;dr is that musl uses valid C11 in its `stdlib.h`, but the parser that [gtk2hs-buildtools](https://hackage.haskell.org/package/gtk2hs-buildtools) uses is a custom version of [c2hs](https://hackage.haskell.org/package/c2hs), which is only [C99 (plus a bit) compatible](https://github.com/haskell/c2hs/issues/159). I reckon the chances of someone ~~writing~~ integrating a competely new parser ~~for~~ into `c2hs` are close to zero, so this is likely an issue that'll stay with us for a while.

jao commented

2022-11-12 21:53:55 +00:00

Owner

@slotThe oh, that probably means that we should move to gi-cairo-render (https://github.com/haskell-gi/haskell-gi/tree/master/cairo/gi-cairo-render), which explicitly doesn't depend on gtk2hs-buildtools, and most probably its companion gi-pango. While migrating to cairo/pango i tried that combo at some point, but i couldn't make it work and eventually went for the gtk2hs-based libs just because they were working out of the box. But I am pretty sure the current code can be made to work with the gi libs.