Test failures on Illumos

[cebtenzzre]

Describe the bug

I use Illumos as an example of a less common UNIX in order to test my own software for portability. I was told the testsuite passes on Solaris, so I suppose they aren't as similar as I had hoped. Most of these failures don't appear to be a problem with meson itself, and the ones that do aren't that important to me as I can work around them.

To Reproduce

Build meson from source and run the testsuite: ./run_tests.py. For the xgettext issue, create a simple meson.build that uses i18n.gettext and call the <project_id>-pot target.

Expected behavior

I would expect the testsuite to pass.

Actual behavior

"common/103 has header symbol": FILE is also defined in stdlib.h.

test cases/common/103 has header symbol/meson.build:16:2: ERROR: Assert failed: FILE structure is defined in stdio.h, not stdlib.h

"common/230 external project": make does not seem to undertstand $<.

cp  "/tmp/meson/b e8961ad1c0/libfoo/dist/usr/lib";
cp: Insufficient arguments (1)

"linuxlike/3 linker script": ld does not understand -z gnu-version-script-compat or --version-script

gcc  -o libbob.so libbob.so.p/bob.c.o -Wl,-z -Wl,ignore -z defs -shared -fPIC -Wl,--start-group -Wl,-soname,libbob.so -Wl,--end-group -Wl,-z,gnu-version-script-compat '-Wl,--version-script,/tmp/meson/test cases/linuxlike/3 linker script/bob.map'
ld: fatal: option -z has illegal argument 'gnu-version-script-compat'
ld: fatal: unrecognized option '--version-script'

"python/8 different python versions" (python2): python2 doesn't seem to recognize the extension module.

Traceback (most recent call last):
  File "/tmp/meson/b fd975f7bbe/../test cases/python/8 different python versions/blaster.py", line 4, in <module>
    import tachyon
ImportError: No module named tachyon

"frameworks/6 gettext": msgfmt does not accept -o after non-option arguments. Illumos msgfmt does work if you pass -o outfile.mo infile.po instead, so this looks like a simple one to fix.

[1/14] Generating po/fi/LC_MESSAGES/intltest-fi.mo with a custom command
FAILED: po/fi/LC_MESSAGES/intltest.mo 
/usr/bin/msgfmt '../test cases/frameworks/6 gettext/po/fi.po' -o po/fi/LC_MESSAGES/intltest.mo
ERROR: Cannot open file -o.

"frameworks/31 curses": It seems like there are conflicting ncurses versions being used.

gcc  -o basic basic.p/main.c.o -Wl,-z -Wl,ignore -z defs -Wl,--start-group -lncurses -Wl,--end-group
Undefined           first referenced
 symbol                 in file
initscr32                           basic.p/main.c.o
ld: fatal: symbol referencing errors. No output written to basic

Calling the test-pot target:

[0/1] Running external command test-pot
/usr/bin/xgettext: illegal option -- package-name=test
/usr/bin/xgettext: illegal option -- f
Usage:  xgettext [-a [-x exclude-file]] [-jns][-c comment-tag]
        [-d default-domain] [-m prefix] [-M suffix] [-p pathname] files ...
        xgettext -h

And I can only override the msgfmt and xgettext binaries by prepending /usr/gnu/bin to PATH. There are 160 binaries in there and I'm not sure how the other ones affect builds.

System parameters

• Is this a cross build? native build
• Operating system: OmniOS r151042
• python --version: Python 3.10.6
• meson --version: 1.1.99
• ninja --version: 1.11.1

[eli-schwartz]

I use Illumos as an example of a less common UNIX in order to test my own software for portability. I was told the testsuite passes on Solaris, so I suppose they aren't as similar as I had hoped. Most of these failures don't appear to be a problem with meson itself, and the ones that do aren't that important to me as I can work around them.

We discussed this in the context of gettext...

"frameworks/6 gettext": msgfmt does not accept -o after non-option arguments. Illumos msgfmt does work if you pass -o outfile.mo infile.po instead, so this looks like a simple one to fix.

and further discussion (you may have left by then) with @alanc indicated that Solaris passes this gettext unittest only when using GNU gettext installed on Solaris. I've since been discussing a resolution to this, with a pending branch here: https://github.com/mesonbuild/meson/compare/master...eli-schwartz:meson:solaris-gettext

tl;dr we can fix the i18n.gettext() method in Meson, we cannot fix the i18n.merge_file() method as that legitimately is designed for the express purpose of using GNU-specific functionality and there is not necessarily any comparable feature for alternative msgfmt programs.

Calling the test-pot target: [...]

I suspect that maintainer targets will in general prove unsuitable for use with non-GNU gettexts, since those make heavy use of GNU-specific tools such as msginit/msgmerge, but that's not a problem at build time, only as part of the release manager's job.

[eli-schwartz]

"linuxlike/3 linker script": ld does not understand -z gnu-version-script-compat or --version-script

The source code to this test indicates it does pass on Solaris: https://github.com/mesonbuild/meson/blob/8d2a9e6e5c10f5e6c45d7954a063d015cb33bf8c/test%20cases/linuxlike/3%20linker%20script/meson.build#L3-L7

Apparently not on Illumos. Is this functionality available in some other way there? Alternatively we could mark the test case to be skipped on Illumos if it is simply not applicable.

[cebtenzzre]

I don't see any references to "version script" or "--version-script" in man ld. GNU ld is available in /usr/gnu/bin but I'm not sure how to try it with the testsuite; prepending it to PATH isn't sufficient. (edit: I also tried CC_LD=gold but GCC seems to ignore -fuse-ld=gold on this platform, even though ld.gold is in /usr/gnu/bin.) There's a related LLVM issue: https://reviews.llvm.org/D84559

[alanc]

Yes, the GNU version script compatibility was added to the Solaris linker years after the OpenSolaris source was closed, so was too late for illumos to inherit it. The Solaris & illumos linker both support the original SVR4 mapfile format, which the GNU version script format was based on and then extended, and the Solaris version 2 mapfile format, which is somewhat different to both GNU & SVR4.

[alanc]

From the Solaris 11.4 side, meson isn't perfect out of the box - we do some work in packaging it. This includes things like setting specific paths to find tools, applying some patches to the source, documenting tests we expect to fail, and comparing test results against our expected baseline.

[eli-schwartz]

"common/230 external project": make does not seem to undertstand $<.

I thought I recalled fixing this somewhere, git log --all finally helped me track it down... it's one of the commits on #10733, specifically commit https://github.com/eli-schwartz/meson/commit/5c69751abcca965f1231bd0237f85bb68410370c.

[mtelka]

The "common/103 has header symbol" failure is caused by an issue in illumos headers. See #13688 and https://www.illumos.org/issues/16793 for details.