Add Solaris support by vlmarek · Pull Request #3515 · jqlang/jq

vlmarek · 2026-03-30T13:21:06Z

I love jq :) So while updating the version we ship in Solaris I have tried to modify stuff to make everything work out of the box. Just

autoreconf -fiv
./configure
gmake
gmake check

I also went ahead and created Solaris test action should you be interested in having it too. The changes are not extensive and I have tried to comment them nicely in each commit. Hopefully that's enough.

Thanks for jq!

wader · 2026-04-05T10:17:44Z

  }
+#endif
+#if defined(__sun)
+  tzset();


Possible to skip above tzset and call it once here?

wader · 2026-04-05T10:22:05Z

Hey, glad to share the love of jq :) Looks good to me, but i lack autotools knowledge to review those parts. Hopefully some other maintainer can shim in.

itchyny · 2026-04-08T05:41:59Z

  else
    dt1=$(LC_ALL=$l date +'%a %d %b %Y at %H:%M:%S')
-    dt2=$(LC_ALL=$l jq -nr 'now | strflocaltime("%a %d %b %Y at %H:%M:%S")')
+    dt2=$(LC_ALL=$l $JQ -nr 'now | strflocaltime("%a %d %b %Y at %H:%M:%S")')


I'd like to cherry-pick this change in separate PR.

itchyny · 2026-04-08T06:11:06Z

In my honest opinion as one of the active maintainers, we can't officially support the architecture that none of the maintainers is familiar with. Adding a job to the CI workflow could be a pain for us, because it blocks everything when it's broken. But fixing the code and build scripts for wider portability is acceptable. Just like I included #3277. We don't ensure the permanent support for the unfamiliar (for us) architecture in the future releases, but if distributors have trouble while building the package, fixing the code in the upstream (us!) is better than distributors patching for their packages.

vlmarek · 2026-04-08T07:03:29Z

Hi, thanks for looking into this PR! I do understand your concern with alien OS. Fair enough :) What next? I think that all the patches are non-intrusive and safe for other architectures. If you want me to just remove the the github actions and merge the two tzest calls into one (nice touch) I'm happy to do so. At any rate the patches will be eventually available here: https://github.com/oracle/solaris-userland/tree/master/components/jq. Thanks!

itchyny · 2026-04-08T07:16:26Z

If you want me to just remove the the github actions and merge the two tzest calls into one (nice touch) I'm happy to do so.

Yes, please.

Solaris comes with own make implementation which is does not work with GNU tools well. Running configure ends with this error: config.status: error: Something went wrong bootstrapping makefile fragments for automatic dependency tracking. If GNU make was not used, consider re-running the configure script with MAKE="gmake" (or whatever is necessary). You can also try re-running configure with the '--disable-dependency-tracking' option to at least be able to build the package (albeit without support for automatic dependency tracking).

vlmarek · 2026-04-08T07:32:05Z

Removed github actions, but kept calling twice the tzset(). tzset has to be called after setenv("TZ", ... . Since we are calling setenv twice, we need two tzset too. Unless I'm missing something ...

itchyny · 2026-04-08T08:35:49Z

 for colors in '/' '[30' '30m' '30:31m:32' '30:*:31' 'invalid'; do
-  JQ_COLORS=$colors \
+  export JQ_COLORS=$colors
    $JQ -Ccn '[{"a":true,"b":false},"abc",123,null]' > $d/color 2>$d/warning


Sorry to nit pick, unindent this line.

Well, what's the intention of this change? Why the other tests (Set non-default colors, complex input) works?

I do not mind nitpicking. At least you have a chance of doing thing properly and most importantly only once :)

If I remove this chagne the test fails:

+ 1> /tmp/jqA4UUyb/color 2> /tmp/jqA4UUyb/warning + cmp /tmp/jqA4UUyb/color /tmp/jqA4UUyb/expect + cat /tmp/jqA4UUyb/warning + JQ_COLORS=/ Failed to set $JQ_COLORS + cat /tmp/jqA4UUyb/expect_warning Failed to set $JQ_COLORS + cmp /tmp/jqA4UUyb/warning /tmp/jqA4UUyb/expect_warning /tmp/jqA4UUyb/warning /tmp/jqA4UUyb/expect_warning differ: char 1, line 1

It's a little bit difficult to unpack. I have added a cat to show contents of the file. The test here captures both stdout and stderr in separate files. The stderr contains:

+ JQ_COLORS=/ Failed to set $JQ_COLORS

The expected output is:

Failed to set $JQ_COLORS

It does not happen in any other tests because stderr is not caught or the form VAR=VALUE command is not used. This is /usr/bin/sh peculiarity here.

$ exec bash $ set -x $ AAA=BBB /bin/true 2> x $ cat x $ exec /usr/bin/sh $ set -x $ AAA=BBB /bin/true 2> x $ cat x + AAA=BBB

What shell is /usr/bin/sh? ksh93?

Indeed, ksh93.

Yeah, I see the difference.

$ ksh93 -c 'set -x; AAA=BBB true 2> /tmp/t; cat /tmp/t' + true + 2> /tmp/t + cat /tmp/t + AAA=BBB $ bash -c 'set -x; AAA=BBB true 2> /tmp/t; cat /tmp/t' + AAA=BBB + true + cat /tmp/t $ dash -c 'set -x; AAA=BBB true 2> /tmp/t; cat /tmp/t' + AAA=BBB true + cat /tmp/t

- run tools from /usr/gnu - disable color testing on Solaris - change the way JQ_COLORS is exported to the process First two poinst are self-explanatory. As for JQ_COLORS, the script originally used this form: JQ_COLORS=blah $JQ ... 2>...warning It runs $JQ and compares stderr with expected value. On Solaris the 'warning' file contains also the variable being set. $ cat warning + JQ_COLORS=/ Failed to set $JQ_COLORS Exporting it in advance makes the tests succeed even on Solaris.

On Solaris, strptime clears the tm structure before parsing. This breaks the sentinel logic in builtin.c, which then incorrectly assumes that strptime set tm_wday and tm_yday. Defining _STRPTIME_DONTZERO disables that behavior. As described in strptime(3C): o If _STRPTIME_DONTZERO is not defined, the tm struct is ze- roed on entry and strptime() updates the fields of the tm struct associated with the specifiers in the format string. o If _STRPTIME_DONTZERO is defined, strptime() does not zero the tm struct on entry. Additionally, for some specifiers, strptime() will use some values in the input tm struct to recalculate the date and re-assign the appropriate members of the tm struct.

Solaris prefers the global timezone similarly to Apple. But in addition needs a 'tzset' call in order to recognise that the environment was changed. Without this change shtests fails with: + TZ=Europe/Paris + r='2024-11-14 23:35:41 +0100 CET' + [ '2024-11-14 23:35:41 +0100 CET' '!=' '2024-11-14 23:35:41 +0000 UTC' ] + [ '2024-11-14 23:35:41 +0100 CET' '!=' '2024-11-14 23:35:41 +0000 GMT' ] + echo 'Incorrectly formatted universal time' Incorrectly formatted universal time

wader · 2026-04-08T14:01:21Z

Removed github actions, but kept calling twice the tzset(). tzset has to be called after setenv("TZ", ... . Since we are calling setenv twice, we need two tzset too. Unless I'm missing something ...

Oh sorry now i see, didn't understand this was part of temp changing TZ to UTC

vlmarek · 2026-04-08T14:03:22Z

Thanks for your patience :)

wader reviewed Apr 5, 2026

View reviewed changes

Comment thread src/builtin.c

}

#endif

#if defined(__sun)

tzset();

Copy link
Copy Markdown

Member

wader Apr 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possible to skip above tzset and call it once here?

itchyny reviewed Apr 8, 2026

View reviewed changes

vlmarek force-pushed the solaris branch from 125f4ab to 78ceacb Compare April 8, 2026 07:29

itchyny reviewed Apr 8, 2026

View reviewed changes

vlmarek added 4 commits April 8, 2026 13:11

Do not test system jq

697c432

vlmarek force-pushed the solaris branch from 78ceacb to 697c432 Compare April 8, 2026 11:12

itchyny approved these changes Apr 8, 2026

View reviewed changes

wader approved these changes Apr 8, 2026

View reviewed changes

wader merged commit 9f778b4 into jqlang:master Apr 8, 2026
29 checks passed

Conversation

vlmarek commented Mar 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wader commented Apr 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

itchyny commented Apr 8, 2026

Uh oh!

vlmarek commented Apr 8, 2026

Uh oh!

itchyny commented Apr 8, 2026

Uh oh!

vlmarek commented Apr 8, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wader commented Apr 8, 2026

Uh oh!

Uh oh!

vlmarek commented Apr 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants