-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build error in Linux for 1.4.0 #302
Comments
Are you sure you are using the mupdf in our repository not not the system's mupdf? |
You're right, it is using the system's |
I don't intend to upgrade to 1.20 for now, but here is a pull request that does that: #294. Maybe you can use this to create a patch for your builds? |
Ok thanks, I'll see what I can do. |
Hi, see #319. |
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? |
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: 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. |
I think I've mentioned this somewhere else before. IMO it would be best to keep up with the latest stable releases of But the situation now is that packagers rely on inofficial patches to support the latest |
I will probably upgrade the mupdf in |
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. |
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.
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.
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. |
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)
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.
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 it does work great on my distribution. In fact I did add this option in build file to use system's mupdf: sioyek/pdf_viewer_build_config.pro Line 85 in 860f93f
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.
Well, if there was no problem, we didn't have to change sioyek for new verisons of mupdf then did we? |
We don't have to, but we prefer to. |
Upgraded to mupdf 1.20.0 in recent commits. |
I'm trying to update the AUR package for Arch Linux, but when I compile sioyek, I get this error:
Any idea why?
The text was updated successfully, but these errors were encountered: