* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
@ 2020-12-22 1:17 ` ahesford
2020-12-22 1:18 ` q66
` (28 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: ahesford @ 2020-12-22 1:17 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]
New comment by ahesford on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749283520
Comment:
In general this seems like a great idea. Are there any issues with rpaths in this scheme? I believe there are at least a few packages that install executables or shared libs that rely on rpaths to find some dependencies. Of course, if they are hard coded in a way that breaks your proposal, they would probably be broken under the current i686 multilib anyway...
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
2020-12-22 1:17 ` [RFC/tracking issue] " ahesford
@ 2020-12-22 1:18 ` q66
2020-12-22 1:22 ` Skirmisher
` (27 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 1:18 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
New comment by q66 on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749283858
Comment:
if there are they are already broken in the current scheme, but things with rpaths don't need to concern us much since the whole 32-bit multilib thing is largely for compatibility libraries, it is rare that you'd use it for 32-bit programs (and most of these should still be okay even then)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
2020-12-22 1:17 ` [RFC/tracking issue] " ahesford
2020-12-22 1:18 ` q66
@ 2020-12-22 1:22 ` Skirmisher
2020-12-22 1:58 ` q66
` (26 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Skirmisher @ 2020-12-22 1:22 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]
New comment by Skirmisher on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749284979
Comment:
Seems pretty good all around. Standardizing the existing lib32/64 setup while pointing the multilib component to a separate prefix is a pragmatic approach that still leaves room for flexibility.
I do want to address the prefix location thing: cross toolchain prefixes are weird because they have libraries for the prefix arch in `usr/lib`, but have host arch binaries in `usr/bin`, making it inconsistent with a real install (especially since in a multiarch situation, you would be able to run the "native" versions of those tools anyway). I'm not sure if there's a way to work around the host-arch binaries, or if it would be straightforward to move the cross prefixes somewhere else, e.g. `/usr/cross/<prefix>`... If nothing else, though, I would find it reasonable to put multiarch prefixes in their own subdirectory like `/usr/multiarch` or `/usr/arch` or whatever else.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (2 preceding siblings ...)
2020-12-22 1:22 ` Skirmisher
@ 2020-12-22 1:58 ` q66
2020-12-22 2:00 ` q66
` (25 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 1:58 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 238 bytes --]
New comment by q66 on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749294026
Comment:
yeah the cross prefix unification thing is just an idea but not something we necessarily have to do
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (3 preceding siblings ...)
2020-12-22 1:58 ` q66
@ 2020-12-22 2:00 ` q66
2020-12-22 2:05 ` ericonr
` (24 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 2:00 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]
New comment by q66 on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749294026
Comment:
yeah the cross prefix unification thing is just an idea but not something we necessarily have to do
it also has other problems, e.g. gccgo's libgo in crossprefix is built with a dummy static libucontext on musl so it probably does not work, and the libc is built with a partial compiler and sometimes lower optimization level so we likely do not actually want to run anything relying on the crosstoolchain's target libs :P
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (4 preceding siblings ...)
2020-12-22 2:00 ` q66
@ 2020-12-22 2:05 ` ericonr
2020-12-22 4:31 ` ericonr
` (23 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: ericonr @ 2020-12-22 2:05 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749295909
Comment:
> We will need tooling for managing these multilib prefixes. Using just xbps as it is is fairly clunky, because by default these prefixes don't have repos set up in them and so on. Especially initial setup is relatively involved.
This initial setup will be rather clunky, since it's not really possible to derive the repo path from whatever is configured in `/etc/xbps.d`; aarch64 has a completely different path from what arm uses, for example.
Just as a note for something that may not be immediately obvious, the reason we need the `/usr/lib32` symlink *as well as* the dynamic linker configuration, is that the latter affects how programs are loaded (where the linker looks for the libraries your program is linked against), while the former is a fix that will allow libraries like mesa and pulse to simply work, since they will search for things to dlopen in `/usr/lib32`.
A few concerns that came to mind now were:
- the case where a library looks for binary helpers (like PAM does, but you shouldn't have a copy of PAM in the alternate root, so it isn't a good example) in `/usr/libexec` will be kind of broken, unless one has the "native" counterparts installed and fully compatible.
- our `wine` package, specifically the `/usr/bin/wine` launcher, will need to be thoroughly fixed, but I'm not entirely sure how.
- and
> There might be packages that require wordsize-specific data files in /usr/share. These need to be found, and such files need to go to /usr/lib(32|64). This is the right thing to do either way, since they're no different from binary files, /usr/share should only contain architecture-independent data.
At least one package that I know of is aspell.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (5 preceding siblings ...)
2020-12-22 2:05 ` ericonr
@ 2020-12-22 4:31 ` ericonr
2020-12-22 4:31 ` ericonr
` (22 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: ericonr @ 2020-12-22 4:31 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749295909
Comment:
> We will need tooling for managing these multilib prefixes. Using just xbps as it is is fairly clunky, because by default these prefixes don't have repos set up in them and so on. Especially initial setup is relatively involved.
This initial setup will be rather clunky, since it's not really possible to derive the repo path from whatever is configured in `/etc/xbps.d`; aarch64 has a completely different path from what arm uses, for example.
Just as a note for something that may not be immediately obvious, the reason we need the `/usr/lib32` symlink *as well as* the dynamic linker configuration, is that the latter affects how programs are loaded (where the linker looks for the libraries your program is linked against), while the former is a fix that will allow libraries like mesa and pulse to simply work, since they will search for things to dlopen in `/usr/lib32`.
A few concerns that came to mind now were:
- the case where a library looks for binary helpers (like PAM does, but you shouldn't have a copy of PAM in the alternate root, so it isn't a good example) in `/usr/libexec` will be kind of broken, unless one has the "native" counterparts installed and fully compatible.
- our `wine` package, specifically the `/usr/bin/wine` launcher, will need to be thoroughly fixed, but I'm not entirely sure how.
- and
> There might be packages that require wordsize-specific data files in /usr/share. These need to be found, and such files need to go to /usr/lib(32|64). This is the right thing to do either way, since they're no different from binary files, /usr/share should only contain architecture-independent data.
At least one package that I know of is aspell. EDIT: I was mistaken about aspell, it did put the files in `/usr/lib`.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (6 preceding siblings ...)
2020-12-22 4:31 ` ericonr
@ 2020-12-22 4:31 ` ericonr
2020-12-22 5:11 ` ericonr
` (21 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: ericonr @ 2020-12-22 4:31 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749295909
Comment:
> We will need tooling for managing these multilib prefixes. Using just xbps as it is is fairly clunky, because by default these prefixes don't have repos set up in them and so on. Especially initial setup is relatively involved.
This initial setup will be rather clunky, since it's not really possible to derive the repo path from whatever is configured in `/etc/xbps.d`; aarch64 has a completely different path from what arm uses, for example.
Just as a note for something that may not be immediately obvious, the reason we need the `/usr/lib32` symlink *as well as* the dynamic linker configuration, is that the latter affects how programs are loaded (where the linker looks for the libraries your program is linked against), while the former is a fix that will allow libraries like mesa and pulse to simply work, since they will search for things to dlopen in `/usr/lib32`.
A few concerns that came to mind now were:
- the case where a library looks for binary helpers (like PAM does, but you shouldn't have a copy of PAM in the alternate root, so it isn't a good example) in `/usr/libexec` will be kind of broken, unless one has the "native" counterparts installed and fully compatible.
- our `wine-common` package, specifically the `/usr/bin/wine` launcher, will need to be thoroughly fixed, but I'm not entirely sure how.
- and
> There might be packages that require wordsize-specific data files in /usr/share. These need to be found, and such files need to go to /usr/lib(32|64). This is the right thing to do either way, since they're no different from binary files, /usr/share should only contain architecture-independent data.
At least one package that I know of is aspell. EDIT: I was mistaken about aspell, it did put the files in `/usr/lib`.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (7 preceding siblings ...)
2020-12-22 4:31 ` ericonr
@ 2020-12-22 5:11 ` ericonr
2020-12-22 5:26 ` ericonr
` (20 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: ericonr @ 2020-12-22 5:11 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [ ] attr
- [ ] MangoHud
- [ ] pulseaudio
- [ ] glibc
- [ ] acl
- [ ] sqlite-replication
- [ ] `common/environment/configure/gnu-configure-args.sh` itself
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (8 preceding siblings ...)
2020-12-22 5:11 ` ericonr
@ 2020-12-22 5:26 ` ericonr
2020-12-22 20:59 ` q66
` (19 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: ericonr @ 2020-12-22 5:26 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [ ] attr
- [ ] MangoHud
- [ ] pulseaudio
- [ ] glibc
- [ ] acl
- [ ] sqlite-replication
- [ ] `common/environment/configure/gnu-configure-args.sh` itself
- [ ] libhugetlbfs (`LIB64=lib64`)
- [ ] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [ ] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [ ] python(3)-tkinter
- [ ] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (9 preceding siblings ...)
2020-12-22 5:26 ` ericonr
@ 2020-12-22 20:59 ` q66
2020-12-22 20:59 ` q66
` (18 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 20:59 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [ ] MangoHud
- [ ] pulseaudio
- [ ] glibc
- [ ] acl
- [ ] sqlite-replication
- [ ] `common/environment/configure/gnu-configure-args.sh` itself
- [ ] libhugetlbfs (`LIB64=lib64`)
- [ ] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [ ] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [ ] python(3)-tkinter
- [ ] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (10 preceding siblings ...)
2020-12-22 20:59 ` q66
@ 2020-12-22 20:59 ` q66
2020-12-22 20:59 ` q66
` (17 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 20:59 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [ ] MangoHud
- [ ] pulseaudio
- [x] glibc
- [ ] acl
- [ ] sqlite-replication
- [ ] `common/environment/configure/gnu-configure-args.sh` itself
- [ ] libhugetlbfs (`LIB64=lib64`)
- [ ] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [ ] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [ ] python(3)-tkinter
- [ ] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (11 preceding siblings ...)
2020-12-22 20:59 ` q66
@ 2020-12-22 20:59 ` q66
2020-12-22 20:59 ` q66
` (16 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 20:59 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [ ] MangoHud
- [ ] pulseaudio
- [x] glibc
- [x] acl
- [ ] sqlite-replication
- [ ] `common/environment/configure/gnu-configure-args.sh` itself
- [ ] libhugetlbfs (`LIB64=lib64`)
- [ ] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [ ] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [ ] python(3)-tkinter
- [ ] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (12 preceding siblings ...)
2020-12-22 20:59 ` q66
@ 2020-12-22 20:59 ` q66
2020-12-22 20:59 ` q66
` (15 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 20:59 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [ ] MangoHud
- [ ] pulseaudio
- [x] glibc
- [x] acl
- [ ] sqlite-replication
- [ ] `common/environment/configure/gnu-configure-args.sh` itself
- [ ] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [ ] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [ ] python(3)-tkinter
- [ ] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (13 preceding siblings ...)
2020-12-22 20:59 ` q66
@ 2020-12-22 20:59 ` q66
2020-12-22 20:59 ` q66
` (14 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 20:59 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [ ] MangoHud
- [ ] pulseaudio
- [x] glibc
- [x] acl
- [ ] sqlite-replication
- [ ] `common/environment/configure/gnu-configure-args.sh` itself
- [ ] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [x] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [ ] python(3)-tkinter
- [ ] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (14 preceding siblings ...)
2020-12-22 20:59 ` q66
@ 2020-12-22 20:59 ` q66
2020-12-22 21:22 ` q66
` (13 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 20:59 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [ ] MangoHud
- [ ] pulseaudio
- [x] glibc
- [x] acl
- [ ] sqlite-replication
- [ ] `common/environment/configure/gnu-configure-args.sh` itself
- [ ] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [x] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [ ] python(3)-tkinter
- [x] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (15 preceding siblings ...)
2020-12-22 20:59 ` q66
@ 2020-12-22 21:22 ` q66
2020-12-22 21:34 ` q66
` (12 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 21:22 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [ ] MangoHud
- [ ] pulseaudio
- [x] glibc
- [x] acl
- [ ] sqlite-replication
- [x] `common/environment/configure/gnu-configure-args.sh` itself
- [ ] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [x] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [ ] python(3)-tkinter
- [x] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (16 preceding siblings ...)
2020-12-22 21:22 ` q66
@ 2020-12-22 21:34 ` q66
2020-12-22 21:58 ` q66
` (11 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 21:34 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [ ] MangoHud
- [ ] pulseaudio
- [x] glibc
- [x] acl
- [ ] sqlite-replication
- [x] `common/environment/configure/gnu-configure-args.sh` itself
- [x] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [x] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [ ] python(3)-tkinter
- [x] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (17 preceding siblings ...)
2020-12-22 21:34 ` q66
@ 2020-12-22 21:58 ` q66
2020-12-22 22:16 ` q66
` (10 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 21:58 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [ ] MangoHud
- [ ] pulseaudio
- [x] glibc
- [x] acl
- [x] sqlite-replication
- [x] `common/environment/configure/gnu-configure-args.sh` itself
- [x] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [x] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [ ] python(3)-tkinter
- [x] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (18 preceding siblings ...)
2020-12-22 21:58 ` q66
@ 2020-12-22 22:16 ` q66
2020-12-23 0:26 ` q66
` (9 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-22 22:16 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [x] MangoHud
- [ ] pulseaudio
- [x] glibc
- [x] acl
- [x] sqlite-replication
- [x] `common/environment/configure/gnu-configure-args.sh` itself
- [x] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [x] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [ ] python(3)-tkinter
- [x] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (19 preceding siblings ...)
2020-12-22 22:16 ` q66
@ 2020-12-23 0:26 ` q66
2020-12-23 0:26 ` q66
` (8 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-23 0:26 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [x] MangoHud
- [ ] pulseaudio
- [x] glibc
- [x] acl
- [x] sqlite-replication
- [x] `common/environment/configure/gnu-configure-args.sh` itself
- [x] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [ ] libva (maybe should go in the mesa PR?)
- [x] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [x] python(3)-tkinter
- [x] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (20 preceding siblings ...)
2020-12-23 0:26 ` q66
@ 2020-12-23 0:26 ` q66
2020-12-23 0:27 ` q66
` (7 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-23 0:26 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [x] MangoHud
- [ ] pulseaudio
- [x] glibc
- [x] acl
- [x] sqlite-replication
- [x] `common/environment/configure/gnu-configure-args.sh` itself
- [x] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [x] cegui (might just allow removal of a sed block)
- [ ] steam INSTALL hook? not sure
- [x] python(3)-tkinter
- [x] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (21 preceding siblings ...)
2020-12-23 0:26 ` q66
@ 2020-12-23 0:27 ` q66
2020-12-23 0:39 ` q66
` (6 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-23 0:27 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [x] MangoHud
- [ ] pulseaudio
- [x] glibc
- [x] acl
- [x] sqlite-replication
- [x] `common/environment/configure/gnu-configure-args.sh` itself
- [x] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [x] cegui (might just allow removal of a sed block)
- ~~steam INSTALL hook? not sure~~
- [x] python(3)-tkinter
- [x] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (22 preceding siblings ...)
2020-12-23 0:27 ` q66
@ 2020-12-23 0:39 ` q66
2020-12-27 20:07 ` ericonr
` (5 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: q66 @ 2020-12-23 0:39 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [x] MangoHud
- [x] pulseaudio
- [x] glibc
- [x] acl
- [x] sqlite-replication
- [x] `common/environment/configure/gnu-configure-args.sh` itself
- [x] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [x] cegui (might just allow removal of a sed block)
- ~~steam INSTALL hook? not sure~~
- [x] python(3)-tkinter
- [x] amdvlk
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (23 preceding siblings ...)
2020-12-23 0:39 ` q66
@ 2020-12-27 20:07 ` ericonr
2020-12-27 20:26 ` ericonr
` (4 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: ericonr @ 2020-12-27 20:07 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749342401
Comment:
Packages that receive special treatment for i686 (due to multilib) and should be fixed (like https://github.com/void-linux/void-packages/pull/27291) for this project to work (I will be updating this list as I find them; feel free to edit. checks will be added when the package has been fixed and rebuilt):
- [x] attr
- [x] MangoHud
- [x] pulseaudio
- [x] glibc
- [x] acl
- [x] sqlite-replication
- [x] `common/environment/configure/gnu-configure-args.sh` itself
- [x] libhugetlbfs (`LIB64=lib64`)
- [x] avahi-discover (does some weird stuff with tmpinstall)
- [x] cegui (might just allow removal of a sed block)
- ~~steam INSTALL hook? not sure~~
- [x] python(3)-tkinter
- [x] amdvlk
- [x] alsa
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (24 preceding siblings ...)
2020-12-27 20:07 ` ericonr
@ 2020-12-27 20:26 ` ericonr
2020-12-28 1:35 ` ericonr
` (3 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: ericonr @ 2020-12-27 20:26 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 237 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-751512288
Comment:
Our 32bit nvidia packages are created manually, we'd have to figure out how to make them work.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (25 preceding siblings ...)
2020-12-27 20:26 ` ericonr
@ 2020-12-28 1:35 ` ericonr
2021-01-07 20:31 ` ahesford
` (2 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: ericonr @ 2020-12-28 1:35 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-751512288
Comment:
Our 32bit nvidia packages are created manually, we'd have to figure out how to make them work.
For this, we could try to build the nvidia stuff inside a i686 masterdir and make packages *only* with the libraries, without the DKMS module.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (26 preceding siblings ...)
2020-12-28 1:35 ` ericonr
@ 2021-01-07 20:31 ` ahesford
2022-05-01 2:14 ` github-actions
2022-05-01 5:45 ` the-maldridge
29 siblings, 0 replies; 31+ messages in thread
From: ahesford @ 2021-01-07 20:31 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]
New comment by ahesford on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-756366215
Comment:
I just did this on an `aarch64` installation on a Raspberry Pi, when I realized I couldn't run `retroarch` because all of the cores precompiled by that project are 32-bit only. Enter multilib forr ARM. Except for the repository path differences (an easy fix), everything worked beautifully.
```bash
mkdir -p /usr/armv7l/etc/xbps.d
echo "repository=https://mirrors.servercentral.com/voidlinux/current" > /usr/armv7l/etc/xbps.d/00-repository-main.conf
XBPS_ARCH=armv7l xbps-install -S -C /usr/armv7l/etc/xbps.d retroarch mesa-dri
rm -rf /usr/lib32 && ln -s armv7l/usr/lib /usr/lib32
ln -s /usr/armv7l/usr/lib/ld-2.30.so /usr/lib/ld-linux-armhf.so.3
/usr/armv7l/usr/bin/retroarch
```
We could wrap this in a simple script that derives `XBPS_ARCH` from the executable name (*e.g.*, `xbps-install-<arch>`) which can check for `/some/path/to/<arch>`, complain if it finds no `etc/xbps.d/00-repository-main.conf` (or maybe prepopulate the file) and make the necessary links after installation if they are missing.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (27 preceding siblings ...)
2021-01-07 20:31 ` ahesford
@ 2022-05-01 2:14 ` github-actions
2022-05-01 5:45 ` the-maldridge
29 siblings, 0 replies; 31+ messages in thread
From: github-actions @ 2022-05-01 2:14 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 293 bytes --]
New comment by github-actions[bot] on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-1114104744
Comment:
Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC/tracking issue] deprecating -lib32 multilib system
2020-12-22 0:50 [ISSUE] tracking issue: deprecating -lib32 multilib system q66
` (28 preceding siblings ...)
2022-05-01 2:14 ` github-actions
@ 2022-05-01 5:45 ` the-maldridge
29 siblings, 0 replies; 31+ messages in thread
From: the-maldridge @ 2022-05-01 5:45 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]
New comment by the-maldridge on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-1114139716
Comment:
We'd certainly like to keep this going, I'm going to exempt this from bot actions with the request label, its not quite the right label, but its the quick fix I have right now.
^ permalink raw reply [flat|nested] 31+ messages in thread