Compile gcc

[BloodANGELdb]

Good afternoon, when compiling gcc, with the prefix $PREFIX/glibc and $PREFIX/glibc_test I get the following errors.

What could be the reason?

[Maxython]

Good afternoon, when compiling gcc, with the prefix $PREFIX/glibc and $PREFIX/glibc_test I get the following errors.

What do you mean with two prefixes? Did you reconfigure something in gpkg/gcc-libs/build.sh?

What could be the reason?

The error says that mv was not found. Have you tried installing coreutils-glibc?

One personal question: are you trying to build gcc for glibc32 (I assumed this since you recently closed your request for implementing glibc32 for 64-bit architectures)?

[BloodANGELdb]

Good afternoon, when compiling gcc, with the prefix $PREFIX/glibc and $PREFIX/glibc_test I get the following errors.

What do you mean with two prefixes? Did you reconfigure something in gpkg/gcc-libs/build.sh?

What could be the reason?

The error says that mv was not found. Have you tried installing coreutils-glibc?

One personal question: are you trying to build gcc for glibc32 (I assumed this since you recently closed your request for implementing glibc32 for 64-bit architectures)?

1. no, I didn’t reconfigure it, I tried to compile it for a different prefix, it didn’t work, I tried it with the original prefix and I see the same errors.

2. Yes installed

3. closed because with the release of wine 9* with Wow64 there is no need for this. I'm trying to create a separate prefix for wine so that it does not interfere with termux-pacman and other projects built on glibc_Termux_Pacman. I partially realized this through crutches. Well, I'm missing a couple of components.

4. I reinstalled everything again and now I have these errors.

[Maxython]

closed because with the release of wine 9* with Wow64 there is no need for this. I'm trying to create a separate prefix for wine so that it does not interfere with termux-pacman and other projects built on glibc_Termux_Pacman. I partially realized this through crutches. Well, I'm missing a couple of components.

Why create such complex circuits. You can simply compile wine with a different prefix separately from the glibc system and still use it. I don’t understand your caution towards glibc, how can wine interfere with other projects?

no, I didn’t reconfigure it, I tried to compile it for a different prefix, it didn’t work, I tried it with the original prefix and I see the same errors.

Compiling gcc itself is quite tricky. This error can occur for various reasons, but most likely it is due to a reconfigured prefix.

[BloodANGELdb]

Compiling gcc itself is quite tricky. This error can occur for various reasons, but most likely it is due to a reconfigured prefix.

I came to the conclusion that I don’t need to create gcc. I choose such a complex scheme because when installing ready-made prefixes built on glibc, my prefix stops working normally.

[Maxython]

I choose such a complex scheme because when installing ready-made prefixes built on glibc, my prefix stops working normally.

Could you show the error that occurs in this case? Perhaps I can help you solve this problem.

[BloodANGELdb]

I choose such a complex scheme because when installing ready-made prefixes built on glibc, my prefix stops working normally.

Could you show the error that occurs in this case? Perhaps I can help you solve this problem.

[Maxython]

I didn't ask for a gcc compilation error, I asked for an error (as I understand the use of wine) that forced you to compile gcc.

[BloodANGELdb]

I didn't ask for a gcc compilation error, I asked for an error (as I understand the use of wine) that forced you to compile gcc.

In this case, it is difficult to show errors, all emulators are installed in the $PREFIX/glibc prefix, first destroying everything in this prefix and replacing it with their own libraries, which breaks compatibility with alternative emulators and termux-pacman

[Maxython]

In this case, it is difficult to show errors, all emulators are installed in the $PREFIX/glibc prefix, first destroying everything in this prefix and replacing it with their own libraries, which breaks compatibility with alternative emulators and termux-pacman

I became more interested in this error. I will ask you to describe what you are doing that results in such an error (if it is not difficult, you can make a video or screenshots) and describe what “emulators” you use (especially the one that destroys the glibc system).

[BloodANGELdb]

In this case, it is difficult to show errors, all emulators are installed in the $PREFIX/glibc prefix, first destroying everything in this prefix and replacing it with their own libraries, which breaks compatibility with alternative emulators and termux-pacman

I became more interested in this error. I will ask you to describe what you are doing that results in such an error (if it is not difficult, you can make a video or screenshots) and describe what “emulators” you use (especially the one that destroys the glibc system).

I’ll try to write it down later, well, let’s say box64droid and mobox cannot exist together, since they have the same prefix which will overwrite glibc

[Maxython]

I’ll try to write it down later, well, let’s say box64droid and mobox cannot exist together, since they have the same prefix which will overwrite glibc

Now everything has become clear. I think it would be much easier to ask the box64droid developer and the mobox developer to add the ability to work with already installed glibc packages to their projects.

[leegao]

Another hack around here - there's really no reason that box64droid and mobox have to ship the full glibc runtime. Instead, it seems do-able to just have them use/share glibc packages from here when possible:

# from DT_NEEDED used by wine + box64
apt install --reinstall alsa-lib-glibc box64-glibc dbus-glibc glib-glibc glibc libflac-glibc liblzma-glibc libmp3lame-glibc libmpg123-glibc libogg-glibc libopus-glibc libpulse-glibc libsndfile-glibc libvorbis-glibc libwayland-glibc libx11-glibc libxau-glibc libxcb-glibc libxdmcp-glibc libxext-glibc libxshmfence-glibc mesa-vulkan-icd-freedreno-glibc zlib-glibc zstd-glibc
# from dynamic loads from wine (but not part of the DT_NEEDED)
apt install --reinstall freetype-glibc libxinerama-glibc libxxf86vm-glibc libxrender-glibc libxcomposite-glibc libxi-glibc libxrender-glibc libxcursor-glibc libgnutls-glibc libbz2-glibc libxrandr-glibc libxfixes-glibc p11-kit-glibc krb5-glibc e2fsprogs-glibc libffi-glibc libidn2-glibc libunistring-glibc libtasn1-glibc libnettle-glibc libnettle-glibc libgmp-glibc libdrm-glibc mesa-glibc 

Here, you can use https://www.reddit.com/r/termux/comments/199nmym/good_news_for_apt_users_glibcpackages_are_now/ to keep the package management simple

It might even be possible, if wine-glibc is (becomes?) a thing, to just install that for the sole purpose of getting these base dependencies.

After that, there are just a few more things Mobox/box64droid would need to do:

1. Bundle (or rebuild) their build of box64-android (e.g. for Mobox - https://github.com/olegos2/mobox/blob/main/patches/box64-setdirs.patch) - actually, I take this back, it looks like their patch is subsumed by upstream (https://github.com/termux-pacman/glibc-packages/blob/main/gpkg/box64/setdirs.patch) or any other missing libraries, and include them somewhere like $PREFIX/glibc/lib/mobox/
2. Include $PREFIX/glibc/lib/mobox/ into either LD_LIBRARY_PATH or BOX64_LD_LIBRARY_PATH
3. (if necessary) Rebuild their respective builds of wine (e.g. https://github.com/olegos2/mobox/blob/main/patches/ge-8-25.patch + patches/fix-address-space.diff) - it doesn't seem like it requires any direct changes to glibc, so you can probably skip this
4. Move the $PREFIX/glibc/share -> $PREFIX/glibc/mobox/share, and namespace anything that needs to be namespaced (e.g. fonts, the wine installation, the .wine prefix, etc)
5. Finally, change the install/uninstall scripts to not just ship its own glibc runtime (instead, installing them from pkg) and (definitely) not just rm -rf $PREFIX/glibc when uninstalling

I definitely think this is possible. I've gotten both to work with the glibc-packages runtime - outside of the libraries they ship on their own - and I've even gotten both to work with a fresh build of debian 12 (but with a custom overlayed runtime with the glibc-packages glibc + box64 + libxcb + libglvnd patches added to avoid the seccomp-filter/x11-socket/mesa-loader path issues)