-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test failures on Illumos #11700
Comments
We discussed this in the context of gettext...
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: master...eli-schwartz:meson:solaris-gettext tl;dr we can fix the
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. |
The source code to this test indicates it does pass on Solaris: meson/test cases/linuxlike/3 linker script/meson.build Lines 3 to 7 in 8d2a9e6
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. |
I don't see any references to "version script" or "--version-script" in |
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. |
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. |
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 eli-schwartz@5c69751. |
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 usesi18n.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.
"common/230 external project": make does not seem to undertstand
$<
."linuxlike/3 linker script": ld does not understand
-z gnu-version-script-compat
or--version-script
"python/8 different python versions" (python2): python2 doesn't seem to recognize the extension module.
"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."frameworks/31 curses": It seems like there are conflicting ncurses versions being used.
Calling the test-pot target:
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
python --version
: Python 3.10.6meson --version
: 1.1.99ninja --version
: 1.11.1The text was updated successfully, but these errors were encountered: