New Linux AppImage and source builds to test

[mcarans]

I have created AppImages for Oolite. Please can you test. They are in the zips pkg-appimage and pkg-appimage-test here:
https://github.com/mcarans/oolite/actio ... 0197295005

In addition, I have created build from source shell scripts. These can be found by checking out the modern_linux branch here:
https://github.com/mcarans/oolite/

The script is here: https://github.com/mcarans/oolite/blob/ ... install.sh

The source shell script is used to make the AppImage on Ubuntu 22.04 in GitHub Actions. It also works with Kubuntu 25.10 (what I'm using). It has untested alternative package downloads for other Linux distros eg. Fedora and Arch based. You can see the packages it will attempt to download for different distros here:
https://github.com/mcarans/oolite/blob/ ... kage_fn.sh

If it doesn't work, please let me know what packages are incorrect or missing on your distro.

[Lone_Wolf]

Code: Select all

elif [[ "$OS_FAMILY" == *"arch"* ]]; then
    # Arch, Manjaro, EndeavourOS
    CURRENT_DISTRO="arch"
    INSTALL_CMD=(sudo pacman -S --noconfirm)
    UPDATE_CMD=(sudo pacman -Sy)

While the commands are syntactically correct, pacman -Sy without -u will cause issues on archlinux.
manjaro uses a different setup where it may work fine, no idea about EndeavourOS.

The use of sudo suggests this is intended for systemwide installs, is that correct ?
If yes, the preferred method of bulding from source for Arch Linux is to create a PKGBUILD that will result in a binary to be installed by pacman.

For things not in official repos the place for that is the Arch User Repository aka AUR , see https://wiki.archlinux.org/title/Arch_User_Repository .
While AUR PKGBUILDs are (officially) only supported on Arch Linux, many users of Manjaro , EndeavourOS, CachyOS etc also use them.


Packages in the aur need to comply with several guidelines and are meant to be build by users on their own systems.
In case someone wants to provide binary versions of aur packages they should be build in a clean chroot so build environment is not influenced by local settings.

https://aur.archlinux.org/packages/oolite-git is maintained by me and complies with the guidelines.

Note that currently gnustep -base & gnustep-make on archlinux are build against gcc-objc .
I don't know whether clang can use those gnustep-* versions, that will have to be tested.

There is a libobjc2 package in aur, but no gnustep-* built with that library/clang .
Adding those will likely be a lot of work.

For now i suggest to stick with my oolite-git package and setup a clean chroot archlinux build environment to provide binaries.
I have no idea if github supports archlinux CI builds , but sourcehut.org does.

[mcarans]

Code: Select all

elif [[ "$OS_FAMILY" == *"arch"* ]]; then
    # Arch, Manjaro, EndeavourOS
    CURRENT_DISTRO="arch"
    INSTALL_CMD=(sudo pacman -S --noconfirm)
    UPDATE_CMD=(sudo pacman -Sy)

While the commands are syntactically correct, pacman -Sy without -u will cause issues on archlinux.
manjaro uses a different setup where it may work fine, no idea about EndeavourOS.

The use of sudo suggests this is intended for systemwide installs, is that correct ?
If yes, the preferred method of bulding from source for Arch Linux is to create a PKGBUILD that can be installed by pacman.

For things not in official repos the place for that is the Arch User Repository aka AUR , see https://wiki.archlinux.org/title/Arch_User_Repository .
While AUR PKGBUILDs are (officially) only supported on Arch Linux, many users of Manjaro , EndeavourOS, CachyOS etc also use them.


Packages in the aur need to comply with several guidelines and are meant to be build by users on their own systems.
In case someone wants to provide binary versions of aur packages they should be build in a clean chroot so build environment is not influenced by local settings.

https://aur.archlinux.org/packages/oolite-git is maintained by me and complies with the guidelines.

Note that currently gnustep -base & gnustep-make on archlinux are build against gcc-objc .
I don't know whether clang can use those gnustep-* versions, that will have to be tested.

There is a libobjc2 package in aur, but no gnustep-* built with that library/clang .
Adding those will likely be a lot of work.

For now i suggest to stick with my oolite-git package and setup a clean chroot archlinux build environment to provide binaries.
I have no idea if github supports archlinux CI builds , but sourcehut.org does.

Yes systemwide install of standard packages and /usr/local for the packages built from source. The source build would be for someone who wants to build from source (eg. a developer), rather than install binaries from a package manager for which the AppImage and your package are provided. I'm also looking at the possibility of Flatpak.

I'm avoiding making packages for every distro (even my own via deb) as it's a lot of work to create and maintain. Ubuntu also does not have GNUStep built with Clang as a standard package (which is what the GNUStep developers recommend and is more performant + better debugging of Objective-C).

Funnily enough MSYS2 on Windows uses PKGBUILD so I made Windows PKGBUILD files for SDL, espeak-ng, pcaudiolib, Spidermonkey, libobjc2, GNUStep Make and GNUStep Base on that platform (https://github.com/mcarans/oolite_windeps_build). Some of these replacing with lines from the build script (https://github.com/mcarans/oolite/blob/ ... sh#L76-L96) might provide a starting point for things that aren't already in AUR if you wish to update https://aur.archlinux.org/packages/oolite-git for the modern Linux build. PKGBUILD is quite straightforward (at least on MSYS2) - my espeak-ng and pcaudiolib packages were accepted as base packages in MSYS2. Let me know if you decide to look at that and need any assistance.

[Lone_Wolf]

Pacman is essentially a cli-frontend for libalpm.so and all systemwide installations on archlinux are maintained through libalpm .
Other package managers like flatpak, pip, conda, kde discover , gnome sw centre, steam etc either communicate with libalpm or stick to user installs (probably 99% do the latter on archlinux)

Pacman/libalpm are forbidden to touch user folders. This means anything under $HOME and /usr/local .

So as long as configure/make/make install or modern equivalent only touches /usr/local its fine.
If installing deps is needed, it should be done manually through a pacman command listed in documentation.




As for a clang/libobjc2 build :
The PKGBUILDs in oolite_windeps_build look decent and of higher quality then many aur submissions.

They do have one issue though : use of external envvars to configure things.
archlinux PKGBUILDs should not need user configuration to ensure everyone that builds them gets the same result.
Using external env vars to configure things is technically not 'user configuration' (and some of my aur packages do use it) but is frowned heavily upon.

gcc is default compiler on arch and building with llvm/clang is only done when there are substantial benefits or gcc is not supported by upstream.
Espeak-ng, pcaudiolib, sdl12-compat & nspr from repos work fine for oolite.

A spidermonkey package would definitely be a good thing, but determining what source to use for it seems to be the tricky part.
For libobjc2 , gnustep-base, gnustep-make aur packages could be made and the msys2 PKGBUILDs would help.
non-repo packages need to coexist with repo packages (preferred) or replace/conflict them. This tends to make creating them harder.

example :
/usr/lib/libobjc.so , /usr/lib/libobjc.so.4 and /usr/lib/libobjc.so.4.0.0 are used by gcc-libs .
libobjc2 needs to use other sonames (can be done by putting them in /usr/lib/libobjc2 if the names clash)

[mcarans]

Pacman is essentially a cli-frontend for libalpm.so and all systemwide installations on archlinux are maintained through libalpm .
Other package managers like flatpak, pip, conda, kde discover , gnome sw centre, steam etc either communicate with libalpm or stick to user installs (probably 99% do the latter on archlinux)

Pacman/libalpm are forbidden to touch user folders. This means anything under $HOME and /usr/local .

So as long as configure/make/make install or modern equivalent only touches /usr/local its fine.
If installing deps is needed, it should be done manually through a pacman command listed in documentation.




As for a clang/libobjc2 build :
The PKGBUILDs in oolite_windeps_build look decent and of higher quality then many aur submissions.

They do have one issue though : use of external envvars to configure things.
archlinux PKGBUILDs should not need user configuration to ensure everyone that builds them gets the same result.
Using external env vars to configure things is technically not 'user configuration' (and some of my aur packages do use it) but is frowned heavily upon.

gcc is default compiler on arch and building with llvm/clang is only done when there are substantial benefits or gcc is not supported by upstream.
Espeak-ng, pcaudiolib, sdl12-compat & nspr from repos work fine for oolite.

A spidermonkey package would definitely be a good thing, but determining what source to use for it seems to be the tricky part.
For libobjc2 , gnustep-base, gnustep-make aur packages could be made and the msys2 PKGBUILDs would help.
non-repo packages need to coexist with repo packages (preferred) or replace/conflict them. This tends to make creating them harder.

example :
/usr/lib/libobjc.so , /usr/lib/libobjc.so.4 and /usr/lib/libobjc.so.4.0.0 are used by gcc-libs .
libobjc2 needs to use other sonames (can be done by putting them in /usr/lib/libobjc2 if the names clash)

I have removed sudo from the Arch setup and it seems to work ok. I have made a CI that passes for the modern Clang build: https://github.com/mcarans/oolite/actio ... 7987670226

The library clashes may be an issue. Typically I have chosen to remove gcc Objective-C libraries when using Clang and vice versa although in theory the GNUStep devs say they can coexist.

If there are existing Arch packages for some things like GNUStep Base, then they could be a good starting point and just switch from gcc to Clang.

[Lone_Wolf]

I see it has been successfull and you cloned gnustep libobjc2 / tools-base / tools-make sourcecode but I have no idea what the build commands are.
It might as well be a black box.

Yes, there are PKGBUILDs for gnustep-base & gnustep-make in repos, but they have to be adapted to use libobjc2 .
I tried to do that a few weeks ago but failed and stopped after spending 3 hours on it.

Part of the fail was due to not having examples of gnustep builds with clang.

[mcarans]

I see it has been successfull and you cloned gnustep libobjc2 / tools-base / tools-make sourcecode but I have no idea what the build commands are.
It might as well be a black box.

Yes, there are PKGBUILDs for gnustep-base & gnustep-make in repos, but they have to be adapted to use libobjc2 .
I tried to do that a few weeks ago but failed and stopped after spending 3 hours on it.

Part of the fail was due to not having examples of gnustep builds with clang.

Both Fedora and Arch build now: https://github.com/mcarans/oolite/actio ... 0203117831. Fedora Oolite even ran locally on Kubuntu through distrobox to my surprise.

Here are the specific build commands: https://github.com/mcarans/oolite/blob/ ... h#L73-L111 (the link should go to install.sh in GitHub and highlight lines 73-111 that build libobjc2, tools-make and libs-base). Also below, copied the specific lines:

Code: Select all

    cd libobjc2
    rm -rf build
    mkdir build
    cd build
    if ! cmake -DTESTS=on -DCMAKE_BUILD_TYPE=Release -DGNUSTEP_INSTALL_TYPE=NONE -DEMBEDDED_BLOCKS_RUNTIME=ON -DOLDABI_COMPAT=OFF ../; then
        echo "❌ libobjc2 cmake configure failed!" >&2
        return 1
    fi

    if ! cmake --build .; then
        echo "❌ libobjc2 cmake build failed!" >&2
        return 1
    fi
    sudo cmake --install .
    cd ../..

    cd tools-make
    make distclean
    if ! ./configure --with-library-combo=ng-gnu-gnu --with-runtime-abi=gnustep-2.2; then
        echo "❌ tools-make configure failed!" >&2
        return 1
    fi
    make
    sudo make install
    cd ..

    cd libs-base
    make distclean
    source /usr/local/share/GNUstep/Makefiles/GNUstep.sh
    if ! ./configure; then
        echo "❌ libs-base configure failed!" >&2
        return 1
    fi
    if ! make -j$(nproc); then
        echo "❌ libs-base make failed!" >&2
        return 1
    fi
    sudo make install
    cd ..

[SiriusCG]

I'd like to test your appImage on Lubuntu 22.04 but I'm unable to locate a download link on the page you linked to. I see them listed under "Artifacts" at the bottom of the page but mousing over them does nothing.

[another_commander]

You must be logged in to GitHub, then those items become download links.

[mcarans]

I fixed the AppImage to include missing SDL2 - you can get latest AppImage here: https://github.com/mcarans/oolite/actio ... 0256287244

It worked on Fedora in Distrobox.

[SiriusCG]

You must be logged in to GitHub, then those items become download links.

Thanks. I thought that might be the case. I'll have to pass on testing then. No desire to create another online account with a service I'll never use. Cheers.

[mcarans]

You must be logged in to GitHub, then those items become download links.

Thanks. I thought that might be the case. I'll have to pass on testing then. No desire to create another online account with a service I'll never use. Cheers.

Here is a download link if you want to test: https://www.filemail.com/d/rqboegjegmaysyy. If you do, please let me know what version of Linux you use.

[Commander_X]

[...]
Here is a download link if you want to test: https://www.filemail.com/d/rqboegjegmaysyy. If you do, please let me know what version of Linux you use.

Sigh (expected):

Code: Select all

$ ./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage 
./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage)

This is on Slackware 15.0 (glibc still 2.33)

There's a reason I'm using "me own" build

[mcarans]

[...]
Here is a download link if you want to test: https://www.filemail.com/d/rqboegjegmaysyy. If you do, please let me know what version of Linux you use.

Sigh (expected):

Code: Select all

$ ./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage 
./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./Oolite_1.91.0.7781-251216-47a0cfb-x86_64.AppImage)

This is on Slackware 15.0 (glibc still 2.33)

There's a reason I'm using "me own" build

I expect it's down to the age of the distro. The AppImage was built in GitHub Actions on Ubuntu 22.04LTS (April 21, 2022). Slackware 15 was released before (February 2, 2022). I could try to build the AppImage in GH Actions on 20.04LTS but may run into issues. I'd be interested to know how many are using pre Ubuntu 22.04LTS distros.

[another_commander]

AppImages are now posted on github as pre-releases in place of the old *.run installers. You can download directly from there too.

First nightly with appimages is 95855a3.