Free books download after loading kill the program about librum HOT 17 CLOSED

Hey, this is a known issue and will be fixed in the next update. It is due to a jpeg library version mismatch.

from librum.

It crashes for me on a self-built version of Librum as well, with the following jpeg libraries reported by the coredump:

Module libjpeg.so.62 from rpm libjpeg-turbo-2.1.4-3.fc39.x86_64
Module libqjpeg.so from rpm qt6-qtbase-6.6.0-2.fc39.x86_64

The stacktrace itself is not very informative:

Stack trace of thread 945247:
#0 0x00007fc04cf40d8e ____longjmp_chk (libc.so.6 + 0x122d8e)
#1 0x69746ba155eccb48 n/a (n/a + 0x0)

This is using current main, built from ff08ad2

Could you try if adding:

set(ENV{USE_SYSTEM_LIBJPEG} yes)

To line 102 of src/application/CMakeLists.txt fixes your problem?

I tried the suggestion above as well as the mupdf patch above that, none of those helped on my end.

Ok, this was a mistake on my end. Setting environment variables as I did before seems to only set them for the cmake configuration step, not for the build step. My latest commit should now finally fix the issue (at least it seems to do so on my PC).

It would be great if someone could confirm this, since I will publish a new version tomorrow and it would be great to know if this fully fixes the error for everyone.

from librum.

I have the same. Segmentation fault...(

from librum.

We are waiting for flatpak to make Qt 6.6 available since this is supposed to fix the jpeg library version missmatch

from librum.

I thought the bug is fixed, because for now in version 0.10.0 I have no crash, everything works fine. But I use all system libraries when build Mupdf . I build client with qt6.4 , but I don't think it really important.

from librum.

So it works fine for your self-build version? What about the one you get via flatpak?, the issue still exists there afaik.

from librum.

Sorry i didn't even try to get it with flatpack) I had a program crash (by segmentation fault) on v0.9.2 self-builded, but now with new release - everything is fine with free books.

from librum.

Ah I understand. Yeah, self-building is a different environment than flatpak. Selfbuilding it works fine for me as well, but with flatpak, Qt gets confused about what jpeg library to choose, since one of Librum's dependencies (mupdf) comes with a different version of libjpeg

from librum.

It crashes for me on a self-built version of Librum as well, with the following jpeg libraries reported by the coredump:

Module libjpeg.so.62 from rpm libjpeg-turbo-2.1.4-3.fc39.x86_64
Module libqjpeg.so from rpm qt6-qtbase-6.6.0-2.fc39.x86_64

The stacktrace itself is not very informative:

Stack trace of thread 945247:
#0 0x00007fc04cf40d8e ____longjmp_chk (libc.so.6 + 0x122d8e)
#1 0x69746ba155eccb48 n/a (n/a + 0x0)

This is using current main, built from ff08ad2

from librum.

It crashes for me on a self-built version of Librum as well, with the following jpeg libraries reported by the coredump:

Module libjpeg.so.62 from rpm libjpeg-turbo-2.1.4-3.fc39.x86_64
Module libqjpeg.so from rpm qt6-qtbase-6.6.0-2.fc39.x86_64

The stacktrace itself is not very informative:

Stack trace of thread 945247:
#0 0x00007fc04cf40d8e ____longjmp_chk (libc.so.6 + 0x122d8e)
#1 0x69746ba155eccb48 n/a (n/a + 0x0)

This is using current main, built from ff08ad2

Thanks for confirming it. Its the same I get.

The problem arises due to the fact that one of our dependencies builds libjpeg from source (mupdf) and the linker gets confused on which version to use, the self-built one or the one provided by the system.

If the error persists even though you built it yourself with Qt 6.6 it most probably isn't flatpak specific.
I'll look for a solution to this.

from librum.

our dependencies builds libjpeg

Maybe it will help somebody...
I'll give a tip - when i force mupdf to use linux system libraries including libjpeg, everything works fine.
More details: extract , rapidfuzz and mujs are builded from source, other libraries are skipped, system libs are used.

from librum.

our dependencies builds libjpeg

Maybe it will help somebody... I'll give a tip - when i force mupdf to use linux system libraries including libjpeg, everything works fine. More details: extract , rapidfuzz and mujs are builded from source, other libraries are skipped, system libs are used.

How do you force mupdf to use libjpeg and not build it from source?

from librum.

How do you force mupdf to use libjpeg and not build it from source?

I patch libs/mupdf/scripts/wrap/main.py.

-    make_args = ' HAVE_GLUT=no HAVE_PTHREAD=yes verbose=yes'
+    make_args = '  USE_SYSTEM_LIBS=yes USE_SYSTEM_LIBJPEG=yes USE_SYSTEM_OPENJPEG=yes USE_SYSTEM_GUMBO=yes USE_SYSTEM_MUJS=no USE_SYSTEM_FREETYPE=yes USE_SYSTEM_HARFBUZZ=yes USE_SYSTEM_ZLIB=yes  USE_SYSTEM_JBIG2DEC=yes  USE_SYSTEM_LCMS2=yes USE_SYSTEM_LEPTONICA=yes USE_SYSTEM_TESSERACT=yes USE_SYSTEM_CURL=yes USE_SYSTEM_GLUT=yes HAVE_GLUT=no HAVE_PTHREAD=yes verbose=yes  '

from librum.

It crashes for me on a self-built version of Librum as well, with the following jpeg libraries reported by the coredump:

Module libjpeg.so.62 from rpm libjpeg-turbo-2.1.4-3.fc39.x86_64
Module libqjpeg.so from rpm qt6-qtbase-6.6.0-2.fc39.x86_64

The stacktrace itself is not very informative:

Stack trace of thread 945247:
#0 0x00007fc04cf40d8e ____longjmp_chk (libc.so.6 + 0x122d8e)
#1 0x69746ba155eccb48 n/a (n/a + 0x0)

This is using current main, built from ff08ad2

Could you try if adding:

set(ENV{USE_SYSTEM_LIBJPEG} yes)

To line 102 of src/application/CMakeLists.txt fixes your problem?

from librum.

It crashes for me on a self-built version of Librum as well, with the following jpeg libraries reported by the coredump:

Module libjpeg.so.62 from rpm libjpeg-turbo-2.1.4-3.fc39.x86_64
Module libqjpeg.so from rpm qt6-qtbase-6.6.0-2.fc39.x86_64

The stacktrace itself is not very informative:

Stack trace of thread 945247:
#0 0x00007fc04cf40d8e ____longjmp_chk (libc.so.6 + 0x122d8e)
#1 0x69746ba155eccb48 n/a (n/a + 0x0)

This is using current main, built from ff08ad2

Could you try if adding:

set(ENV{USE_SYSTEM_LIBJPEG} yes)

To line 102 of src/application/CMakeLists.txt fixes your problem?

I tried the suggestion above as well as the mupdf patch above that, none of those helped on my end.

from librum.

It crashes for me on a self-built version of Librum as well, with the following jpeg libraries reported by the coredump:

Module libjpeg.so.62 from rpm libjpeg-turbo-2.1.4-3.fc39.x86_64
Module libqjpeg.so from rpm qt6-qtbase-6.6.0-2.fc39.x86_64

The stacktrace itself is not very informative:

Stack trace of thread 945247:
#0 0x00007fc04cf40d8e ____longjmp_chk (libc.so.6 + 0x122d8e)
#1 0x69746ba155eccb48 n/a (n/a + 0x0)

This is using current main, built from ff08ad2

Could you try if adding:

set(ENV{USE_SYSTEM_LIBJPEG} yes)

To line 102 of src/application/CMakeLists.txt fixes your problem?

I tried the suggestion above as well as the mupdf patch above that, none of those helped on my end.

Have you deleted the /libs/mupdf/build folder before rebuilding with the new environment variable?

from librum.

The latest release of Librum fixed this.

from librum.