Subject: Re: [alpine-devel] Dealing with multiple architectures (x86/x86_64)
From: Natanael Copa <ncopa@alpinelinux.org>
To: Alpine Development <alpine-devel@lists.alpinelinux.org>
In-Reply-To: <1290588497.6958.21.camel@ncopa-desktop.nor.wtbts.net>
References: <1290588497.6958.21.camel@ncopa-desktop.nor.wtbts.net>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 24 Nov 2010 11:50:57 +0100
Message-ID: <1290595857.6958.37.camel@ncopa-desktop.nor.wtbts.net>
Precedence: list
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Wed, 2010-11-24 at 09:48 +0100, Natanael Copa wrote:

> Other things we need resolve?

One more thing. Should we use /usr/lib64 or /usr/lib for x86_64? Even if
we support multilib in future we might want stuff things in /usr/lib32
and /usr/lib.

I originially thought we could symlink /usr/lib64 to /usr/lib but that
is not a good idea as it will confuse apk-tools. One package might
provide /usr/lib64/libfoo.so and other /usr/lib/libfoo.so. If we symlink
the dirs will apk-tools allow them overwrite each others files. We don't
want that.

I tried to put things in /usr/lib but gcc seems to insist in putting the
libstdc++, libgomp and other libs in /usr/lib/../lib64 and hardcode that
path in libtool files (*.la) so building c++ apps later breaks.

If we go for /usr/lib64 and no /usr/lib then we might need fix uclibc's
default search path and i assume there will be a bunch of packages that
needs --libdir fix.

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---