Build error in Linux for 1.4.0

[goggle]

I'm trying to update the AUR package for Arch Linux, but when I compile sioyek, I get this error:

pdf_viewer/document.cpp:552:52: error: cannot convert ‘fz_location’ to ‘int’ in assignment
  552 |                         current_node->page = root->page;
      |                                              ~~~~~~^~~~
      |                                                    |
      |                                                    fz_location
pdf_viewer/document.cpp: In member function ‘std::optional<std::pair<std::__cxx11::basic_string<wchar_t>, std::__cxx11::basic_string<wchar_t> > > Document::get_generic_link_name_at_position(const std::vector<fz_stext_char*>&, float, float)’:
pdf_viewer/document.cpp:1211:27: warning: unknown escape sequence: '\.'
 1211 |         std::wregex regex(L"[a-zA-Z]{3,}(\.){0,1}[ \t]+[0-9]+(\.[0-9]+)*");
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pdf_viewer/document.cpp:1211:27: warning: unknown escape sequence: '\.'
make: *** [Makefile:966: document.o] Error 1
cp: cannot stat 'sioyek': No such file or directory
==> Entering fakeroot environment...
==> Starting package()...
install: cannot stat './build/sioyek': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...

Any idea why?

[ahrm]

Are you sure you are using the mupdf in our repository not not the system's mupdf? If you insist on using the system's mupdf you should make sure that it is the correct version of mupdf (1.19).

[goggle]

You're right, it is using the system's mupdf which is at version 1.20. Any chance to get the code compiling with that?

[ahrm]

I don't intend to upgrade to 1.20 for now, but here is a pull request that does that: https://github.com/ahrm/sioyek/pull/294. Maybe you can use this to create a patch for your builds?

[goggle]

Ok thanks, I'll see what I can do.

[DhruvaSambrani]

Hi, see #319. As a temporary alternative, you can use https://aur.archlinux.org/packages/sioyek-appimage

[NickCao]

Hit by the same issue here in nixpkgs: https://hydra.nixos.org/build/187798391, what's blocking us from supporting the latest stable version of mupdf?

[ahrm]

I don't want distributions to dictate when it is time for me to update my libraries (especially since there are many distributions with conflicting versions of libraries). There is a patch here that upgrades to 1.20 maybe you could use that: https://github.com/ahrm/sioyek/pull/294.

But I recommend just doing what we do to build the appimages in this script: https://github.com/ahrm/sioyek/blob/main/build_and_release.sh. Which is to build the required version of mupdf ourselves.

[goggle]

I think I've mentioned this somewhere else before.

IMO it would be best to keep up with the latest stable releases of mupdf (there are usually 1-2 releases per year). Why? Many distributions will have the latest stable release of mupdf in their repositories. It is then easy to package the latest sioyek that uses the systems mupdf. If the distribution doesn't have the latest mupdf in their repositories, packagers can go through the sioyek commit history and revert the mupdf-related changes to support an older version of mupdf.

But the situation now is that packagers rely on inofficial patches to support the latest mupdf. This is not optimal because it can introduce bugs and unexpected behavior...

[ahrm]

I will probably upgrade the mupdf in sioyek 2.0 release. However, what I don't understand is why don't linux packager's simply use the mupdf included in the repository and avoid all this trouble?

[NickCao]

If every project include a specific version of mupdf inside their repo, that would mean compiling mupdf for thousands of times, and when these projects are linked together, symbol collisions and other strange things will happen. In general, as packagers, we perfer to have no more than one version of the same software in our distributions (major versions aside, as they have different sonames thus won't be a problem). As for developers, it may be tempting to vendor your own dependencies, but actually it forces you to integrate their build process into yours, leaving much more trouble to yourself. I appreciate your efforts to make packaging easier by vendoring mupdf, but that's sadly, not how linux distributions work.

[ahrm]

and when these projects are linked together, symbol collisions and other strange things will happen

Out of the 3 platforms that run sioyek (windows, mac and linux). The only time that I have had to deal with symbol collisions was on the linux builds. So whatever solution linux distributions have for avoiding name collisions, they have failed spectacularly. In fact, originally we did use the mupdf bundled with the distribution and the reason we had to switch to building mupdf ourself was name collisions (the libharfbuzz of qt5 and mupdf included with ubuntu collided with each other so we had to build mupdf ourselves).

forces you to integrate their build process into yours, leaving much more trouble to yourself.

I take integrating build processed into my workflow any day of the week over the nightmare that is linux's fragmented package distributions and conflicting versions.

not how linux distributions work.

Well they have to do something about that. If distributions are going to demand that softwares use only their libraries, they better have a method of distributing multiple versions of libraries and linking against specific versions. Asking people to always use the single version provided by distribution is simply idiotic.

[NickCao]

Out of the 3 platforms that run sioyek (windows, mac and linux). The only time that I have had to deal with symbol collisions was on the linux builds.

The reason behind this is crystal clear, people has long grew the habit of bundling dependencies on windows and mac, no sharing, no collision, that is a possible solution, especially for proprietary softwares, however for open source softwares, sharing dependencies means less disk space consumption and easier security upgrades, for example if there's a new vulnerability in zlib, we don't have to wait you and all other developers to release new versions. The debate for whether to bundle dependencies, or whether to dynamic link or static link has been around for decades, I'm not here to keep the flame on, but I do believe sharing is the way to go. (I have no idea about the ubuntu story though, sounds like packaging issue)

I take integrating build processed into my workflow any day of the week over the nightmare that is linux's fragmented package distributions and conflicting versions.

Or you can just step aside and leave the job to us packagers, just make sure your great software works greatly on your preferred distribution, and we are more than willing to take care of the rest.

Asking people to always use the single version provided by distribution is simply idiotic.

Actually for softwares following semantic versioning. these version bumps are unlikely to cause issues, and all distributions have one way or another to ship multiple major versions of the same library from day one, just not applied to minor versions.

[ahrm]

Or you can just step aside and leave the job to us packagers, just make sure your great software works greatly on your preferred distribution, and we are more than willing to take care of the rest.

Well it does work great on my distribution. In fact I did add this option in build file to use system's mupdf: https://github.com/ahrm/sioyek/blob/860f93f4a5fcad6fb8e184499874f034a6b86807/pdf_viewer_build_config.pro#L85 I did this to help package maintainers. However, asking me to maintain multiple versions of sioyek source code to make distributions happy is simply too much.

Actually for softwares following semantic versioning. these version bumps are unlikely to cause issues, and all distributions have one way or another to ship multiple major versions of the same library from day one, just not applied to minor versions.

Well, if there was no problem, we didn't have to change sioyek for new verisons of mupdf then did we?

[NickCao]

We don't have to, but we prefer to.

[ahrm]

Upgraded to mupdf 1.20.0 in recent commits.