Created attachment 234219 [details] build logs to failure wo qmake and with qmake.log so during my upgrade from 13.0 to 13.1 amd64 this is the one port that will not build. I've attached my build log. in first case i only have qt5-qmake installed, which this port seems not to recognize but all dependencies are satisfied, so the second case is after i installed qmake as well. it gets a little further but fails. in the first case it cannot find soqt at all due to purported missing qmake, in second case it seems to be calling windows specific python code in setup.py and failing out due to null string s in the code if I'm reading the python correctly. I've attached the build logs in one file annotated for the qmake status. I trimmed after the snake ascii art. I might play around a bit, but python builds are not something i really understand at all. FreeCAD the primary consumer seems to work ok, and loads a quick test of STL files but closes with this console message, which may or may not be related to me still using an old py38-pivy relative to the newer Coin interface, not sure if shiboken uses pivy or not, again may have nothing to do with anything or be an error to function of FreeCAD but for completeness sake. It does seem more related to vtk though. Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/local/lib/python3.8/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 142, in _import return original_import(name, *args, **kwargs) File "/usr/local/FreeCAD/Mod/MeshPart/MeshFlatteningCommand.py", line 5, in <module> import MeshPartGui File "/usr/local/lib/python3.8/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 142, in _import return original_import(name, *args, **kwargs) <class 'ImportError'>: /usr/local/FreeCAD/lib/libSMESH.so: Undefined symbol "_ZN14vtkMeshQuality15QuadAspectRatioEP7vtkCell"
That "missing qmake" is expected (at least it's the same on 13.0 and 12) and should not break the build, mabe there's something else going on? Why do you thing your pivy is "old"? It hasn't changed for over a year. That "<class 'ImportError'>: /usr/local/FreeCAD/lib/libSMESH.so: Undefined symbol "_ZN14vtkMeshQuality15QuadAspectRatioEP7vtkCell" " is indead related to vtk: that's vtkMeshQuality::QuadAspectRatio(vtkCell*) and should be found in libvtkFiltersVerdict-9.1.so (as far as I grok that right now, C++ being C++ etc.) This combination makes me think there might be something wonky on your system.
(In reply to Christoph Moench-Tegeder from comment #1) because it was last built under 13.0, and being a Coin interface, Coin just updated the other day too. wonky is a bit nebulous of a descriptor, short of nuking my ports src tree and re-pulling not sure what else you could mean. I mean 2300 ports re-built fine eventually given the fun of doing that many at one go and it ending up in batches while clearing errors. as far as rebuilds after upgrades this one was pretty smooth going. I tossed a few along the way like gzdoom that i didn't care to figure out but still that has nothing to do with py-pivy. I assume you are saying it builds fine on a live system for you under 13.1 amd64? the only hack i continue to run on my tree is py38-scipy with atlas, and given that was and possibly still is that projects default BLAS library I don't see how that could be doing anything given no dependency to it, and it being in place last year when py-pivy built and installed fine. I don't even keep the hack in the tree, I just use it when needed and reset hard to main.
(In reply to alt2600 from comment #2) > Coin just updated the other day too coin got a bump for depending on libglvnd (ports da3162c7c9) but no changes to itself. > wonky is a bit nebulous of a descriptor Given what I know about your system - ld.so having problems with some part of vtk and a failing build without distinct error message - I just don't have any idea how to be more specific. I do not know what you did and what you did not do to end up in your situation, and I cannot and will not remote-debug that. > I assume you are saying it builds fine on a live system for you under 13.1 amd64? I did not say that. I'm not yet on 13.1 (ENOTIME), and I will never make any statement about building in-system, except for that being generally too messy and too unreliable to make any statements about. (Use poudriere, folks).
(In reply to Christoph Moench-Tegeder from comment #3) thanks for the razzle dazzle explanation of how messed up my machine is. now on to the issue of py-pivy and why it doesn't build Line 10 of qtinfo.py in the workdir needs self._qmake_command = [find_executable("qmake),] needs to be patched thusly and all is well self._qmake_command = [find_executable("qmake-qt5"),] I'd make a patch but i wouldn't want my wonky machine to taint the tree.
We do have successful package builds e.g. on 12.2 and 13.0, just to pick two of them: http://beefy5.nyi.freebsd.org/data/122i386-default/1853d90f79b6/logs/py38-pivy-0.6.6.log http://package21.nyi.freebsd.org/data/130amd64-default-qat/690ee1ef6bb0/logs/py38-pivy-0.6.6.log so I'd rather find out why that breaks on 13.1 and if it fails reproducably or if you're just seing artifacts.
(In reply to Christoph Moench-Tegeder from comment #5) fair enough, but I'm just using the one that built when i hard coded the qt5-qmake. I don't know when the last run of py-pivy is on those servers as the build logs come back as server not found for me, but I know I saw no fallout messages so I'll take them as current. I'd gladly try to rule out artifacts, but looking over the build scripts I cannot understand how the scripts are supposed to know what qmake to use, I just seeing it checking if its in the path, not for a QMAKE variable being set. I see that the variable QMAKE is available to the build, I see setup.py using code to find qt information, and i see qtinfo hard coded to use qmake in its constructor. As far as I can find find_executable only searches the path not environment variables. Is /usr/local/lib/qt5/bin/ supposed to be in the path for the build? I didn't see it being set by qt.mk and its not in the build path when i check make -vPATH . this is me assuming it is supposed to thusly move through setup.py and qtinfo should be able to find qmake somehow. /usr/ports/graphics/py-pivy|$ make -vQMAKE clean /usr/local/lib/qt5/bin/qmake #### setup.py line 231 on if config_dict.get('SOQT_INCLUDE_DIR', 'false') == 'false': pivy_build.MODULES.pop('soqt') print(red("\ndisable soqt, because cmake couldn't find it")) else: try: import qtinfo self.QTINFO = qtinfo.QtInfo() except Exception as e: import traceback print(red("\ndisable soqt, because there was a problem running qtinfo (needs qmake)")) print(red("-" * 60)) print(red(traceback.print_exc())) print(red("-" * 60)) pivy_build.MODULES.pop('soqt') #### qtinfo.py class QtInfo(object): def __init__(self, qmake_command=None): if qmake_command: self._qmake_command = qmake_command else: self._qmake_command = [find_executable("qmake"),] self._dict = {} # bind all variables early at __init__ time. for thing in self.__class__.__dict__: getattr(self, thing)
fixed in https://cgit.freebsd.org/ports/commit/?id=106f25634da3a2156af2a2af171195296f071460 closing as it now builds fine