Summary: | www/qt5-webengine: build failure after devel/re2 upgrade | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Jack <xxjack12xx> |
Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> |
Status: | New --- | ||
Severity: | Affects Only Me | CC: | jcfyecrayz, kde, sunpoet, tcberner, xxjack12xx |
Priority: | --- | ||
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any |
Description
Jack
2020-04-09 21:53:37 UTC
Moin moin The issue here seems to be, that the building WebEngine picks up files from the already installed one. The easiest solution here is to follow UPDATING 20190613 and deinstall the pkg before upgrading (or use poudriere). mfg Tobias Assuming removal of the existing qt5-webengine fixed this for the OP, it seems to me there must be a way to tell these qt5 builds to look in WRKDIR before LOCALBASE so we don't repeatedly encounter this problem. See also bug 245614, comment 9 for a similar instance of the same problem. Yes, removal before install fixed the issue. (In reply to Tobias C. Berner from comment #1) Updating qt5-webengine to 5.15.0 from 5.14.2 fails if already installed, too. For example, /usr/local/bin/ld: qquickwebengineview.cpp:(.text+0x4f25): undefined reference to `QtWebEngineCore::WebContentsAdapter::runFeatureRequestCallback(QUrl const&, QtWebEngineCore::ProfileAdapter::PermissionType, bool)' The UPDATING notes that suggest removing the installed port are a bit old and refer to updating from 5.12.2. Maybe a refreshed note in UPDATING is worthwhile. Even better would be to have the build look in the build tree before /usr/local, but I do not have enough qt build understanding to figure out how to make that happen. (In reply to John Hein from comment #4) Moin moin I wrote this in the commit message: * People that use upgrading mechanisms with incomplete dependency handling (portmaster & Co) should make sure to manually remove the existing Qt packages to guarantee a safe upgrade. Keep in mind, that Qt does not like if you have an incomplete upgrade. Arguably, I could also have put it into UPDATING :) mfg Tobias (In reply to Tobias C. Berner from comment #5) Yeah, I guess I was suggesting it might merit an updated UPDATING note. Could you explain what you mean by 'incomplete dependency handling'? |