undefined reference to `pdf_parse_link_uri'

[mil-ad]

I'm getting the error below when building main branch on linux:

pdf_viewer/sqlite3.c: In function ‘sqlite3SelectNew’:
pdf_viewer/sqlite3.c:128048: warning: function may return address of local variable [-Wreturn-local-addr]
128048 |   return pNew;
pdf_viewer/sqlite3.c:128008: note: declared here
128008 |   Select standin;
/usr/bin/ld: /tmp/ccKw8oVk.ltrans4.ltrans.o: in function `DocumentView::get_visible_links(std::vector<std::pair<int, fz_link*>, std::allocator<std::pair<int, fz_link*> > >&)':
/home/milad/Seafile/repos/mil-ad/sioyek-build-src/src/sioyek/pdf_viewer/utils.cpp:122:(.text+0x930b): undefined reference to `pdf_parse_link_uri'
/usr/bin/ld: /tmp/ccKw8oVk.ltrans4.ltrans.o: in function `DocumentView::find_line_definitions()':
/home/milad/Seafile/repos/mil-ad/sioyek-build-src/src/sioyek/pdf_viewer/utils.cpp:122:(.text+0xa569): undefined reference to `pdf_parse_link_uri'
/usr/bin/ld: /tmp/ccKw8oVk.ltrans10.ltrans.o: in function `MainWidget::set_overview_link(PdfLink)':
/home/milad/Seafile/repos/mil-ad/sioyek-build-src/src/sioyek/pdf_viewer/utils.cpp:122:(.text+0xd26): undefined reference to `pdf_parse_link_uri'
/usr/bin/ld: /tmp/ccKw8oVk.ltrans12.ltrans.o: in function `MainWidget::handle_link_click(PdfLink const&)':
/home/milad/Seafile/repos/mil-ad/sioyek-build-src/src/sioyek/pdf_viewer/utils.cpp:122:(.text+0x720a): undefined reference to `pdf_parse_link_uri'
/usr/bin/ld: /tmp/ccKw8oVk.ltrans13.ltrans.o: in function `MainWidget::handle_portal_to_link(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)':
/home/milad/Seafile/repos/mil-ad/sioyek-build-src/src/sioyek/pdf_viewer/utils.cpp:122:(.text+0x2e7): undefined reference to `pdf_parse_link_uri'
/usr/bin/ld: /tmp/ccKw8oVk.ltrans13.ltrans.o:/home/milad/Seafile/repos/mil-ad/sioyek-build-src/src/sioyek/pdf_viewer/utils.cpp:122: more undefined references to `pdf_parse_link_uri' follow
collect2: error: ld returned 1 exit status
make: *** [Makefile:396: sioyek] Error 1

does this ring any bells?

[ahrm]

Yes, this is fixed in the development branch. There is a patch by another user here: https://github.com/ahrm/sioyek/issues/897.

[mil-ad]

I switched to development branch. I can now build fine but when I try to open a PDF I get:

render glyph failed err=62 face=0x5ada6587b770, glyph=51
zsh: segmentation fault (core dumped)  sioyek 

[mil-ad]

It also happens when I try sioyek-git package in Arch's AUR.

[mil-ad]

(I'd stick with the .appimage but the latest release is 18 months old)

[ahrm]

Can you backup your shared.db and local.db to another location and see if the crash happens these files are deleted?

[mil-ad]

I deleted both files and still get the same error 🤔

[ahrm]

Does this happen with all pdf files? You may also want to remove last_document_path.txt file.

[ahrm]

Another thing is that we use qt 6.7 on the development branch (as opposed to 5.* in the main branch).

[mil-ad]

Does this happen with all pdf files?

Yes it happens with all PDFs.

You may also want to remove last_document_path.txt file.

Made no difference

Another thing is that we use qt 6.7 on the development branch (as opposed to 5.* in the main branch). Yes I'm using qmake6 and qt versions below. Although I noticed the README instructions on development branch still says qt5 for linux, we need to update that at some point.

qt6-3d 6.7.0-1
qt6-5compat 6.7.0-1
qt6-base 6.7.0-6
qt6-declarative 6.7.0-1
qt6-imageformats 6.7.0-1
qt6-multimedia 6.7.0-1
qt6-multimedia-ffmpeg 6.7.0-1
qt6-positioning 6.7.0-2
qt6-shadertools 6.7.0-1
qt6-speech 6.7.0-1
qt6-svg 6.7.0-1
qt6-tools 6.7.0-2
qt6-translations 6.7.0-1
qt6-wayland 6.7.0-1
qt6-webchannel 6.7.0-1
qt6-webengine 6.7.0-1
qt6ct 0.9-7

[ahrm]

Hmmm did you build sioyek yourself or are you using some prebuilt package? If you built it yourself you may want to build it in debug mode and see what the stack trace is?

[mil-ad]

I'm building it myself. Do I just add CONFIG+=debug to the build command?

(thanks for all the help btw 🫡)

[ahrm]

Yes, I think that should do it. yw :) .

[mil-ad]

I'm not 100% sure I did the debug build correctly but I'm now getting this:

cannot create context: incompatible header (1.22.0) and library (1.24.2) versions
could not create mupdf context

[ahrm]

Ahh, I think you are building against your system's mupdf but using the mupdf headers included in sioyek repo. You can either use your system's headers files (probably removing this line should do it: https://github.com/ahrm/sioyek/blob/b312fe0b7ae4b8125febef4467480367e0030665/pdf_viewer_build_config.pro#L6). Or use the mupdf included with sioyek (the linux_app_image config option does that, see here: https://github.com/ahrm/sioyek/blob/b312fe0b7ae4b8125febef4467480367e0030665/pdf_viewer_build_config.pro#L160).

(You may also want to define LINUX_STANDARD_PATHS with linux_app_image config which uses more standard linux path and is the default for non-appimage sioyek packages).

[mil-ad]

ah that's strange. I thought I was using the mupdf in the repo.

this is my build step:

build() {
    cd "sioyek/mupdf"
    make USE_SYSTEM_HARFBUZZ=yes
    cd ..

    qmake6 CONFIG+=linux_app_image pdf_viewer_build_config.pro
    make
}

and I have also borrowed a patch file sioyek-git in the AUR that does this:

diff --git a/pdf_viewer_build_config.pro b/pdf_viewer_build_config.pro
index a09b861..0154e5d 100644
--- a/pdf_viewer_build_config.pro
+++ b/pdf_viewer_build_config.pro
@@ -88,7 +88,8 @@ unix:!mac {
     QMAKE_CXXFLAGS += -std=c++17

     CONFIG(linux_app_image){
-        LIBS += -ldl -Lmupdf/build/release -lmupdf -lmupdf-third -lmupdf-threads -lharfbuzz -lz
+        DEFINES += LINUX_STANDARD_PATHS
+        LIBS += -ldl -lmupdf -lz
     } else {
         DEFINES += NON_PORTABLE
         DEFINES += LINUX_STANDARD_PATHS

[ahrm]

Yeah the patch uses the system's mupdf (by removing -Lmupdf/build/release).

[mil-ad]

aaah! Let me try again! Thanks!

[mil-ad]

that worked and turns out you were right; it's my database after all 😵‍💫

[ahrm]

If your database doesn't contain private information, you can mail it to me and I can see what is wrong, otherwise maybe the stack trace gives a clue?