qt5-qtwebkit: Flag conflicting ports on case insensitive filesystems #16890
Conversation
|
Notifying maintainers: |
|
This fixes the issue, thx! Looking forward to have it merged :) |
|
I probably cannot offer a constructive alternative to this PR anytime soon. However I have not seen explanation for why this issue is specific to ARM64, and so do not see why the proposed change should be specific to one architecture (even if that is all it is commonly reported for); if the actual cause is something like filesystem case insensitivity, then it definitely should be applied to all architectures. And if it is not ARM64 specific, then older qtwebkit ports are likely affected, and the same fixes should be applied eventually for consistency. Also, does the proposed approach of removing |
|
Honestly, I don't know why it is specific to ARM (all of my intel machines work fine...). I can easily remove the architecture if statement. I have successfully compiled and tested on intel with that change and did not see any adverse effects (only added the if statement out of the "if it ain't broke don't fix it" mentality). From what I can tell in the build logs, the At any rate, this has been an issue for over a year. It would be nice if it eventually got addressed either by this proposed work around or something better. |
|
it would sure be nice to know which external header(s) are causing the issue exactly, rather than this… |
|
Honestly, an exhaustive list would be near impossible to put together unless all ports were installed. Also, you get blocked one header at a time, so the ones I've found are: "Archive.h" |
|
Here's the otool -L output for QtWebKit with correctly linked libs for icu leveldb webp libxml2 libxslt zlib sqlite3 libjpeg-turbo: I can't find a link to font-config in the installed files- but it might use one of the font-config installed executables. |
|
That last commit / force push was just to fix a typo in the comments as well as to add the latest qtwebkit ticket to the commit log. Given that last tickets shows the issue occurring on intel, should I remove the if statement? |
|
blocking all of macports' ports from being picked up is most likely going to cause a lot of trouble in the end. Having the headers from who-knows-where linked up to macports libraries will also cause a lot of trouble in the end -- surprising, really, that it works at all now. Presumably ?? the icu headers from the system are being used, but the icu library from macports is being linked?? That just sounds like trouble waiting ... |
I don't believe (but could be wrong) that the macports headers are being blocked. From looking at the build log on my machine, they get added back in, just later in the search path. In regards to your now deleted question - "any guess then as to why this shows up now, 10 years in?" - no clue to the root cause, but more users will see this issue until pre-built packages are available on Ventura. I fear that this has been a hidden issue for some time, just masked by pre-built packages being available. Also - this issue didn't just show up. It's been around for at least over a year. It would be nice to have a solution, even a bandaid solution, get applied until the root cause can fully be understood. Troubleshooting the real issue is beyond my skillset. As always, I am happy to assist getting to the heart of the matter - but will need some help to get there. |
|
@kencu - To your question on if this works. It does. I have been successfully running with this work around for over a year without an issue. Here is a screen shot from an application I built this week that uses qt5-qtwebkit. I picked cnn as the site so as to show "latest" news. Happy to grab a different screenshot from another site.
|
|
Changing to the following seems to allow it to compile. Would this be an acceptable bandaid solution?: |
|
Before it's asked - just adding "configure.cppflags-append "-I${worksrcpath}/include" does not work. Unfortunately the delete and re-add is necessary. |
|
That last series of commits / force pushes added the updated code, removed the arm if statment and synced with the lastest macports master branch which had qt5 commits last night. |
|
Yes, I do think that having the worksrcpath includes come first is a cleaner fix, thanks for thinking of that … maybe there is a clue in worksrcpath as to what headers are conflicting. What we should hope to avoid most is mismatching headers and libraries. This has bitten us many times. |
aqua/qt5/Portfile
Outdated
| # Resolve this by making sure that the qt5-qtwebkit headers are first on the include path | ||
| # https://trac.macports.org/ticket/63877 | ||
| configure.cppflags-delete "-I${prefix}/include" | ||
| configure.cppflags-append "-I${worksrcpath}/include:-I${prefix}/include" |
There was a problem hiding this comment.
I don't think I've ever seen a colon used in this position before... does that work?
clang++ -I/path/to/something:-I/opt/local/include test.cpp
There was a problem hiding this comment.
Nope - that is a mistake. And unfortunately, the compile only worked due to the error. Substituting in a space for the colon does not build
|
I just rolled back to a version with the "delete only lines". The explicit error we keep tripping is this: |
jhoyt4
changed the title
|
I just added another trac ticket to the commit log. So far, I've found 4 separate and related tickets for this issue. |
|
I believe the conflict is coming from the "libevent" port then. qt5-qtwebkit has a header called "Event.h" and libevent has a header "event.h" On the buildbot, Ryan uses a case-sensitive file system, so this error is not seen. There seems to be another similar issue with libarchive, which provides "/${prefix}/include/archive.h". |
|
event.h: conflicts_build-append port:libevent |
|
Is there a way to automatically deactivate / reactivate the conflicting ports or must this always be done manually? |
jhoyt4
changed the title
…r conflicts On case insensitive file systems, the include search path picks up header files from macports before the local header files causing an error while compiling. This modification places flags the known conflicting ports with conflicts_build. Closes: https://trac.macports.org/ticket/63877 Closes: https://trac.macports.org/ticket/62027 Closes: https://trac.macports.org/ticket/66177 Closes: https://trac.macports.org/ticket/63566 [skip ci] fun
|
it can be done automatically, but the admins really frown on it, as it changes installed ports without the user’s approval or knowledge… I feel somewhat better understanding the issue more completely. We have a couple of options to fix this as you noted, but no ideal option. The best option might be to do as you said, prioritize WebKit’s headers. Sometimes the headers in ${prefix} can be prepended to the system header list… I have seen that done successfully. I just built this successfully without having the libevent or libarchive ports installed. As you said, it’s possible some other may turn up. Let’s get this in, and then if I (or you) can come up with something more elegant, we can do that later. Thanks for your patience as I fussed about the real issue… |
|
@kencu - Thank you for hanging in with me on this one. I'm very much learning as I go, and your assistance and guidance has helped a ton. |
On some builds, the include search path picks up header files from macports
and occasionally the system before the local header files causing an error.
This modification places the qt5-qtwebkit header files first on the search path.
Closes: https://trac.macports.org/ticket/63877
Closes: https://trac.macports.org/ticket/62027
Closes: https://trac.macports.org/ticket/66177
Closes: https://trac.macports.org/ticket/63566
[skip ci]
Tested and verified to work with Test Application
Description
Type(s)
Tested on
macOS 13.0.1 22A400 arm64
Xcode 14.1 14B47b
Verification
Have you
port lint --nitpick?sudo port test?sudo port -vst install?