Opened 4 months ago

Closed 6 weeks ago

#61511 closed defect (fixed)

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

Reported by: thetrial (alabay) Owned by: ghosthound
Priority: Normal Milestone:
Component: ports Version: 2.6.4
Keywords: legacy-os, elcapitan Cc: mascguy (Christopher Nielsen)
Port: wireshark3

Description (last modified by 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.

Attachments (3)

main.log (4.3 MB) - added by thetrial (alabay) 4 months ago.
wireshark3-patch-fix-clock_realtime.diff (984 bytes) - added by mascguy (Christopher Nielsen) 2 months ago.
main.2.log (4.2 MB) - added by thetrial (alabay) 2 months ago.
After patch.

Change History (37)

Changed 4 months ago by thetrial (alabay)

Attachment: main.log added

comment:1 Changed 4 months ago by thetrial (alabay)

Description: modified (diff)

comment:2 Changed 4 months ago by ryandesign (Ryan Schmidt)

Cc: ghosthound removed
Owner: changed from opendarwin.org@… to ghosthound
Port: wireshark3 added; wireshark3-3.4.0_0+cares+chmodbpf+geoip+gnutls+kerberos5+libsmi+python37+qt5+zlib.darwin_15.x86_64 removed
Summary: wireshark3 @ 3.4.0_0+cares+chmodbpf+geoip+gnutls+kerberos5+libsmi+python37+qt5+zlib.darwin_15.x86_64 ui/qt Errorwireshark3 @3.4.0_0+cares+chmodbpf+geoip+gnutls+kerberos5+libsmi+python37+qt5+zlib: error: use of undeclared identifier 'CLOCK_REALTIME'

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.

comment:3 Changed 3 months ago by thetrial (alabay)

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

comment:4 Changed 3 months ago by 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.

comment:5 Changed 3 months ago by mascguy (Christopher Nielsen)

Cc: mascguy added

comment:6 Changed 2 months ago by 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.

Changed 2 months ago by mascguy (Christopher Nielsen)

comment:7 Changed 2 months ago by 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.

comment:8 Changed 2 months ago by 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.

comment:9 in reply to:  8 ; Changed 2 months ago by 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.

comment:10 Changed 2 months ago by ghosthound

Status: assignedaccepted

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.

comment:11 Changed 2 months ago by 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.

comment:12 in reply to:  9 ; Changed 2 months ago by 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.

comment:13 in reply to:  12 Changed 2 months ago by 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!

comment:14 Changed 2 months ago by 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?

comment:15 in reply to:  14 Changed 2 months ago by 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

comment:16 Changed 2 months ago by 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

comment:17 in reply to:  16 Changed 2 months ago by 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.

comment:18 in reply to:  16 Changed 2 months ago by 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
Last edited 2 months ago by kencu (Ken) (previous) (diff)

Changed 2 months ago by thetrial (alabay)

Attachment: main.2.log added

After patch.

comment:19 Changed 2 months ago by 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?!

Last edited 2 months ago by thetrial (alabay) (previous) (diff)

comment:20 Changed 2 months ago by 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                           ^

comment:21 Changed 2 months ago by 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.

comment:22 Changed 2 months ago by 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.

comment:23 Changed 2 months ago by 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?

comment:24 in reply to:  23 ; Changed 2 months ago by 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.

comment:25 in reply to:  24 Changed 2 months ago by 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...

comment:26 Changed 7 weeks ago by 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?

Last edited 7 weeks ago by mascguy (Christopher Nielsen) (previous) (diff)

comment:27 Changed 7 weeks ago by 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.

comment:28 Changed 7 weeks ago by 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.

comment:29 in reply to:  28 Changed 7 weeks ago by 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?

comment:30 Changed 7 weeks ago by 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.

comment:31 Changed 7 weeks ago by 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?

comment:32 in reply to:  31 Changed 7 weeks ago by 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.

comment:33 Changed 6 weeks ago by 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

comment:34 Changed 6 weeks ago by Christopher Nielsen <62156882+mascguy@…>

Resolution: fixed
Status: acceptedclosed

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@…>

Note: See TracTickets for help on using tickets.