New beta testers, new headaches - libunwind.
Since Xojo-built apps require libunwind, would it make sense to include the libunwind-1.2.2 within our app’s “Libs” folder? A lot of users seem to be moving to Fedora 28 and 29 for some reason and libunwind isn’t installed by default. This also seems the case on SuSE Linux Desktop and Server as well.
What I do is have a Linux .deb installer that checks for that dependency and just installs libunwind (and 3 other packages) as part of the install process if they’re not already installed. I’ve been using it internally for a while and relatively happy with it. It’s a port of the Debreate project into Xojo code and I’ve made it a bit friendlier for Xojo developers. You can PM if you’d like to take a look at it.
That is discouraged by linux.
What xojo have to do, is to find a way to display an error msgbox “libunwind not found, please install in order to run this app”
libunwind is a dependency of the app, so the app won’t run… If the app won’t run, how do you expect the app to display a msgbox?
Keep in mind, that on macOS and Windows, whenever you see a dialog saying that an app can’t launch because of a missing dependency, it’s the OS itself that is telling you that, not the app that you just launched. If Linux doesn’t do that and you think that it should, you ought to talk to the Linux OS vendors themselves.
[quote=404195:@Pedro Ivan Tellez Corella]That is discouraged by linux.
What xojo have to do, is to find a way to display an error msgbox “libunwind not found, please install in order to run this app”[/quote]
Pedro - do you sell commercial software to Fortune 500 clients, or are you simply a Linux “user”? There is a very large difference between the two classifications of Linux users. What is “discouraged” and what works are two different things. I and our customers don’t give two hoots about open source rhetoric and simply want an application that runs when installed.
If we can FUNCTIONALLY include libunwind-1.2.2.so in the app’s Libs folder - the problem is resolved.
That may be the result except we need to support both dpkg and rpm standards and maintaining 2 spec formats is a PITA. Combine that with “alien” only mostly working and I’m thinking of an installer script like we used back in the olden days of real Unix computing.
The problem with that is that if a bug fix is released for libunwind, the clients don’t automatically get that.
Besides the fact that there’s no way for us to know at compile time what version you’re going to need. libunwind-1.2.2 is a minimum version, but if 1.2.5 was already on the machine, you’d really want to use that version instead.
[quote=404199:@Greg O’Lone]The problem with that is that if a bug fix is released for libunwind, the clients don’t automatically get that.
Besides the fact that there’s no way for us to know at compile time what version you’re going to need. libunwind-1.2.2 is a minimum version, but if 1.2.5 was already on the machine, you’d really want to use that version instead.[/quote]
Not necessarily - since I built against 1.2.2, I want to run against 1.2.2. If 1.2.5 FUBARs my app because of a change, the customer’s screwed and it turns into one more support call that we shouldn’t have to deal with.
Believe me, in building commercial apps for Linux since 0.99pl12 in 1993 (BRU was the first commercially available application for Linux), and Unix in general since 1982, I’ve heard all of the pro and con arguments (and a few that seem to argue both sides) concerning library versions and local versus system versus static and I’m now at the same point as our customers - I don’t care. I just want the app to run.
This is why our non-Xojo apps are compiled as static for Unix in addition to a dynamic version. When our solutions are installed on non-Mac OS Unix platforms, the user doesn’t need to play the dependency games. But, if they are concerned about updated libraries, they can use the dynamic build and submit an update request for their platform (which we’re probably already working on).
As an aside - there’s a very old fogbugz request in the system for Xojo to allow static compiles - <https://xojo.com/issue/1464> - that I submitted and garnered 13 votes. It was an issue back then, and it’s still an issue today.
Interesting discoveries -
It seems that Xojo apps don’t respect the LD_LIBRARY_PATH env variable or recognize that the ldconfig cache has changed.
Also, a Xojo Linux app does include a system library - libc++.so.1. This seems to be a bit of a double standard.
@Tim Jones & @Bob Keeney Have either of you tried either AppImage or Snap formats for distributing apps for Linux?
Snap support is pretty widespread in Linux distributions these days, but I can see that in a locked down environment it might not be tenable if support isn’t installed.
However, AppImage effectively has no runtime dependencies other than setting the execute bit on the file’s permissions, then you should be good to go.
I’ve tested AppImage but it was very inconsistent in the results.