Libelektra: 0.9.2 fails to build on non-glibc systems

[haraldg]

Steps to Reproduce the Problem

I'm cross compiling elektra for OpenWRT. (See https://github.com/openwrt/packages/issues/12307) I have added the following CMAKE_OPTIONS among others:

-DBUILD_TESTING=OFF
-DPLUGINS="ALL;-multifile;-python2;-simpleini"
-DBINDINGS="MAINTAINED;-intercept_env;-intercept_fs"

which I believe should disable everything, that depends on glibc.

Expected Result

cmake completes successfully.

Actual Result

cmake says:

[...]
-- Looking for __GNU_LIBRARY__
-- Looking for __GNU_LIBRARY__ - not found
-- Exclude Plugin simpleini because simpleini needs glibc to work, use the mini plugin instead
[...]
-- Exclude Binding intercept_fs because explicitly excluded
-- Exclude Binding intercept_env because explicitly excluded
[...]
-- Configuring incomplete, errors occurred!
See also "/home/harald/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/target-arm_arm926ej-s_musl_eabi/elektra-0.9.2/CMakeFiles/CMakeOutput.log".
See also "/home/harald/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/target-arm_arm926ej-s_musl_eabi/elektra-0.9.2/CMakeFiles/CMakeError.log".

Which suggests, that
a) disabling simpleini was not honored
b) despite simpleini was excluded anyway, cmake still failed.

System Information

• Elektra Version: 0.9.2
• OpenWRT SDK

Further Log Files and Output

CMakeError.log
stdout of the build job

[markus2330]

Thank you for updating the packages and reporting the issue!

I do not think the overall error (making cmake fail) is related to simpleini, although I agree that CMakeError.log should not contain this error if simpleini was explicitly disabled. (But I think this is a separate, rather minor issue.)

When I try to compile with your command-line flags, I get the error (to stderr):

`CMake Error at src/bindings/io/uv/CMakeLists.txt:61 (add_executable):
  Error evaluating generator expression:

    $<TARGET_OBJECTS:cframework>

  Objects of target "cframework" referenced but no such target exists.


CMake Error at src/bindings/io/glib/CMakeLists.txt:52 (add_executable):
  Error evaluating generator expression:

    $<TARGET_OBJECTS:cframework>

  Objects of target "cframework" referenced but no such target exists.


CMake Error at src/bindings/io/uv/CMakeLists.txt:61 (add_executable):
  No SOURCES given to target: testio_uv


CMake Error at src/bindings/io/glib/CMakeLists.txt:52 (add_executable):
  No SOURCES given to target: testio_glib

The problem seems to be that building the io binding without TESTING seems to be broken.

Updating the cmake call to:

-DBUILD_TESTING=OFF
-DPLUGINS="ALL;-multifile;-simpleini"
-DBINDINGS="MAINTAINED;-intercept_env;-intercept_fs;-io_uv;-io_ev;-io_glib"

will hopefully fix the issue for you. (I also removed -python2, as this plugin is gone now.)

[markus2330]

The proper fix would be to have a if TESTING around the use of $<TARGET_OBJECTS:cframework>. Would be good if we can also have a build job that uses -DBUILD_TESTING=OFF (currently the doc build job is the only one with this option, but this build job does not compile anything at all).

[haraldg]

I do not think the overall error (making cmake fail) is related to simpleini, although I agree that CMakeError.log should not contain this error if simpleini was explicitly disabled. (But I think this is a separate, rather minor issue.)

Well, it is the only error in CMakeError.log ...

When I try to compile with your command-line flags, I get the error (to stderr):

I don't get such an error. And actually the io bindings aren't compiled. In output.log you can verify, that all of them are excluded because of missing dependencies. I tried your suggestion anyway, but as expected, it didn't change anything.

Also note that cmake doesn't output any Errors to stdout or stderr other then the one error in CMakeError.log

[haraldg]

BTW, there is also an other cmake issue, that mystifies me. It only affects the host build and I think in 0.9.2 it isn't necessary to have a host build anymore, so this is not critical. On host builds I have this in CMakeError.log:

/usr/bin/cc -O2 -I/home/harald/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/host/include -I/home/harald/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/hostpkg/include -I/home/harald/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/target-arm_arm926ej-s_musl_eabi/host/include -std=gnu99  -Wno-deprecated-declarations  -Wstrict-prototypes  -Wno-long-long -Wpedantic -Wno-variadic-macros -Wall -Wextra -Wno-overlength-strings -Wsign-compare -Wfloat-equal -Wformat -Wformat-security -Wshadow -Wcomments -Wtrigraphs -Wundef -Wuninitialized -Winit-self -Wmaybe-uninitialized -Wsign-compare -Wfloat-equal -DCHECK_FUNCTION_EXISTS=pthread_create  -L/home/harald/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/host/lib -L/home/harald/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/hostpkg/lib -L/home/harald/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/target-arm_arm926ej-s_musl_eabi/host/lib  CMakeFiles/cmTC_14bbb.dir/CheckFunctionExists.c.o  -o cmTC_14bbb  -lpthreads 
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status

for checking if libpthread is available. Since the library is called libpthread without the final 's' this is not surprising. What is surprising is, that I don't see the same error on target builds.

Both builds should use the cmake version from the OpenWRT SDK: 3.17.0

Incidentally, I do have the same error in CMakeError.log on native builds (cmake version 3.16.3) but for native builds this doesn't cause the compilation to fail.

[markus2330]

Well, it is the only error in CMakeError.log ...

CMakeError.log is a misleading name, it does not contain errors of CMake but it is the error log of tools executed by cmake. The "error" you see is the expected output of non-glibc systems. This code is only compiled to check if the symbol is available. Because the symbol is not available, simpleini would be excluded, even if you would not have -simpleini in the PLUGINS. (I agree, however, that the check should not be done if you already explicitly excluded the plugin.)

I don't get such an error. And actually the io bindings aren't compiled. In output.log you can verify, that all of them are excluded because of missing dependencies. I tried your suggestion anyway, but as expected, it didn't change anything.

Ok, then we probably have a third problem here. (Unless there is something I overlooked in the very short simpleini CMake file.)

Can you please paste the full output (stdout+stderr)?

Also note that cmake doesn't output any Errors to stdout or stderr other then the one error in CMakeError.log

For me, the above error about io errors is not written to CMakeError.log, thus I suggested the fix to you. Probably we also have another problem with -DBUILD_TESTING=OFF I cannot reproduce on amd64.

BTW, there is also an other cmake issue, that mystifies me. It only affects the host build and I think in 0.9.2 it isn't necessary to have a host build anymore, so this is not critical.

Yes, I also think it is not needed anymore. (symbol export was rewritten to CMake by @kodebach)

On host builds I have this in CMakeError.log:

Thank you for reporting. This is, however, if it is any issue (maybe it is also expected output in the detection code of threads), an upstream CMake issue (or OpenWRT problem). We use the built-in functionality of cmake to detect which is the correct pthread library.

[haraldg]

Ok, here for a build with:

make -j1 V=s package/elektra/compile >output.log 2>error.log

error.log
output.log

[markus2330]

Thank you, so the CMake error is:

CMake Error at scripts/kdb/CMakeLists.txt:14 (install):
  install PROGRAMS given directory
  "/home/harald/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/target-arm_arm926ej-s_musl_eabi/elektra-0.9.2/scripts/kdb/CMakeFiles"
  to install.

Is there maybe a garbage directory in "scripts/kdb"? ls -la scripts/kdb

https://stackoverflow.com/questions/18968510/what-does-the-cmake-error-message-install-files-given-directory-mean

If this is not the problem: Did you set TARGET_TOOL_EXEC_FOLDER somehow weird? (containing a further PROGRAMS directive?) We forgot to make that line safe against CMake code injections.

[haraldg]

Well, the only thing I can think about is, that OpenWRT forces us to do in tree builds. This is the entire CMAKE_OPTIONS:

CMAKE_OPTIONS = \
        -DTARGET_PLUGIN_FOLDER="" \
        -DBUILD_FULL=OFF \
        -DBUILD_STATIC=OFF \
        -DBUILD_DOCUMENTATION=OFF \
        -DFORCE_IN_SOURCE_BUILD=ON \
        -DBUILD_TESTING=OFF \
        -DKDB_DEFAULT_RESOLVER=resolver_fm_pb_b \
        -DKDB_DEFAULT_STORAGE=ini \
        -DENABLE_OPTIMIZATIONS=OFF \
        -DPLUGINS="ALL;-multifile;-simpleini" \
        -DBINDINGS="MAINTAINED;-intercept_env;-intercept_fs;-io_uv;-io_ev;-io_glib" \
        -DIconv_LIBRARY=-liconv \
        -DIconv_INCLUDE_DIR="$(ICONV_PREFIX)/include"

The output of ls -la build_dir/target-arm_arm926ej-s_musl_eabi/elektra-0.9.2/scripts/kdb/:

insgesamt 88
drwxr-xr-x  3 harald harald 4096 Mai 29 14:44 .
drwxr-xr-x 15 harald harald 4096 Mai 29 14:44 ..
-rw-r--r--  1 harald harald  953 Mai 29 14:44 backup
-rw-r--r--  1 harald harald  966 Mai 26 17:13 backup.in
drwxr-xr-x  2 harald harald 4096 Mai 29 14:44 CMakeFiles
-rw-r--r--  1 harald harald  669 Mai 26 17:13 CMakeLists.txt
-rwxr-xr-x  1 harald harald 1031 Mai 26 17:13 cmerge-config-files
-rwxr-xr-x  1 harald harald  569 Mai 29 14:44 elektrify-getenv
-rwxr-xr-x  1 harald harald  621 Mai 26 17:13 elektrify-getenv.in
-rwxr-xr-x  1 harald harald  411 Mai 29 14:44 elektrify-open
-rwxr-xr-x  1 harald harald  441 Mai 26 17:13 elektrify-open.in
-rwxr-xr-x  1 harald harald 5982 Mai 26 17:13 find-tools
-rwxr-xr-x  1 harald harald 2531 Mai 26 17:13 install-config-file
-rwxr-xr-x  1 harald harald  195 Mai 29 14:44 list-tools
-rwxr-xr-x  1 harald harald  217 Mai 26 17:13 list-tools.in
-rwxr-xr-x  1 harald harald  678 Mai 26 17:13 mount-augeas
-rwxr-xr-x  1 harald harald  953 Mai 26 17:13 mount-info
-rwxr-xr-x  1 harald harald  321 Mai 26 17:13 mount-kde
-rwxr-xr-x  1 harald harald  424 Mai 26 17:13 mount-list-all-files
-rwxr-xr-x  1 harald harald  215 Mai 26 17:13 mount-openicc
-rwxr-xr-x  1 harald harald 2325 Mai 26 17:13 mountpoint-info

[kodebach]

I think you need to add LIST_DIRECTORIES false to the file(GLOB command in the CMake file with the error:

https://github.com/ElektraInitiative/libelektra/blob/2b94668c7360d5a80171aaea3752c059d09a1e6c/scripts/kdb/CMakeLists.txt#L10-L15

Otherwise the GLOB will include the auto-generated CMakeFiles directory.

[markus2330]

@kodebach thank you :1st_place_medal:

But probably this is needed in several places. We need to check this. And we also need to test the in-source-tree builds on the build server in future.

@haraldg Can you easily patch the source or should we rather make a new release?

[haraldg]

Sure, I can include the patch in the OpenWRT package. No release is needed.

But it would help, if you created a branch at the 0.9.2 tag and cherry-picked the fix there. Much easier to keep track of things that way.

[neheb]

A small note:

OpenWrt has CMAKE_BINARY_SUBDIR to avoid that issue.

[markus2330]

@neheb Thank you for the hint! :fireworks:

If we could drop support for in-source-tree-builds, we would be very happy (it would reduce half of the possible CMake build combinations). Afaik OpenWRT is the only reason why we still support it.

[neheb]

Hmm? Doesn't CMAKE_BINARY_SUBDIR solve that?

[haraldg]

Thanks, for the pointer! Looks like CMAKE_BINARY_SUBDIR has been introduced shortly after the initial packaging and I never notriced. There is no equivalent for host builds yet, but I guess I'd rather add a patch to openwrt for it than force in source builds on elektra.

Your suggestion did the trick. I'm running into new errors, but I'll open new issues for them, if I believe they are elektra's fault or I can't figure them out.