wireshark3 @3.4.0_0+cares+chmodbpf+geoip+gnutls+kerberos5+libsmi+python37+qt5+zlib: error: use of undeclared identifier 'CLOCK_REALTIME'

[thetrial (alabay)]

Wireshark3 won’t update under El Capitan (!) – I know that there usually is another qt level under El Capitan, but normally it works with a lower qt version. This time something hangs. Maybe this has to do with El Capitan?

I don’t know if it is an error or incompatibility.

:info:build make[2]: *** [ui/qt/CMakeFiles/qtui.dir/import_text_dialog.cpp.o] Error 1

:info:build make[1]: *** [ui/qt/CMakeFiles/qtui.dir/all] Error 2

I’ll attach main.log.

[ryandesign (Ryan Carsten Schmidt)]

The build fails because:

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_wireshark3/wireshark3/work/wireshark-3.4.0/ui/qt/import_text_dialog.cpp:388:27: error: use of undeclared identifier 'CLOCK_REALTIME'
:info:build             clock_gettime(CLOCK_REALTIME, &timenow); /* supported by Linux and MacOS */
:info:build                           ^

Realtime clock is a feature introduced in macOS 10.12.

We have compatibility functions in our legacysupport library which could possibly be used to fix this port.

[thetrial (alabay)]

Version has been elevated to 3.4.1 … problem stays the same.

[ghosthound]

I don't have an El Capitan (10.11) system to dev/test with. If someone does and wants to look into this please let me know.

[mascguy (Christopher Nielsen)]

Created new Wireshark3 issue:

​https://gitlab.com/wireshark/wireshark/-/issues/17101

Also provided them with a patch to fix the issue. See attached file wireshark3-patch-fix-clock_realtime.diff.

[mascguy (Christopher Nielsen)]

Note that patch was created against Wireshark 3.4.0. Also, I can confirm that it fixes the build failure on MacOS 10.8.

[kencu (Ken)]

patch is nice -- but we will want (and upsteam will want) to use the main pathway for all systems that can support it, ie 10.12 up.

[mascguy (Christopher Nielsen)]

Replying to kencu:

patch is nice -- but we will want (and upsteam will want) to use the main pathway for all systems that can support it, ie 10.12 up.

Well, the worst they can do is reject the bug/patch, with that sentiment. But let's await their response.

[ghosthound]

Can you improve the patch to detect macOS versions that do not have 'CLOCK_REALTIME' and do the workaround only for those systems? I'd think that would make it more likely to be accepted.

[mascguy (Christopher Nielsen)]

The Wireshark folks generalized my patch, to formally deal with platform time differences:

​https://gitlab.com/wireshark/wireshark/-/merge_requests/1404

Net-Net, a fix has been merged into master.

[kencu (Ken)]

Replying to mascguy:

Replying to kencu:

patch is nice -- but we will want (and upsteam will want) to use the main pathway for all systems that can support it, ie 10.12 up.

Well, the worst they can do is reject the bug/patch, with that sentiment. But let's await their response.

So they did exactly what I said, using the main pathway for all systems that have it, and falling back when it's not available.

Why would you think there was a bad sentiment to that? We will always do that.

[mascguy (Christopher Nielsen)]

Replying to kencu:

Why would you think there was a bad sentiment to that? We will always do that.

I didn't mean to imply there would be any bad sentiment, but rather, that our proposed patch might simply be rejected.

Regardless, yesterday was a good day: Not only did the Wireshark folks accept our issue, they were also kind and generous enough to commit a fix a few hours later. Huge kudos to them!

[thetrial (alabay)]

I guess I’m too impatient … but with version 3.4.2 the problem is not fixed yet. Or do I have to apply something?

[mascguy (Christopher Nielsen)]

Replying to thetrial:

I guess I’m too impatient … but with version 3.4.2 the problem is not fixed yet. Or do I have to apply something?

Yes, you'd need to utilize a patch, until the next release.

The easier route is to use the one I attached. Alternatively, you can apply the official changes, though that involves three files/patches:

​https://gitlab.com/wireshark/wireshark/-/commit/ca99a821b4021b2367152ed6547615b098ac7c71

[thetrial (alabay)]

Hm, something went wrong.

can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- old/ui/qt/import_text_dialog.cpp	2020-12-20 11:02:56.000000000 -0500
|+++ new/ui/qt/import_text_dialog.cpp	2020-12-15 16:53:01.000000000 -0500
--------------------------
File to patch:

I don’t know why. I tried to apply your patch with:

cd $(port dir wireshark3)
net/wireshark3 # patch -p0 < ~/Downloads/wireshark3-patch-fix-clock_realtime.diff

[mascguy (Christopher Nielsen)]

Replying to thetrial:

Hm, something went wrong.

can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- old/ui/qt/import_text_dialog.cpp	2020-12-20 11:02:56.000000000 -0500
|+++ new/ui/qt/import_text_dialog.cpp	2020-12-15 16:53:01.000000000 -0500
--------------------------

You need to modify the embedded paths in the patch, relative to where it's run from. Try removing the old/ and new/ prefixes from the two filenames.

[kencu (Ken)]

Replying to thetrial:

Hm, something went wrong.

can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- old/ui/qt/import_text_dialog.cpp	2020-12-20 11:02:56.000000000 -0500
|+++ new/ui/qt/import_text_dialog.cpp	2020-12-15 16:53:01.000000000 -0500
--------------------------
File to patch:

I don’t know why. I tried to apply your patch with:

cd $(port dir wireshark3)
net/wireshark3 # patch -p0 < ~/Downloads/wireshark3-patch-fix-clock_realtime.diff

You don't run the patch from this directory:

cd $(port dir wireshark3)

you run it from this directory:

cd $(port work wireshark3)

The work directory doesn't exist until the build is in progress, so you can do this:

sudo port clean wireshark3
sudo port -v patch wireshark3
cd $(port work wireshark3) 
sudo chmod -R a+rw ./*
patch -p1 < ~/Downloads/wireshark3-patch-fix-clock_realtime.diff
cd ~
sudo port -v -s install wireshark3

[thetrial (alabay)]

After patch.

[thetrial (alabay)]

Hm, that did not work either. I got the same error. Then I tried to go the way by foot … and copied the patchfile to:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_wireshark3/wireshark3/work/wireshark-3.4.2 (oh, I forgot to mention the diffs-folder, of course I put it in the diffs folder für macosx stuff)

Now … it seems I have a different error, not clocktime anymore?!

[mascguy (Christopher Nielsen)]

I'm seeing the original compilation failure. Are you sure the patch was applied successfully?

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_wireshark3/wireshark3/work/wireshark-3.4.2/ui/qt/import_text_dialog.cpp:388:27: error: use of undeclared identifier 'CLOCK_REALTIME'
:info:build             clock_gettime(CLOCK_REALTIME, &timenow); /* supported by Linux and MacOS */
:info:build                           ^

[thetrial (alabay)]

No, I’m not. Perhaps I did it wrong. As said, the usual way led to the same error message for pattching. So, I should wait, I guess.

[mascguy (Christopher Nielsen)]

If folks are interested in fixing this ASAP, I'll submit a pull request using the official patch. Otherwise it should be fixed with the next Wireshark3 release.

Let me know.

[mascguy (Christopher Nielsen)]

Update: With the official patch, the build fails on MacOS 10.8 due to a new issue: QOperatingSystemVersion is now needed, and that requires at least QT 5.9. Whereas Wireshark3 is building with QT 5.7 on 10.8.

Is QT 5.9 supported, and operational, on MacOS 10.8?

[kencu (Ken)]

Replying to mascguy:

Is QT 5.9 supported, and operational, on MacOS 10.8?

It doesn't appear so <​https://github.com/macports/macports-ports/blob/a37f84e0c972f3a80e368a2d72fcba33b08d91f1/_resources/port1.0/group/qt5-1.0.tcl#L73> although I have never personally put forth any effort into trying to fix qt59 on 10.8.

[mascguy (Christopher Nielsen)]

Replying to kencu:

Replying to mascguy:

Is QT 5.9 supported, and operational, on MacOS 10.8?

It doesn't appear so <​https://github.com/macports/macports-ports/blob/a37f84e0c972f3a80e368a2d72fcba33b08d91f1/_resources/port1.0/group/qt5-1.0.tcl#L73> although I have never personally put forth any effort into trying to fix qt59 on 10.8.

Of note, we'll need a strategy for dealing with this, for the next major Wireshark release...

[mascguy (Christopher Nielsen)]

After doing more build testing with a simpler patch - and re-encountering the build error related to QT 5.9 - I realized that the wireshark version is now at 3.4.2. Duh, right?

In any case, after pondering this for a few weeks, these are my recommendations:

For the immediate term: To ensure our users have access to wireshark3 for older macOS releases, update the port to gracefully fallback to 3.4.1 [for those cases]. That will stop the bleeding, and provide said users with a working port. This should probably be done ASAP.

Longer-term: If we want to support the latest wireshark3 releases across-the-board, there's going to be some work involved. Either we'll need to get QT 5.9 working for older macOS versions, or patch wireshark3 to not require QT 5.9 components. (I don't know whether the latter is even practical - or feasible - but throwing it out there as an idea.) Someone should also check the cmake scripts, and see if the project has a flag to disable the use of newer QT components. That sounds too good to be true, but who knows.

Thoughts?

[thetrial (alabay)]

By the way … today mesa 19.0.8_0 gave the same error it seems. Currently I can’t file a ticket yet.

[ghosthound]

I'm reluctant to do much to support a very old version of macOS, and in particular not willing to fall back to an older wireshark release to do so - that impacts everyone using a "current" version of macOS. If someone wants to develop and maintain patches for wireshark (and dependencies) to support older versions of macOS and those patches do not impact users on "current" macOS, happy to review them for acceptance. As discussed previously, if upstream is willing to patch to support older versions of macOS, that's the best.

[mascguy (Christopher Nielsen)]

Replying to ghosthound:

I'm reluctant to do much to support a very old version of macOS, and in particular not willing to fall back to an older wireshark release to do so - that impacts everyone using a "current" version of macOS.

The proposed immediate-term change wouldn't affect users of later macOS releases, and is trivial to maintain.

To ensure we're on the same page... it would entail simple logic in the portfile, such as:

if { ${os.major} >= <darwin_version_that_support_qt59, etc> } {
    version 3.4.2
    <...3.4.2-specific patches, etc...>
} else {
    version 3.4.1
    <...3.4.1-specific patches, etc...>
}

Does that make sense?

[thetrial (alabay)]

Final El Capitan is two and a half years old. A »very old« version of macOS?! Something goes very badly wrong in the sense of obsolescence, I’d say. Maybe ideological.

[ghosthound]

For "old" version of macOS I was thinking of the mention of 10.8 above. El Capitan (10.11) last release that I know of was 10.11.6 in July 2016, which puts it at ~4.5 years. That's getting up there as well.

For the ${os.major} check proposed - are we doing this in any other ports? If so, are we getting any reports of confusion as to why an older version is installed for an older OS version?

[mascguy (Christopher Nielsen)]

Replying to ghosthound:

For the ${os.major} check proposed - are we doing this in any other ports? If so, are we getting any reports of confusion as to why an older version is installed for an older OS version?

Yep, this strategy is used in other ports too.

As for the confusion aspect, I can't speak to that. But you can help reduce it, by appending some brief text at the end of the port description.

[mascguy (Christopher Nielsen)]

Let's fix this for our users on older macOS releases. Pull request created:

​https://github.com/macports/macports-ports/pull/9744

[Christopher Nielsen <62156882+mascguy@…>]

In 3fc0e042540c4a9db088fbb84f4ab292eafe3c0d/macports-ports (master):

wireshark3: update port to select 3.4.1 for older macOS releases, and add patch for clock_realtime build errors on those (​https://github.com/macports/macports-ports/pull/9744)

Fixes: #61511

Co-authored-by: Christopher Nielsen <mascguy@…>