| 1 |
Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> 'No mainstream' as you claim it doesn't mean it's fine to invent yet |
| 4 |
> another completely incompatible solution. |
| 5 |
|
| 6 |
As I understand, the compatibility with Debian might be increased |
| 7 |
(keeping /lib32), at the cost of slightly decreasing the compatibility |
| 8 |
with Red Hat (concerning 32bit emulation). |
| 9 |
So depending on the use case, it might as well be more compatible. |
| 10 |
|
| 11 |
>> in _all_ /lib* directories |
| 12 |
> |
| 13 |
> This is not true. |
| 14 |
|
| 15 |
You are right, I had made a stupid mistake. (I forgot that I still |
| 16 |
have the symlink lib->lib64 so that of course I should not have |
| 17 |
wondered why all ld-* existed in both libs...) |
| 18 |
|
| 19 |
> the linker uses /lib path independently of how multilib is done |
| 20 |
> on the system. |
| 21 |
|
| 22 |
I am not sure whether I understand what you mean. |
| 23 |
Do you mean that practically sys-libs/binutils or sys-libs/glibc |
| 24 |
have hardcoded |
| 25 |
/lib -> 32bit |
| 26 |
/lib64 -> 64bit |
| 27 |
(concerning ld-*) unless one patches it out? |
| 28 |
In this case you are right that there is an upstream to follow. |
| 29 |
In this case I wonder why Debian decided to patch out this |
| 30 |
upstream decision to support /lib32. |
| 31 |
|
| 32 |
> The 32-bit proprietary binaries use exactly /lib which is the main |
| 33 |
> reason for the switch. |
| 34 |
|
| 35 |
I thought the main reason for the switch is to avoid the |
| 36 |
merging of /lib and /lib64 which in bug 506276 led to problems |
| 37 |
for debugging. |
| 38 |
For this reason I am afraid that now merging /lib and /lib32 |
| 39 |
might again lead to a similar type of problems. |
| 40 |
I am aware that exactly the cited problem is now mitigated, |
| 41 |
because this time the merging does not happen over a symlink. |
| 42 |
But anyway, it seems unnatural when "curing" from a merge to |
| 43 |
decide to merge something else. |
Archives