[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
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.


Reply to: