How to build against a specific version of glibc, what options?

seth · 2024-02-04 09:18:47

Des Pudels Kern…
Bundle glibc:
https://appimage-builder.readthedocs.io … -different

Wrt out XY-Problem I'll state a hypothesis:
You, at times, use a system that's not administered by you but either your employer, your educational facility or YOUR MOTHER.
You'd like to play some games on that system and the admin told you to do your homework first (the "your mother" joke will keep ethical questions away, so we'll roll with that and also because I'm infantile)
The system, probably some older debian or ubuntu because otherwise you'd beasking about the dominant flatschpak, can however run appimages (you did test that, did you?)
Can it also run random binaries out of your $HOME or is that mounted noexec?
Because if it can, you can just build retroarch on a clone of that system (ie. install Ubuntu 18.10 or whatever in a VM) and build retroarch w/ a different --prefix to install it into YOUR MO… no, wait: your $HOME - you can then just copy that one over and run it on YOUR MOTHERs computer. No container system needed.

The docker method DID work.
However, multiple people told me there's better ways to do this than docker, with toolchains/chroots/etc.

To be clear, what you were doing here was to run a docker container of an older debian or ubuntu system (effectively chrooting into a parallel OS) and built the appimage of retroarch inside that docker container?
And then multiple people (your BROTH… that doesn't work) told you there are betterways™ citing "toolchains" (you're not building anything w/o a toolchain anyway), "chroots" (into what, the docker container?) and "etc"…

But they didn't suggest anything specifically?

Ketrel · 2024-02-04 20:44:24

seth wrote:

Des Pudels Kern…
Bundle glibc:
https://appimage-builder.readthedocs.io … -different

I don't think I've heard of that tool before. It reads promising, and should work
EDIT: Using this according to their docs fails, I'm not sure what the cause is at this time.

seth wrote:

Wrt out XY-Problem I'll state a hypothesis:
You, at times, use a system that's not administered by you but either your employer, your educational facility or YOUR MOTHER.
You'd like to play some games on that system and the admin told you to do your homework first (the "your mother" joke will keep ethical questions away, so we'll roll with that and also because I'm infantile)
The system, probably some older debian or ubuntu because otherwise you'd beasking about the dominant flatschpak, can however run appimages (you did test that, did you?)
Can it also run random binaries out of your $HOME or is that mounted noexec?
Because if it can, you can just build retroarch on a clone of that system (ie. install Ubuntu 18.10 or whatever in a VM) and build retroarch w/ a different --prefix to install it into YOUR MO… no, wait: your $HOME - you can then just copy that one over and run it on YOUR MOTHERs computer. No container system needed.

It is a system owned by me, the Steam Deck with SteamOS to be specific, so Arch based, but not Arch. Still on glibc 2.37, / is readonly, /home is not. /home is not mounted with noexec, so no issue there.
I looked for docker images of SteamOS, but all of them build it off the current Arch, so it gets glibc 2.38 and has the same issue if I build in with one of those images. That was actually the very first avenue I tried

seth wrote:

The docker method DID work.
However, multiple people told me there's better ways to do this than docker, with toolchains/chroots/etc.
To be clear, what you were doing here was to run a docker container of an older debian or ubuntu system (effectively chrooting into a parallel OS) and built the appimage of retroarch inside that docker container?
And then multiple people (your BROTH… that doesn't work) told you there are betterways™ citing "toolchains" (you're not building anything w/o a toolchain anyway), "chroots" (into what, the docker container?) and "etc"…
https://upload.wikimedia.org/wikipedia/ … s_plan.png
But they didn't suggest anything specifically?

Yes, that's what I did, I used Debian Bookworm as the base, and built both the appimage tools and Retroarch within, packaged it as an appimage within, and then transferred the appimage to the Steamdeck where it runs without issue.
When I was discussing what I did and how with people in a docker chat, I was told that's good for one of things like that, but I'd be better suited using a custom toolchain and compiling on my host directly for if I wanted to use a setup to build more than just that single appimage in the future. That's when I was directed to crosstools-ng. From there, I've had zero luck, apparently doing things right but not getting success building, and couple people there said they had no such issue when they did, but they also combine it with buildroot, which I should look into using. I did, but haven't had any success there, and while asking for advise in the buildroot chatroom, it was suggested I use Docker with a Debian image as the base and go from there. Since that went in a big ol circle, that's when I came here to ask for suggestions on what options there were to achieve this.

(I initially before any of this, had just built Retroarch and the Appimage on my machine directly, but that's when I ran into the glibc error (the one in the appimage doc I linked) that sparked this whole endeavour to begin with.)
(Also as far as the Steamdeck goes, I don't want to use flatpak though from what I see, it's supported, and I don't want to run non-SteamOS on it because I've seen there's issues if you do, which I'd prefer to avoid to keep the Steam end of it working, so my target is pretty much fixed.)

Last edited by Ketrel (2024-02-04 21:49:17)

V1del · 2024-02-04 22:30:08

FWIW with regard to that immediate goal, Retroarch has a steam release, precisely to help running it on Steamdeck, is that not an option because cores are lacking?

In any case for your build env goal... I'd just generally ignore those people and do what works in this particular instance, i absolutely do not see what the problem would be using a docker image for creating the appimage here. but assuming you absolutely want some different toolchain, what about posting about the issues you get with the appimage-builder tool, or for that matter crosstools-ng? While I'm absolutely for trying to figure things out yourself, maybe you missed some small thing and we could actually help with that.

Ketrel · 2024-02-04 23:27:41

V1del wrote:

FWIW with regard to that immediate goal, Retroarch has a steam release, precisely to help running it on Steamdeck, is that not an option because cores are lacking?

The Steam one has a couple issues
1. It depends on running Steam, which is good if you haven't been offline too long, not so much if you have.
2. Cores are severely lacking

The desktop mode has a version of it too with better cores, but that's a flatpak with all my issues with that (personal issues with flatpaks and snaps).

V1del wrote:

In any case for your build env goal... I'd just generally ignore those people and do what works in this particular instance, i absolutely do not see what the problem would be using a docker image for creating the appimage here. but assuming you absolutely want some different toolchain, what about posting about the issues you get with the appimage-builder tool, or for that matter crosstools-ng? While I'm absolutely for trying to figure things out yourself, maybe you missed some small thing and we could actually help with that.

Well that was the point of asking for options, if those are supposed to all be viable options for this use, then yes, I'll definitely start asking about it.

In fact, if you'd like, here's what I had done

mkdir workdir
cd workdir
ct-ng x86_64-unknown-linux-gnu
cp .config _base_config
ct-ng menuconfig
 
diff -U0 _base_config .config

Diff output

    --- _base_config        2024-02-02 21:31:15.735887972 -0500
    +++ .config     2024-02-02 21:31:54.629220978 -0500
    @@ -32 +32 @@
    -CT_VCHECK="load"
    +CT_VCHECK=""
    @@ -207 +207 @@
    -CT_TARGET_VENDOR="unknown"
    +CT_TARGET_VENDOR="glibc237"
    @@ -424,2 +424,2 @@
    -CT_GLIBC_V_2_38=y
    -# CT_GLIBC_V_2_37 is not set
    +# CT_GLIBC_V_2_38 is not set
    +CT_GLIBC_V_2_37=y
    @@ -442 +442 @@
    -CT_GLIBC_VERSION="2.38"
    +CT_GLIBC_VERSION="2.37"
    @@ -448 +447,0 @@
    -CT_GLIBC_2_38_or_later=y
    @@ -450 +449 @@
    -CT_GLIBC_later_than_2_37=y
    +CT_GLIBC_older_than_2_38=y
    @@ -451,0 +451 @@
    +CT_GLIBC_2_37_or_older=y
    @@ -491 +490,0 @@
    -CT_GLIBC_HAS_OBSOLETE_LIBCRYPT=y
    @@ -496 +494,0 @@
    -# CT_GLIBC_ENABLE_OBSOLETE_LIBCRYPT is not set

Continuing on

ct-ng build
 
cd /builder
mkdir builddir
cd /builder/builddir
 
tar -xf /home/_shared/libgpg-error-1.47.tar.bz2
tar -xf /home/_shared/libassuan-2.5.6.tar.bz2
tar -xf /home/_shared/gpgme-1.23.2.tar.bz2
 
mkdir staging
 
export PATH="/builder/x-tools/x86_64-glibc237-linux-gnu/bin:${PATH}"
export CC="x86_64-glibc237-linux-gnu-gcc"
export CXX="x86_64-glibc237-linux-gnu-g++"
export LD="x86_64-glibc237-linux-gnu-ld"
export CPPFLAGS="-I/builder/builddir/staging/usr/include"
export LDFLAGS="-L/builder/builddir/staging/lib -L/builder/builddir/staging/usr/lib"
 
cd libgpg-error-1.47
./configure --prefix=/usr
make -j1
make install DESTDIR=/builder/builddir/staging
 
cd ..
cd libassuan-2.5.6
./configure --prefix=/usr
make -j1
make install DESTDIR=/builder/builddir/staging
 
cd ..
cd gpgme-1.23.2
./configure --prefix=/usr
make -j1 1>buildout_stdout.txt 2>buildout_stderr.txt
#this make fails

Stdout: https://termbin.com/1gxt
Stderr: https://termbin.com/oq7j

/usr/bin/sed: can't read /usr/lib/libgpg-error.la: No such file or directory
libtool: link: `/usr/lib/libgpg-error.la' is not a valid libtool archive
make[2]: *** [Makefile:856: libgpgme.la] Error 1
make[1]: *** [Makefile:550: all-recursive] Error 1
make: *** [Makefile:482: all] Error 2

It looks like it's trying to read /usr/lib/libgpg-error.la which I can only find only referenced in a .la file generated during the build

If I then try running `make -j1` again, I get this output

[bob@ragnarok gpgme-1.23.2]$ make -j1
make  all-recursive
make[1]: Entering directory '/builder/builddir/gpgme-1.23.2'
Making all in src
make[2]: Entering directory '/builder/builddir/gpgme-1.23.2/src'
/bin/sh ../libtool  --tag=CC   --mode=link x86_64-glibc237-linux-gnu-gcc  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k -Wno-missing-field-initializers -Wno-sign-compare -Wno-format-zero-length -Wno-format-truncation -Wno-sizeof-pointer-div  -L/builder/builddir/staging/lib -L/builder/builddir/staging/usr/lib -o gpgme-tool gpgme-tool.o argparse.o libgpgme.la -lassuan -lgpg-error 
libtool: link: x86_64-glibc237-linux-gnu-gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k -Wno-missing-field-initializers -Wno-sign-compare -Wno-format-zero-length -Wno-format-truncation -Wno-sizeof-pointer-div -o .libs/gpgme-tool gpgme-tool.o argparse.o  -L/builder/builddir/staging/lib -L/builder/builddir/staging/usr/lib ./.libs/libgpgme.so /usr/lib/libassuan.so /usr/lib/libgpg-error.so
x86_64-glibc237-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../conf   -I/builder/builddir/staging/usr/include  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k -Wno-missing-field-initializers -Wno-sign-compare -Wno-format-zero-length -Wno-format-truncation -Wno-sizeof-pointer-div -MT gpgme-json.o -MD -MP -MF .deps/gpgme-json.Tpo -c -o gpgme-json.o gpgme-json.c
mv -f .deps/gpgme-json.Tpo .deps/gpgme-json.Po
x86_64-glibc237-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../conf   -I/builder/builddir/staging/usr/include  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k -Wno-missing-field-initializers -Wno-sign-compare -Wno-format-zero-length -Wno-format-truncation -Wno-sizeof-pointer-div -MT cJSON.o -MD -MP -MF .deps/cJSON.Tpo -c -o cJSON.o cJSON.c
mv -f .deps/cJSON.Tpo .deps/cJSON.Po
/bin/sh ../libtool  --tag=CC   --mode=link x86_64-glibc237-linux-gnu-gcc  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k -Wno-missing-field-initializers -Wno-sign-compare -Wno-format-zero-length -Wno-format-truncation -Wno-sizeof-pointer-div  -L/builder/builddir/staging/lib -L/builder/builddir/staging/usr/lib -o gpgme-json gpgme-json.o cJSON.o -lm libgpgme.la -lgpg-error 
libtool: link: x86_64-glibc237-linux-gnu-gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k -Wno-missing-field-initializers -Wno-sign-compare -Wno-format-zero-length -Wno-format-truncation -Wno-sizeof-pointer-div -o .libs/gpgme-json gpgme-json.o cJSON.o  -L/builder/builddir/staging/lib -L/builder/builddir/staging/usr/lib -lm ./.libs/libgpgme.so /usr/lib/libgpg-error.so
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: warning: libassuan.so.0, needed by ./.libs/libgpgme.so, not found (try using -rpath or -rpath-link)
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_socket_connect@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_ctx_set_system_hooks@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_get_active_fds@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_sendfd@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_transact@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_write_line@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_pending_line@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_pipe_connect@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_read_line@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_new_ext@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_release@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_set_flag@LIBASSUAN_1.0'
/builder/x-tools/x86_64-glibc237-linux-gnu/lib/gcc/x86_64-glibc237-linux-gnu/13.2.0/../../../../x86_64-glibc237-linux-gnu/bin/ld.bfd: ./.libs/libgpgme.so: undefined reference to `assuan_send_data@LIBASSUAN_1.0'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:860: gpgme-json] Error 1
make[2]: Leaving directory '/builder/builddir/gpgme-1.23.2/src'
make[1]: *** [Makefile:550: all-recursive] Error 1
make[1]: Leaving directory '/builder/builddir/gpgme-1.23.2'
make: *** [Makefile:482: all] Error 2

This is just trying to get prereqs built for the appimagetool and linuxdeploy
(which are the two tools I have success building app images with)

Arch Linux

#26 2024-02-04 09:18:47

Re: How to build against a specific version of glibc, what options?

#27 2024-02-04 20:44:24

Re: How to build against a specific version of glibc, what options?

#28 2024-02-04 22:30:08

Re: How to build against a specific version of glibc, what options?

#29 2024-02-04 23:27:41

Re: How to build against a specific version of glibc, what options?

Board footer