realthunder / FreeCAD

Link branch FreeCAD
Other
763 stars 45 forks source link

[Problem] The appimage format does not start in archlinux. #960

Open yueduz opened 6 months ago

yueduz commented 6 months ago

Is there an existing issue for this?

Version

0.21 (Development)

Full version info

I can't open the About dialog box

Subproject(s) affected?

None

Problem description

$ ./FreeCAD-Link-Stable-Linux-x86_64-py3.11-20240123_9100c2a2943e932102bdd527d5aee0fb.AppImage [20:09:45] Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. /tmp/.mount_FreeCACbthw5 FreeCAD 0.21.0, Libs: 2024.123.0R14555 (Git shallow) MESA-LOADER: failed to open radeonsi: /usr/lib/dri/radeonsi_dri.so: undefined symbol: amdgpu_va_get_start_addr (search paths /usr/lib/dri, suffix _dri) failed to load driver: radeonsi MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: undefined symbol: amdgpu_va_get_start_addr (search paths /usr/lib/dri, suffix _dri) failed to load driver: swrast 0.914828 init_gui.py(14): no solver backend found WebEngineContext used before QtWebEngine::initialize() or OpenGL context creation failed. QGLXContext: Failed to create dummy context Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) /tmp/.mount_FreeCACbthw5/AppRun: 第 52 行: 7028 已中止 (核心已转储)"./$name" "$@"

Anything else?

No response

Code of Conduct

darrellenns commented 6 months ago

I have the same issue here. I found that the appimage contains a bunch of libraries that should not be included, results in this failure due to incompatibility with system libraries. For this particular error, I believe the libdrm* libraries are the culprit.

As per https://docs.appimage.org/introduction/concepts.html:

This doesn’t mean an AppImage must not use resources provided by the system, like for example basic libraries that can be assumed to be part of every target system (e.g., the C standard library or graphics libraries), user interface themes or the like. See the excludelist for a list of the libraries we consider to currently be part of each still-supported target system (distribution).

The excludelist shows that libdrm should be excluded from the appimage. Likewise, things like libstdc++ should be excluded (it currently isn't excluded).

A workaround is to unpack the appimage (run it with --appimage-extract), remove the offending libraries, and the repack it with appimagetool.

yueduz commented 6 months ago

I have the same issue here. I found that the appimage contains a bunch of libraries that should not be included, results in this failure due to incompatibility with system libraries. For this particular error, I believe the libdrm* libraries are the culprit.

As per https://docs.appimage.org/introduction/concepts.html:

This doesn’t mean an AppImage must not use resources provided by the system, like for example basic libraries that can be assumed to be part of every target system (e.g., the C standard library or graphics libraries), user interface themes or the like. See the excludelist for a list of the libraries we consider to currently be part of each still-supported target system (distribution).

The excludelist shows that libdrm should be excluded from the appimage. Likewise, things like libstdc++ should be excluded (it currently isn't excluded).

A workaround is to unpack the appimage (run it with --appimage-extract), remove the offending libraries, and the repack it with appimagetool.

What you said is right. After deleting libdrm*, it can start normally.

jordanfelipe commented 6 months ago

Here is what worked for me. I don't know if it is technically correct, but it seems to work.

  1. Navigate to the folder containing the downloaded AppImage.
  2. Unpack AppImage. (Substitute your AppImage name.)
    1. ./FreeCAD-Link-Stable-Linux-x86_64-py3.11-20240113.AppImage --appimage-extract
  3. Delete all libdrm* files. (Assuming the folder extracted as squashfs-root.)
    1. rm squashfs-root/usr/lib/libdrm*
  4. Pack AppImage without AppStream check. (Output as FreeCAD.AppImage, change as needed.)
    1. NOTE: The appimagetool package is needed for this.
    2. appimagetool -n squashfs-root/ FreeCAD.AppImage
  5. Make FreeCAD.AppImage executable, if necessary.
    1. chmod +x FreeCAD.AppImage
  6. Run AppImage.
    1. ./FreeCAD.AppImage
domcivocato commented 6 months ago

@jordanfelipe Easy, straighforward solution. Works like a charm! Thanks

oerkel47 commented 6 months ago

Yes I have this Problem with Mesa 24. The original FreeCAD daily builds appear to have this fixed btw. So I am hoping for an actual fix here as well.

CobraA1 commented 6 months ago

Manjaro now gets the same problem, and @jordanfelipe 's fix works as well there.

oerkel47 commented 5 months ago

The current appimage did not need the workaround on my setup (Mint 21.3 with Mesa24).

parthvzala commented 4 months ago

@jordanfelipe Thanks a lot! Worked for me. I have intel i5 with intel Arc a770 gpu. First I thought it's Intel GPU that is having issue running FreeCAD due to driver issues.

kzuahelp commented 4 months ago

[code] OS: Arch Linux (XFCE/xfce) Word size of FreeCAD: 64-bit Version: 0.21.2.33771 (Git) AppImage Build type: Release Branch: (HEAD detached at 0.21.2) Hash: b9bfa5c5507506e4515816414cd27f4851d00489 Python 3.10.13, Qt 5.15.8, Coin 4.0.0, Vtk 9.2.6, OCC 7.6.3 Locale: English/United States (en_US) Installed mods:

Problem exists, solution of @jordanfelipe works

bikemike commented 1 month ago

Rebuilding the AppImage also fixed the issue for me in Ubuntu 24.04.