meson: if -Dsm-scripting=true, C code fails to build due to -xc++

[jhgit]

noticed on ver: 0.15.0

If you use meson and enable sm-scripting, it sets extracflags to -xc++. That seems to be effective globally, not just for the ecmascript code. Because of this, C code builds can fail. The first failure I noticed was src/bookmarks/backend/common.c:

In file included from ../src/bookmarks/backend/common.c:13:
In file included from ../src/bfu/dialog.h:5:
In file included from ../src/bfu/widget.h:10:
In file included from ../src/bfu/inpfield.h:6:
../src/util/lists.h:231:2: error: assigning to 'struct list_head_elinks *' from incompatible type 'void *'
        foreach (item, *list)
        ^~~~~~~~~~~~~~~~~~~~~
../src/util/lists.h:191:17: note: expanded from macro 'foreach'
        for ((e) = (l).next; \
                   ~~~~^~~~
../src/util/lists.h:231:2: error: assigning to 'struct list_head_elinks *' from incompatible type 'void *'
        foreach (item, *list)
        ^~~~~~~~~~~~~~~~~~~~~
../src/util/lists.h:193:18: note: expanded from macro 'foreach'
             (e) = (e)->next)
                   ~~~~~^~~~

Is building just the ecmascript code with a c++ compiler the right way to solve this (however that is achieved in meson)?

FWIW, I tried meson because autoconf was failing to build the ecmascript code with spidermonkey78 installed (and enabled with --enable-sm-scripting --with-spidermonkey). The problem there was the opposite issue - all the code was being built with the C compiler, and the ecmascript build was failing because it was not using the C++ compiler (failed due to including C++ headers like "#include " in the spidermonkey78 header files).

[rkd77]

Thanks for the report. Yes, this fragment was not checked. It is compilable when both: -Dspidermonkey=true
-Dsm-scripting=true are set. Browser (www) part can be disabled in option manager.

[jhgit]

I had both -Dspidermonkey=true and -Dsm-scripting=true. But I tried your patch anyway. Same problem.

[jhgit]

Here is the compiler invocation for common.c:

cc -Isrc/elinks.p -Isrc -I../src -I. -I.. -I/usr/local/include -I/usr/local/include/nspr -I/usr/local/include/lua52 -I/usr/local/include/libxml++-5.0 -I/usr/local/include/libxml++-5.0/include -I/usr/local/include/libxml2 -fno-color-diagnostics -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 '-DGETTEXT_PACKAGE="elinks"' '-DBUILD_ID="-dirty"' -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -include /usr/local/include/mozjs-78/js/RequiredDefines.h -isystem /usr/local/include/mozjs-78 -isystem /usr/local/include -DHAVE_CONFIG_H -fno-strict-aliasing -Wno-builtin-declaration-mismatch -Wno-address -xc++ -fpermissive -MD -MQ src/elinks.p/bookmarks_bookmarks.c.o -MF src/elinks.p/bookmarks_bookmarks.c.o.d -o src/elinks.p/bookmarks_bookmarks.c.o -c ../src/bookmarks/bookmarks.c
warning: unknown warning option '-Wno-builtin-declaration-mismatch'; did you mean '-Wno-missing-declarations'? [-Wunknown-warning-option]

This is clang 12, by the way. I added the warning line above as extra info - apparently clang does not have that -W option for compatibility with gcc. That's not important for this bug - just FYI that there is a gcc-specific -W option in meson.build that clang does not currently have.

If you remove the -xc++, it compiles successfully.

[rkd77]

This time I compiled with clang 11.

[jhgit]

I tried clang10 and clang11 as well. Same results for common.c

And for good measure gcc10 and gcc12. Same complaints, but they are warnings (unlike clang's treating them as errors). I suppose that using gcc and tolerating the warnings is a workaround, but that doesn't seem like the right answer (I haven't tried building every file with gcc yet instead).

It seems to me it would be best to compile C code without -xc++. I just haven't figured out how to convince meson to build elinks that way yet.

[eli-schwartz]

Generally, you would compile a selection of files that need different c_args as a static_library() and link it into the main executable.

The alternative would be acknowledging that certain files are effectively C++, and renaming them from .c to .cpp.

[rkd77]

#!/bin/sh

rm -rf /dev/shm/buildC2_clang

CC=clang CXX=clang++ meson /dev/shm/buildC2_clang  -Dbrotli=true \
-Dutf-8=true \
-Dtrue-color=true \
-Dgopher=true \
-Dbzlib=true \
-Dlzma=false \
-Dperl=false \
-Dzlib=true \
-Dbacktrace=false \
-Dcombining=true \
-Dbittorrent=true \
-D88-colors=false \
-D256-colors=true \
-Dopenssl=false \
-Dgnutls=true \
-Dlibevent=false \
-Dlibev=false \
-Dterminfo=false \
-Dcgi=true \
-Druby=false \
-Dsm-scripting=true \
-Dpython=false \
-Dzstd=true \
-Dwithdebug=false \
-Dguile=false \
-Dgpm=true \
-Dprefix=$HOME \
-Dx=false \
-Dnntp=true \
-Dcss=true \
-Dgemini=true \
-Dgettext=false \
-Dquickjs=false \
-Dspidermonkey=false
#-Dluapkg='luajit'

meson compile -C /dev/shm/buildC2_clang

This script compiles today's master branch. Could you show your script?

[rkd77]

Yes, 0.15.0 does not build with -Dsm-scripting=true. There was a bit of changes since then. master compiles with the same meson options. I don't consider backporting changes to the 0.15 branch.

[jailbird777]

Since 0.15.x isn't going to have this working, are there any plans to have a stable-ish release any time soon with this functionality?

[rkd77]

ok. I'm going to release current git master as 0.15.1 on the last Sunday of July. Please check whether current git version compiles.

[jailbird777]

Okay, so I'm using the git master and I can't even get as far as you guys did. Using clang 14 or gcc 11, it gives:

cc1: warning: command-line option '-std=gnu++17' is valid for C++/ObjC++ but not for C

But keeps going on at least. However, they both eventually die with:

  [CC]   src/dialogs/info.o

cc1: warning: command-line option '-std=gnu++17' is valid for C++/ObjC++ but not for C cc1: warning: command-line option '-fpermissive' is valid for C++/ObjC++ but not for C In file included from /usr/local/include/mozjs-78/jsapi.h:12, from ../.././src/ecmascript/ecmascript.h:13, from info.c:22: /usr/local/include/mozjs-78/mozilla/AlreadyAddRefed.h:12:10: fatal error: utility: No such file or directory 12 | #include | ^~~~~~~~~ compilation terminated.

I'm assuming it's because it's including C++ from C and utility is a C++ header. So I readded the -xc++ and used gcc 11 (since I know clang didn't like that the last time). It got past all of that. However, once it gets to src/viewer/lib.c:

lib.o:1:1: error: stray '\177' in program lib.o:1:5: error: stray '\2' in program lib.o:1:6: error: stray '\1' in program

I get screenfuls of that (along with control characters). So I need to dig into that.

[rkd77]

Please, show your meson options. meson builds are reproducible.

[rkd77]

If you want this issue to be fixed, provide details: operating system, how do you build elinks, etc.

[rkd77]

I was able to get linking error on Fedora with clang-14 and -Dxbel=true. lto was disabled in 8764def801ad825faf1ce7f8ed5190e6f1c71c9e If it does not resolve issue, I have not ideas. Which linker do you use?

[jailbird777]

Sorry, I'll have a meson command here shortly. The port in FreeBSD currently uses autoconf and I'm moving it over now.

As for linker, for gcc 11 it was using binutils 2.37 (ld, not gold), for clang 14 it was using LLD 14.0.5.

[rkd77]

elinks-0.15 depends on spidermonkey78, sqlite3 and libxml++ (5.0.1.GIT) or higher. For libxml++-5.0.1 at least this https://github.com/libxmlplusplus/libxmlplusplus/commit/f23e0ff9828cd4036870ed8f2c8249cad7b3089a patch should be applied.

[rkd77]

FYI, current master compiles .c files by C compiler and .cpp files by C++ compiler in meson builds.

[jailbird777]

This can be closed, as I just verified your fix on FreeBSD and updated the port.

Thanks!