lighterowl / transgui

A fork of Transmission Remote GUI
GNU General Public License v2.0
152 stars 4 forks source link

Error building in Linux Mint #12

Closed fredo-47 closed 1 year ago

fredo-47 commented 1 year ago

Hello, I am on Linux Mint 21.1 Cinnamon, and I tried to build your transgui fork by executing the build_ubuntu.sh under the .github directory.

After lots of messages, it finally stops with this error: [...] (3104) Compiling main.pas /home/rene/xavery-transgui/main.pas(46,65) Warning: (3226) Don't load LINEINFO unit manually, Use the -gl compiler switch instead /home/rene/xavery-transgui/main.pas(44,3) Fatal: (10022) Can't find unit httpsend used by Main Fatal: (1018) Compilation aborted Error: /usr/bin/ppcx64 returned an error exitcode Error: (lazarus) Projekt kompilieren, Modus: Release, Ziel: units/transgui: stopped with exit code 1 Error: (lazbuild) failed compiling of project /home/rene/xavery-transgui/transgui.lpi

Any idea how to fix this?

fredo-47 commented 1 year ago

I found out: In order to populate the folder synapse/source/lib, simple cloning of the repository is not sufficient, but it's also required to do git submodule update --init --recursive

(I am not expert. I only tried this because this command is also used in building instructions for the actual transmission :-) )

fredo-47 commented 1 year ago

Btw, at beginning of build process, the script installs fuse. In my OS, this step removes several other things, including fuse3 (which actually provides the fuse features):

The following packages are REMOVED: fuse3 gvfs-fuse mint-meta-cinnamon mint-meta-core mintstick ntfs-3g testdisk xdg-desktop-portal xdg-desktop-portal-gtk The following NEW packages are installed: fuse

Are you sure that fuse is required over fuse3?

lighterowl commented 1 year ago

Thanks for the report. I do agree that a clear instruction that you need to fetch submodules before building is long overdue. Will fix that right away as I need to update the actual submodule too due to upstream changes.

I'm not a Ubuntu user so this script was written just to run it in GitHub CI. FUSE is only needed because AppImage requires it, I will try fuse3 instead and just use it if it works.

lighterowl commented 1 year ago

Turns out libfuse2 should be installed instead of fuse, as documented in https://github.com/AppImage/AppImageKit/wiki/FUSE . This is now fixed.

fredo-47 commented 1 year ago

@xavery , thanks for your quick response!

I have got another (more general) question: I see that transgui--x86_64.AppImage executable is 35,7 MB in filesize, while the "normal" transgui executable is only 4,5 MB in filesize. Both seem to work on my Linux system. The look is somewhat different though, e.g. the smaller transgui seems to use my system colors (Linux Mint green), while the bigger AppImage uses blue color.

So what is the actual purpose or advantage of having an AppImage file? I would maybe assume that the AppImage is totally portable, i.e. usable on any other Linux system, and the smaller transgui would only work on the system I built it on (or at least on systems that have the same libraries available), is that right?

lighterowl commented 1 year ago

So what is the actual purpose or advantage of having an AppImage file? I would maybe assume that the AppImage is totally portable, i.e. usable on any other Linux system, and the smaller transgui would only work on the system I built it on (or at least on systems that have the same libraries available), is that right?

Exactly that. AppImage includes all libraries that the main executable depends on, however that in itself doesn't guarantee that it will run on every system as it's built on Ubuntu 22.04 and will probably not run on older distributions due to kernel and/or C library dependencies. The solution to that is building on the oldest supported distribution (which these days would be CentOS 7) which will guarantee forward compatibility.

However, even that is still not a 100% perfect solution because, in this particular example, the Qt version inside the package might not include any system-specific modifications like theming, which causes what you're describing. When I run the AppImage on my system, the window is not scaled according to the system's DPI.

What you built locally is just an executable file that simply loads all the dependent libraries from your system, but it might not/will not work on other systems.

I don't see this as a blocking issue because there's no "one true way" of packaging applications for Linux, at least I'm not aware of one. Besides, Linux distributions usually include a way for users to compile stuff on their own via a ports-like system (gentoo's emerge or Arch's PKGBUILD).