Simon McVittie dixit:

>opt-in to (2.) is available via -D_FILE_OFFSET_BITS=64 for the subset
>of libraries that can support it without breaking ABI, and similarly

Right, but e.g. <fts.h> refuses to work under it.

>That wasn't actually the reason for my concern. As far as I'm aware, the
>glibc dynamic linker doesn't guarantee not to look at libraries from other
>architectures' multiarch library directories, or even know which directory
>is for which architecture. There's only one /etc/ld.so.conf(.d), which

Oh okay.

>I agree that this is less like amd64 vs x32 vs i386, and more like arm vs
>armel vs armhf (all 32-bit ARM and all mutually incompatible). I believe

Indeed.

>32-bit mips also has more than one ABI ("o32" and "n32") which might be

n32 is 64-bit, but from a short research, let’s not look at how
MIPS did this because it’s apparently convoluted and “historical
reasons” enough to make people despair (and apparently one can
compile an o32 file for MIPS64…).

But, yes, e_flags seems to be the way to go.

>(Of course, orthogonally, it would be nice if we could finally stop
>shipping shared libraries in the non-multiarch directories before trixie.)

Wouldn’t help here, considering that the old i386 has to be there
for legacy reasons so people might manually throw in, oh idk, an
OpenSSL 0.x and libstdc++5 even. But, yeah, M-A is nice now that
it works.

bye,
//mirabilos
-- 
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design.  <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)

Reply via email to