[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: