qt5-core not building

[Tobias C. Berner]

Moin moin 

You can do something like 

 find /usr/local/lib/qt5 -type f | xargs pkg which -o | grep 'was not found in 
the database' 

to find other stray files -- note, not everything that appears might be "bad".


mfg Tobias

Am Sonntag, 28. Oktober 2018, 15:45:34 CET schrieb Andrew Hamilton-Wright:
> Thank-you for your help.  Your information allowed me to construct a
> resolution.
 
> The information to answer your queries is the following:
> 
> # pwd
> /usr/ports/devel/qt5-buildtools
> # make -V QT5_VERSION
> 5.11.2
> 
> # pkg info qt5-buildtools
> pkg: No package(s) matching qt5-buildtools
> 
> # pkg info qt5-qmake
> pkg: No package(s) matching qt5-qmake
> 
> # pkg which /usr/local/lib/qt5/mkspecs/modules/qt_lib_bootstrap_private.pri
> /usr/local/lib/qt5/mkspecs/modules/qt_lib_bootstrap_private.pri was not
> found in the database 
> # cat /tmp/qt_lib_bootstrap_private.pri 
> QT.bootstrap_private.VERSION = 5.9.4
> QT.bootstrap_private.name = QtBootstrap
> QT.bootstrap_private.module = Qt5Bootstrap
> QT.bootstrap_private.libs = $$QT_MODULE_HOST_LIB_BASE
> QT.bootstrap_private.includes = $$QT_MODULE_INCLUDE_BASE
> $$QT_MODULE_INCLUDE_BASE/QtCore $$QT_MODULE_INCLUDE_BASE/QtCore/5.9.4
> $$QT_MODULE_INCLUDE_BASE/QtCore/5.9.4/QtCore $$QT_MODULE_INCLUDE_BASE/QtXml
> $$QT_MODULE_INCLUDE_BASE/QtXml/5.9.4
> $$QT_MODULE_INCLUDE_BASE/QtXml/5.9.4/QtXml
 QT.bootstrap_private.frameworks
> =
> QT.bootstrap_private.depends =
> QT.bootstrap_private.uses =
> QT.bootstrap_private.module_config = v2 staticlib internal_module
> QT.bootstrap_private.DEFINES = QT_BOOTSTRAP_LIB QT_VERSION_STR=\'\"5.9.4\"\'
> QT_VERSION_MAJOR=5 QT_VERSION_MINOR=9 QT_VERSION_PATCH=4 QT_BOOTSTRAPPED
> QT_NO_CAST_TO_ASCII
 QT.bootstrap_private.enabled_features =
> QT.bootstrap_private.disabled_features =
> QT_CONFIG +=
> QT_MODULES += bootstrap
> 
> 
> I was able to resolve my problem by doing the following:
> - rm /usr/local/lib/qt5/mkspecs/modules/qt_lib_bootstrap_private.pri
> - pkg delete qtchooser-66
> 	(This was causing some type of conflict when qmake was being rebuilt,
> however I had tried building qmake with the top-level port, not the
> qt5-qmake port, so I don't know whether this was required)
 - cd
> /usr/ports/devel/qt5-qmake && make clean && make && make install (I
> originally tried to build qt5-buildtools, and allow it to rebuild qmake,
> but it didn't figure out that it needed to do so, which I find very
> interesting.  The qt5-buildtools port then failed with exactly the same
> type of error that qt5-core failed with in my initial message.) - cd
> /usr/ports/deve/qt5-buildtools && make clean && make && make install (This
> now works, after having manually built qmake -- and the make clean calls
> for a deletion and rebuild of qmake now, so something is clearly off here.)
> - cd /usr/ports/devel/qt5-core && make clean && make && make install (This
> now works.)
> 
> 
> So -- not completely sure what had happened, and I would still love a
> pointer to how to find all of the QT related files so that I can do a
> filetime analysis to see if there is anything old that might still be left
> over, but it seems that it is working now.
 
> Thanks,
> Andrew.
> 
> 
> 
> On 2018-10-27, 4:20 AM, "Schaich Alonso" <alonsoschaich at fastmail.fm>
> wrote:
 
>     On Fri, 26 Oct 2018 20:37:24 +0000
>     Andrew Hamilton-Wright <andrew.hamilton-wright at uoguelph.ca> wrote:
>     
> 
>     > 
>     > As it happens, I do use synth for port management.  That does not
>     > solve the problem.  In fact, it was problems in synth build that let
>     > me to look into this issue in the first place.
 
>     > What is clear to me is that the port installation of qt5 as it exists
>     > on my machine is broken, as it cannot be built from the port itself,
>     > which is, I note the recommended way of doing things as described in
>     > the FreeBSD manual.
 
>     > The machine is up to date.  When building, I see the 5.11.2 version
>     > number for QT being reported at multiple points, however the build
>     > itself is getting the old version information from somewhere.
 
>     > Where are these “hidden” data pieces stored?  It would be helpful to
>     > know where the clearly incorrect version numbering is coming from.
 
>     > If, to do this, I do need to completely remove QT, a pointer to some
>     > instructions on how to do that would be helpful.  It does not seem to
>     > simply be the case that either port based “make deinstall” or package
>     > based delete has any effect on the problem.  Wherever the corruption
>     > is, it is not touched by these methods.
 
>     > Is there a clear statement somewhere about where this information is
>     > stored?  Or additionally how to ensure that the entirety of QT is
>     > removed in order that it can be reinstalled from scratch?
 
>     > Best regards,
>     > AHW
>     > 
> 
>     
>     Hi
>     
>     The Qt version macros are set by qmake's makespec files, namely
>     
> 
>     > /usr/local/lib/qt5/mkspecs/modules/qt_lib_bootstrap_private.pri
> 
>     
>     which is installed as part of the qt5-buildtools package these days, but
> it might have been installed by qt5-qmake on historic ports.
 
>     A possible scenario would be having Qt-5.9.4's qt5-buildtools package
> installed while trying to compile Qt-5.11.2 packages that _should_ depend
> on qt5-buildtools (potentially indirectly by depending on other ports that
> depend on it) in order to prevent the old buildtools to be installed at the
> point a non-buildsystem Qt port is compiled.
 
>     
>     
>     Can you check
>     
> 
>     > make -V QT5_VERSION
> 
>     
>     in the devel/qt5-buildtools subdirectory of your ports repository prints
> 5.11.2, and
 
> 
>     > pkg info qt5-buildtools
> 
>     
>     confirms the package system "thinks" 5.11.2 is installed?
>     
>     
>     
>     Another potential scenario would be having attempted to perform a manual
> update, i.e. using "make" rather than some ports-management tool
> (portmaster and the likes), and having forgotten to run "make clean" before
> updating the ports tree. AFAIK, ports would reinstall the already built
> content of the stagedir because it has "learned" that "make build" / "make
> stage" has already sucessfully completed before the ports tree was updated
> and still has this "knowledge" after the update.
 
>     
>     
>     Alonso
>     
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20181028/a5a1878b/attachment.sig>