jes notes Index Gallery . Shaft passers Snap issues

2025-02-15

Last modified: 2025-02-18 17:48:37

< 2025-02-14 2025-02-18 >

FreeCAD

My next idea is to make a distrobox of Ubuntu and see if the libraries in that one are more favourable.

$ distrobox create --image ubuntu:latest ubuntu-distrobox

OK, well after several rounds of cmake .., apt install, etc., it eventually built, but lots of:

libshiboken2.abi3.so.5.13: cannot open shared object file: No such file or directory

I installed libshiboken2-dev, make clean, make -j10.

No different. Clear out build and cmake .. again?

A few more ideas for things to contribute:

Ugh, even after cmake .. and rebuilding, same error, even though I've installed it now.

I tried:

$ ln -s /usr/lib/x86_64-linux-gnu/libshiboken2.cpython-312-x86_64-linux-gnu.so /usr/lib/x86_64-linux-gnu/libshiboken2.abi3.so.5.13

But then I got:

During initialization the error "/home/jes/.local/lib/python3.12/site-packages/PySide2/Qt/lib/libQt5Qml.so.5: undefined symbol: _ZN14QMetaCallEventC1EttPFvP7QObjectN11QMetaObject4CallEiPPvEPKS0_iiPiS5_P10QSemaphore, version Qt_5_PRIVATE_API" occurred in /home/jes/projects/freecad-source/build/Mod/AddonManager/InitGui.py

Very frustrating. I'm stuck again.

I pasted all of my notes into ChatGPT to see if it had any good ideas, but it didn't.

OK, made some progress! The issue is that I forgot that my home dir is shared between the host and the distrobox, so the distrobox is not a clean environment like I expected.

This is the file that is trying to load the bad shiboken file:

/home/jes/.local/lib/python3.12/site-packages/PySide2/QtCore.abi3.so

After rm -rf ~/.local/lib/python3.12/:

$ bin/FreeCAD
bin/FreeCAD: error while loading shared libraries: libCoin.so.80c: cannot open shared object file: No such file or directory

I guess maybe try cmake from scratch again? Oh, oops, I was trying to launch it from my main host system, not the ubuntu distrobox. But I already deleted the contents of build, so I get to sit and wait for it to recompile anyway.

Woo, looks like it's working.

Aargh. Not working.

$ bin/FreeCAD
FreeCAD 1.1.0, Libs: 1.1.0devRUnknown
(C) 2001-2025 FreeCAD contributors
FreeCAD is free and open-source software licensed under the terms of LGPL2+ license.

Gtk-Message: 11:37:09.891: Failed to load module "canberra-gtk-module"
Gtk-Message: 11:37:09.891: Failed to load module "canberra-gtk-module"
_IceTransSocketUNIXConnect: Cannot connect to non-local host longjohn
_IceTransSocketUNIXConnect: Cannot connect to non-local host longjohn
Qt: Session management error: Could not open network socket
Could not import QtNetwork -- it does not appear to be installed on your system. Your provider may have a package for this dependency (often called "python3-pyside2.qtnetwork")
Wizard shaft module cannot be loaded
failed to create drawable

The start screen loads as normal, but "failed to create drawable" appears as soon as I try to create a new file.

python3-pyside2.qtnetwork indeed wasn't installed, let's try that.

Now we're getting

_IceTransSocketUNIXConnect: Cannot connect to non-local host longjohn
Qt: Session management error: Could not open network socket

And still "failed to create drawable", but no more message about not being able to import QtNetwork.

I'm guessing these issues are caused by trying to run it inside distrobox. I tried to launch the binary outside distrobox but it doesn't have all the libraries it needs.

Installing mesa-utils hasn't helped. Running with LIBGL_ALWAYS_SOFTWARE=1 hasn't helped, and running with QT_QPA_PLATFORM=xcb hasn't helped. (All suggested by ChatGPT).

So then:

The obvious thing that happens when you start a new project is you need a 3d view, so it engages OpenGL. But then you'd think the software renderer would work?

glxgears works.

And the qopenglwidget example program appears to work even though it prints "failed to create drawable". Maybe "failed to create drawable" is a total red herring. I'm going to try to get Cursor to find the code that launches the 3d view and see if I can put in some printf debugging.

You can do debugging with:

Base::Console().Message("[jes] Application::newDocument entry\n");

Adding a line like that to newDocument() in src/App/Application.cpp leads to a make -j10 that takes 62 seconds. Getting this working is not going to be quick.

And even so, I don't know what I'm looking for. If the working hypothesis is that something is just not drawing when it should be, how will I find out what that thing is?

I think we have to hold on to hope that "failed to create drawable" is proximate to the broken component, and work out what that component is and why it might be broken.

I've tracked it down to something after Application's signalNewDocument is fired.

I instrumented every slot that connects to that signal with logging, which says:

...
[jes] TreeWidget::slotNewDocument exit
failed to create drawable
[jes] AutoSaver::slotCreateDocument entry
...

So... I guess I missed one?

Well I've tracked it down to view->show() in the !isEmpty case in MainWindow::addWindow(). I think view is an MDIView, which just inherits from QMainWindow.

Meh, can't see what I can do from here.

Changing tack: can I static-link the binary and then run it from outside distrobox?

Or alternatively can I copy out all of the required .so files?

I should make a little script that does this. You pass it a binary, it runs ldd to work out all the required .so files, and then copies them all into a self-extracting executable, like an AppImage but worse.

I got ChatGPT to make me the script. I'm guessing it won't work on FreeCAD because of stuff loaded at runtime with openat().

https://gist.github.com/jes/543669252b2951e961614e2f2a873b22

Indeed it doesn't work for FreeCAD because all the modules are loaded at runtime.

Maybe if we make the script take arguments listing extra libs. Meh, still too much trouble.

Some progress though. With:

$ ./make-lame-appimage.sh bin/FreeCAD lib Mod src data _deps Ext share

in the build/ directory, I get a FreeCAD.run that I can run inside the distrobox and it works the same as the real one, and I can run it outside the distrobox and it loads all the way up but some of the UI is missing because of Python stuff. However I can create a new document and it does appear and it doesn't say "failed to create drawable".

So I think I can pretty safely conclude that the issue with the "drawable" is a distrobox problem.

So a couple of things here:

  1. the lame appimage script should take a list of paths from your system and then somehow create a self-extracting script that bind-mounts those paths into the binary's environment
  2. maybe recreate the distrobox but with ChatGPT's method of GPU pass-through?

I did get Cursor to do a first pass of bind-mounting your paths etc. but it didn't work and it looked fragile with having loads of code to manually unmount them at the end etc.

Distrobox with GPU:

$ distrobox create --name ubuntu-gpu --image ubuntu:latest --nvidia

That did the trick!!

Finally. I have a working FreeCAD compiled from source. Great success.

< 2025-02-14 2025-02-18 >