Re: multiarch/bi-arch status (ETA) question
David Wood <obsidian@panix.com> writes:
> On Fri, 8 Jul 2005, Goswin von Brederlow wrote:
>
>> 3rd party software is nearly completly 32bit and our 32bit libs are
>> already in the wrong place for rpath then. We can move
>> /emul/ia32-libs/lib/* to /lib/i486-linux/ (same for usr/lib in all
>> cases) without changing anything.
>>
>> We can also move /lib/* to /lib/x86_64-linux/* and adjust the /lib64
>> compatibility link without changing anything. That even works for
>> rpath.
>>
>> We can even link /lib/i486-linux -> ., placing the 32bit libs in /lib
>> to preserve rpath for both 32bit and 64bit.
>
> So, if I can go back to my original question: what are the blockers
> for a package maintainer who wants to get started with multiarch? It
> sounds like just some symlinks in base packages are all that need to
> change...
and I repeat my answere: gcc, binutils, libtools, automake,
autoconf. Toolchain issues.
By all means move your lib around in your package and try them
out. Recompile any rdepends your lib has. You will notice if something
has problems.
But I suggest not uploading those changes just yet. With all the
transitions going on currently risking breakage you didn't test for
would be bad.
FYI: If I can convince the dpkg maintainer then I will add
DEB_HOST_LIBDIR, DEB_HOST_LIB32DIR and DEB_HOST_LIB64DIR to
dpkg-architecture. That way sources can use those variables to build
and install their files already and when we decide the toolchain is
all ready for multiarch dpkg-architecture changes the paths.
MfG
Goswin
Reply to: