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

Re: Multiarch and ABI support

(Resending to debian-arm as mailto: addreces I sent had some typo)

Dear Steve,

2010/7/24, Steve Langasek <vorlon@debian.org>:
> On Mon, Jul 19, 2010 at 07:02:32PM +0100, Hector Oron wrote:
>> 2010/7/18 Steve Langasek <vorlon@debian.org>:

>> AFAICS `dpkg' relais on -dumpmachine from `gcc'
>> scripts/Dpkg/Arch.pm:68:        my $gcc_host_gnu_type = `\${CC:-gcc}
>> -dumpmachine`;

> It wouldn't.  I don't see a compelling reason for dpkg to do this at all.
> Your quote shows that dpkg *does* do this today, which I didn't remember
> before this conversation, but that's not an explanation for *why* it does -
> as opposed to dpkg directly recording what its current architecture is.

I am not `dpkg' maintainer, nor I did such change, so *why* it does
that I do not know, but surely there is a reason which stands valid or
it is outdated.

> Calling this something other than "architecture" ("ABI", "subarch", etc) is
> quite beside the point - we still need a distinct name for any files we
> intend to ship in the main archive.

Yes, I agree, something that won't get easily outdated should work, or
even better relocatable (non-hardcoded) names would be best. You are
probably aware all changes this means for Debian infrastructure.

>> As I had stated previously my though on another thread [2], there are
>> two different cases mixed on `multiarch':
>> a) Co-installing libraries (in x86 world, with compatible ABI) which
>> main purpose it is to be able to run `non-free' software.
>> b) Co-building, which it is the part that affects me the most and can
>> be easily solved using sysroot switch on GCC, without any upstream
>> changes.

>> Using sysroot approach you might be able to co-install foreign (other
>> arches) libraries into the sysroot for case a) - it even lets the user
>> have multiple systems with same ABI and architecture, but with
>> different libraries (in the case you want to cross build non Debian
>> systems).

> sysroot is irrelevant to what multiarch aims to achieve.

Sorry, I think I have not yet understand you. Would you mind to expand
your point here?

While sysroot is just a tool which it is probably very helpful on
multiarch design. What is orthogonal on sysroot and multiarch are the
hardcoded paths (/usr/lib/<triplet>) which we had discussed above that
are wrong.

Sysroot is everybody's way to cross compile in world but us (Debian)
if multiarch aims to be a fit-all solution it should be relevant, if
it is not, either you might misunderstood sysroot rationale or I just
should be stop loosing time on multiarch. Maybe multiarch just needs
to setup sysroot=/ and change FHS for upstreams to follow, which it is
not something it happens in couple months.

Kind regards,
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html

Reply to: