We're trying to package KDE Plasma 5 for our new distribution Adélie Linux, based on the musl libc. The musl libc provides libintl (similar to glibc) but does not use the same internals, so even though we are using the GNU gettext (__USE_GNU_GETTEXT = 1), the libintl included with the libc does not define _nl_msg_cat_cntr (nor does it need it). There is no preprocessor definition for musl (as it is an attempt to be a strictly compliant POSIX C library - see http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F for info) so it should likely be a CMake test to determine if the symbol is available. Reproducible: Always Steps to Reproduce: 1. Use musl libc. 2. Attempt to build ki18n. Actual Results: /usr/src/kde-frameworks/ki18n-5.24.0/work/ki18n-5.24.0/src/kcatalog.cpp:177: undefined reference to `_nl_msg_cat_cntr' Expected Results: Successful build. Relevant configure output: -- Looking for __GLIBC__ -- Looking for __GLIBC__ - not found -- Performing Test _OFFT_IS_64BIT -- Performing Test _OFFT_IS_64BIT - Success -- Looking for dngettext -- Looking for dngettext - found -- libintl is part of libc, no extra library is required. -- Found LibIntl: /usr/include -- Found Gettext: /usr/bin/msgmerge (found version "0.19.7") Relevant build log output: CMakeFiles/KF5I18n.dir/kcatalog.cpp.o: In function `KCatalogPrivate::setupGettextEnv()': /usr/src/kde-frameworks/ki18n-5.24.0/work/ki18n-5.24.0/src/kcatalog.cpp:177: undefined reference to `_nl_msg_cat_cntr' collect2: error: ld returned 1 exit status src/CMakeFiles/KF5I18n.dir/build.make:276: recipe for target 'src/libKF5I18n.so.5.24.0' failed
Created attachment 100223 [details] Patch to ki18n to check for presence of _nl_msg_cat_cntr before using it I cannot upload to Gerrit using my KDE Identity account (awilcox) so I am submitting the patch here. This patch allows ki18n (tested on 5.21.0, 5.24.0, and master) to build on both glibc (using _nl_msg_cat_cntr) and musl (without using _nl_msg_cat_cntr).
The patch seems fine to me, but this is also the question of which conventions we follow for this type of configuration in CMake, and that I'm not so sure about. So for the moment I'll just add someone who knows better, or knows who knows better, to CC.
I was just pointed to this bug by a musl user on my distro. What's the status of this patch. Why wasn't it posted to phabricator?
The patch as attached looks stylistically correct to me, using a CMake check to generate a config.h file that would then be used for the include guard. That's also how I'd do it, and I wouldn't have even bothered to fix the .gitignore myself. However the patch wouldn't have worked directly (the fix to FindLibIntl.cmake uses "HAVE_..." while the code checks for "HAS_..."). Also I'd use a namespaced include guard in config.h (e.g. "#ifndef KF5_KI18N_CONFIG_H ..." instead of "#ifndef CONFIG_H"), but that's more about residual trauma from --enable-final builds back in the day. Since we've already got a soft +1 on this patch already I'll go ahead and commit the corrected patch in the next day or two if there's no objections from here. P.S. I've previously built all of KF5 on Alpine Linux (also using musl libc) while testing Docker, but I think that had worked because I had also installed GNU libintl, presumably that overrides the musl libintl if both exist?
I didn't have a Phabricator account at the time I reported this bug, and I lost track of this bug when I brought the other patches over to Phabricator. Sorry! Yes, GNU libintl on Alpine will override musl. We're shipping gettext-tiny in Adélie now, which has a tiny libintl.a containing only this symbol and a few others that are needed. However, since "libintl is part of libc", ki18n still won't link to it, and still fails with this error. Thank you for the style notes, Michael; I'll be sure to keep them in mind for any future patches I write.
Git commit 543b8ae67c57500bf3cabde75bf1599904d6e482 by Michael Pyne, on behalf of A. Wilcox. Committed on 15/07/2018 at 18:08. Pushed by mpyne into branch 'master'. libintl: Determine if _nl_msg_cat_cntr exists before use Using GNU gettext does not guarantee that GNU libintl will be used. This assumption breaks the build when using musl libc (which does implement libintl, but does so without using internal GNU symbols). FIXED-IN:5.49.0 M +1 -0 .gitignore M +3 -0 CMakeLists.txt M +3 -0 cmake/FindLibIntl.cmake A +25 -0 src/config.h.in M +3 -2 src/kcatalog.cpp https://commits.kde.org/ki18n/543b8ae67c57500bf3cabde75bf1599904d6e482