Re: Bug#980963: dpkg: Please add ARC architecture
Hi Guillem, On 5/27/21 8:50 PM, Guillem Jover wrote: > I discussed this today with Vineet on IRC in #debian-bootstrap, to try > to clarify some things, and this is the summary I think: > > * ARCv2 32-bit little-endian > >- The arch based on ARCv2 32-bit is going to be little-endian, and > ideally will be hard-float, but that's pending on a patch for gcc, > to flip the default from soft-float. From what I understand while > hard and soft-float are ABI compatible in the ISA and calling > convention sense, they are not ABI compatible in the object > linking sense, and while I guess this could also perhaps be lifted, > it's not currently the case. My concern is that adding the support > before the default has been switched might mean "ABI incompatible" > architectures if we cannot link objects. Vineet, mentioned that > they might be fine settling with soft-float in that case, even > with the performance penalty implied (in that case, personally I > think adding the -gnuhf triplet would be better, but I'd not be > going to be doing the work, so… :). The patch is supposed to be > sent upstream around next week or so. I'd prefer to wait what > ends up happening there, TBH, before committing the support to > dpkg. As I've mentioned I'm fine with committing it once it hits > upstream git though. >- The triplet would be «arc-linux-gnu», the Debian architecture > would be «arc». FWIW gcc patch is now in mainline (I've requested Claudiu for backport) 2021-06-02 46d04271a498 ARC: gcc driver default to hs38_linux Thx, -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Bug#980963: dpkg: Please add ARC architecture
Hi! On Mon, 2021-05-24 at 20:41:23 +, Vineet Gupta wrote: > On 3/26/21 10:39 AM, Vineet Gupta wrote: > > On 3/4/21 3:56 PM, Vineet Gupta wrote: > >>> Also just to make sure, the GNU triplets are: > >>> > >>> arc-linux-gnu > >>> arceb-linux-gnu > >>> No ABI modifiers (stuff like “eabi”) for the libc part (“gnu“) right? > >> Actually it seems we are missing hardfloat here: ARC glibc/gcc support > >> it very well and should be default for any reasonable performance. > >> > >> So I think we should add > >> arc-linux-gnuhf > >> arceb-linux-gnuhf > >> > >> BTW I have oce question: where does one select what default toggles to > >> build the entire software stack with (say -mcpu etc). Does this rely > >> on toolchain driver default to DRTH. One of my problems with > >> rebootstrap was gcc driver defaulting to our legacy cpu. I've cured it > >> there (and planning to upstream the gcc driver patch). > > So here's the lay of the land, apologies for the long email, and if > > some/most of below is not directly relevant to dpkg bug, but I'll > > provide the background so we are all on same page. > > > > We've had 3 revisions of the ISA and ensuing multiple processors in last > > 15 years: > > > > ISA Implementations/Processors (Linux capable) > > -- --- > > ARCompact ARC700 > > ARCv2 HS38x/HS48x > > ARCv3:32-bit HS58MP > > ARCv3:64-bit HS68MP > > > > - ARCompact is legacy and no new development needed including debian port. > > - Code for one ISA is not compatible with priors, mainly due to addition > > of new instructions. In fact given the configurability of the ISA itself > > (for better or worse), one could end up 2 non-compatible variants of > > same ISA (think double load/store instructions in ARCv2). But the port > > can assume the all encompassing super-set of the ISA as baseline. > > - ARCv3 is currently under development / pre-production but should be > > kept in mind as it is knocking on the door already. > > > > In terms of the ABI critical flavors: there's little/big endian and > > soft/hard-float. > > - Again big endian debian is not needed - mainly because of number of > > customer engagements and resourcing needed to support it > > - ARCv2 hard-float ABI is same as soft - FPU shares the same register > > file so the calling conventions are same. However the triplet is > > different arc-linux-gnuhf [1] as libraries for hard won't run on a > > soft-float system due to lack of emulation etc. > > - ARCv3 does have a dedicated FP register file so there's soft and hard ABIs > > > > So given all of this, I'd like to propose ARCv2 port with hard-float as > > baseline. We don't bother with Big-endian. A soft-float would be > > desirable for debugging and fall-back but not necessary from feature pov. > > > > I'm open to port names as maintainers feel appropriate - but stick with > > current triplets arc-gnu-linux / arc-gnu-linuxhf for ARCv2. > > For ARCv3, we could have arc64* / arc32* > > > > Please let me know if this makes sense. > > > > Once we agree, we can start off with requesting changes to GNU config > > project. > > Further to my msg on IRC, we've gotten pretty far along with ARC > rebootstrap [1]. It seems to build 151 packages before failing for perl > and I see similar outcome for riscv64 (which is weird as perl should be > supported there. > > Anyhow this is just a polite ping to make some progress on ARC. I discussed this today with Vineet on IRC in #debian-bootstrap, to try to clarify some things, and this is the summary I think: * ARCv2 32-bit little-endian - The arch based on ARCv2 32-bit is going to be little-endian, and ideally will be hard-float, but that's pending on a patch for gcc, to flip the default from soft-float. From what I understand while hard and soft-float are ABI compatible in the ISA and calling convention sense, they are not ABI compatible in the object linking sense, and while I guess this could also perhaps be lifted, it's not currently the case. My concern is that adding the support before the default has been switched might mean "ABI incompatible" architectures if we cannot link objects. Vineet, mentioned that they might be fine settling with soft-float in that case, even with the performance penalty implied (in that case, personally I think adding the -gnuhf triplet would be better, but I'd not be going to be doing the work, so… :). The patch is supposed to be sent upstream around next week or so. I'd prefer to wait what ends up happening there, TBH, before committing the support to dpkg. As I've mentioned I'm fine with committing it once it hits upstream git though. - The triplet would be «arc-linux-gnu», the Debian architecture would be «arc». * ARCv3 32/64-bit little-endian - These are still in the works, but there's already a GNU triplet «arc64-linux-gnu» in GNU
Re: Bug#980963: dpkg: Please add ARC architecture
Hi Guillem, On 3/26/21 10:39 AM, Vineet Gupta wrote: > On 3/4/21 3:56 PM, Vineet Gupta wrote: >>> Also just to make sure, the GNU triplets are: >>> >>> arc-linux-gnu >>> arceb-linux-gnu >>> No ABI modifiers (stuff like “eabi”) for the libc part (“gnu“) right? >> Actually it seems we are missing hardfloat here: ARC glibc/gcc support >> it very well and should be default for any reasonable performance. >> >> So I think we should add >> arc-linux-gnuhf >> arceb-linux-gnuhf >> >> BTW I have oce question: where does one select what default toggles to >> build the entire software stack with (say -mcpu etc). Does this rely >> on toolchain driver default to DRTH. One of my problems with >> rebootstrap was gcc driver defaulting to our legacy cpu. I've cured it >> there (and planning to upstream the gcc driver patch). > So here's the lay of the land, apologies for the long email, and if > some/most of below is not directly relevant to dpkg bug, but I'll > provide the background so we are all on same page. > > We've had 3 revisions of the ISA and ensuing multiple processors in last > 15 years: > > ISA Implementations/Processors (Linux capable) > -- --- > ARCompact ARC700 > ARCv2 HS38x/HS48x > ARCv3:32-bit HS58MP > ARCv3:64-bit HS68MP > > - ARCompact is legacy and no new development needed including debian port. > - Code for one ISA is not compatible with priors, mainly due to addition > of new instructions. In fact given the configurability of the ISA itself > (for better or worse), one could end up 2 non-compatible variants of > same ISA (think double load/store instructions in ARCv2). But the port > can assume the all encompassing super-set of the ISA as baseline. > - ARCv3 is currently under development / pre-production but should be > kept in mind as it is knocking on the door already. > > In terms of the ABI critical flavors: there's little/big endian and > soft/hard-float. > - Again big endian debian is not needed - mainly because of number of > customer engagements and resourcing needed to support it > - ARCv2 hard-float ABI is same as soft - FPU shares the same register > file so the calling conventions are same. However the triplet is > different arc-linux-gnuhf [1] as libraries for hard won't run on a > soft-float system due to lack of emulation etc. > - ARCv3 does have a dedicated FP register file so there's soft and hard ABIs > > So given all of this, I'd like to propose ARCv2 port with hard-float as > baseline. We don't bother with Big-endian. A soft-float would be > desirable for debugging and fall-back but not necessary from feature pov. > > I'm open to port names as maintainers feel appropriate - but stick with > current triplets arc-gnu-linux / arc-gnu-linuxhf for ARCv2. > For ARCv3, we could have arc64* / arc32* > > Please let me know if this makes sense. > > Once we agree, we can start off with requesting changes to GNU config > project. Further to my msg on IRC, we've gotten pretty far along with ARC rebootstrap [1]. It seems to build 151 packages before failing for perl and I see similar outcome for riscv64 (which is weird as perl should be supported there. Anyhow this is just a polite ping to make some progress on ARC. Thx, -Vineet [1] https://salsa.debian.org/vineetgarc/rebootstrap ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Bug#980963: dpkg: Please add ARC architecture
On 3/4/21 3:56 PM, Vineet Gupta wrote: >> Also just to make sure, the GNU triplets are: >> >> arc-linux-gnu >> arceb-linux-gnu >> No ABI modifiers (stuff like “eabi”) for the libc part (“gnu“) right? > > Actually it seems we are missing hardfloat here: ARC glibc/gcc support > it very well and should be default for any reasonable performance. > > So I think we should add > arc-linux-gnuhf > arceb-linux-gnuhf > > BTW I have oce question: where does one select what default toggles to > build the entire software stack with (say -mcpu etc). Does this rely > on toolchain driver default to DRTH. One of my problems with > rebootstrap was gcc driver defaulting to our legacy cpu. I've cured it > there (and planning to upstream the gcc driver patch). So here's the lay of the land, apologies for the long email, and if some/most of below is not directly relevant to dpkg bug, but I'll provide the background so we are all on same page. We've had 3 revisions of the ISA and ensuing multiple processors in last 15 years: ISA Implementations/Processors (Linux capable) -- --- ARCompact ARC700 ARCv2 HS38x/HS48x ARCv3:32-bit HS58MP ARCv3:64-bit HS68MP - ARCompact is legacy and no new development needed including debian port. - Code for one ISA is not compatible with priors, mainly due to addition of new instructions. In fact given the configurability of the ISA itself (for better or worse), one could end up 2 non-compatible variants of same ISA (think double load/store instructions in ARCv2). But the port can assume the all encompassing super-set of the ISA as baseline. - ARCv3 is currently under development / pre-production but should be kept in mind as it is knocking on the door already. In terms of the ABI critical flavors: there's little/big endian and soft/hard-float. - Again big endian debian is not needed - mainly because of number of customer engagements and resourcing needed to support it - ARCv2 hard-float ABI is same as soft - FPU shares the same register file so the calling conventions are same. However the triplet is different arc-linux-gnuhf [1] as libraries for hard won't run on a soft-float system due to lack of emulation etc. - ARCv3 does have a dedicated FP register file so there's soft and hard ABIs So given all of this, I'd like to propose ARCv2 port with hard-float as baseline. We don't bother with Big-endian. A soft-float would be desirable for debugging and fall-back but not necessary from feature pov. I'm open to port names as maintainers feel appropriate - but stick with current triplets arc-gnu-linux / arc-gnu-linuxhf for ARCv2. For ARCv3, we could have arc64* / arc32* Please let me know if this makes sense. Once we agree, we can start off with requesting changes to GNU config project. Thx, -Vineet [1] I don't see the arc hf explicitly @ https://git.savannah.gnu.org/cgit/config.git/tree/testsuite/config-sub.data ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Bug#980963: dpkg: Please add ARC architecture
Hi Guillem, On 3/4/21 5:55 AM, Guillem Jover wrote: Hi! On Sun, 2021-01-24 at 23:36:52 +0300, Alexey Brodkin wrote: Package: dpkg Version: 1.19.7ubuntu3-1~202101232134~ubuntu20.04.1 Severity: wishlist Tags: patch ARC architecture seem to match requirements for being added to the dpkg (https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F): * GNU triplet is there since 2013, see: https://git.savannah.gnu.org/cgit/config.git/commit/?id=986360de6e412cbed27dbe2dbfb64ddbd18e7370 * Binutils, GCC & uClibc support ARC for many years now, glibc 2.32 finally gained ARC support, see https://lists.gnu.org/archive/html/info-gnu/2020-08/msg2.html Sorry, didn't reply up to now due to the freeze, this not looking ready yet (as glibc is not even in Debian), but mostly because it slipped my mind, but that kind of blocks progress on your side. So let's see. :) Or, were you looking to get this included for bullseye? (I think this would not qualify, but, I think we might have done exceptions in such cases in the past.) We don' have a timelime, but the sooner the better ;-) I just want to flush out any missing pieces from ARC side of the things. Is the ABI fully stabilized now? It is. One thing to note is that ARC follows the 64-bit time_t/offsets, for 32-bit arches, enabled by glibc 2.32 (and that is the only glibc ABI we support). FWIW RV32 being th eonly other 32-bit arch (so far) to do that. I'm not sure if the debian ecosystem is prepared for this in general (for 32-bit arches). At the time fixes were neede in simplest of things like busybox so I'm wondering if what support if needed elsewhere or is it there already. >From 96523e18473b56743bf2f7d308c2d786f337e52e Mon Sep 17 00:00:00 2001 From: Alexey Brodkin Date: Sun, 24 Jan 2021 00:34:52 +0300 Subject: [PATCH] Add ARC architecture diff --git a/data/cputable b/data/cputable index 9f2a8e0e4..114a66ecb 100644 --- a/data/cputable +++ b/data/cputable @@ -20,6 +20,8 @@ i386 i686(i[34567]86|pentium)32 little ia64 ia64ia6464 little alpha alpha alpha.* 64 little amd64 x86_64 (amd64|x86_64) 64 little +arcarc arc.* 32 little +arceb arc arceb.* 32 big armeb armeb arm.*b 32 big arm arm arm.* 32 little arm64 aarch64 aarch64 64 little This looked incorrect, as it ends up not being a bijective relation, so the lines need to be swapped. The problem is that the comments do not explain this nor the test suite checks. So I improved both with the attached patches, which I'll commit into master once I open it up for 1.21.x. Thx. We are debian noobs so please feel free to massage them for correctness and/or feel free to ask us to rework. Also just to make sure, the GNU triplets are: arc-linux-gnu arceb-linux-gnu No ABI modifiers (stuff like “eabi”) for the libc part (“gnu“) right? Actually it seems we are missing hardfloat here: ARC glibc/gcc support it very well and should be default for any reasonable performance. So I think we should add arc-linux-gnuhf arceb-linux-gnuhf BTW I have oce question: where does one select what default toggles to build the entire software stack with (say -mcpu etc). Does this rely on toolchain driver default to DRTH. One of my problems with rebootstrap was gcc driver defaulting to our legacy cpu. I've cured it there (and planning to upstream the gcc driver patch). Thx, -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Bug#980963: dpkg: Please add ARC architecture
Hi!
On Sun, 2021-01-24 at 23:36:52 +0300, Alexey Brodkin wrote:
> Package: dpkg
> Version: 1.19.7ubuntu3-1~202101232134~ubuntu20.04.1
> Severity: wishlist
> Tags: patch
> ARC architecture seem to match requirements for being added to the dpkg
> (https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F):
>
> * GNU triplet is there since 2013,
>see:
> https://git.savannah.gnu.org/cgit/config.git/commit/?id=986360de6e412cbed27dbe2dbfb64ddbd18e7370
> * Binutils, GCC & uClibc support ARC for many years now,
>glibc 2.32 finally gained ARC support, see
> https://lists.gnu.org/archive/html/info-gnu/2020-08/msg2.html
Sorry, didn't reply up to now due to the freeze, this not looking
ready yet (as glibc is not even in Debian), but mostly because it
slipped my mind, but that kind of blocks progress on your side.
So let's see. :)
Or, were you looking to get this included for bullseye? (I think this
would not qualify, but, I think we might have done exceptions in such
cases in the past.)
Is the ABI fully stabilized now?
> >From 96523e18473b56743bf2f7d308c2d786f337e52e Mon Sep 17 00:00:00 2001
> From: Alexey Brodkin
> Date: Sun, 24 Jan 2021 00:34:52 +0300
> Subject: [PATCH] Add ARC architecture
> diff --git a/data/cputable b/data/cputable
> index 9f2a8e0e4..114a66ecb 100644
> --- a/data/cputable
> +++ b/data/cputable
> @@ -20,6 +20,8 @@ i386i686(i[34567]86|pentium)
> 32 little
> ia64 ia64ia6464 little
> alphaalpha alpha.* 64 little
> amd64x86_64 (amd64|x86_64) 64 little
> +arc arc arc.* 32 little
> +arcebarc arceb.* 32 big
> armebarmeb arm.*b 32 big
> arm arm arm.* 32 little
> arm64aarch64 aarch64 64 little
This looked incorrect, as it ends up not being a bijective relation,
so the lines need to be swapped. The problem is that the comments do
not explain this nor the test suite checks. So I improved both with the
attached patches, which I'll commit into master once I open it up for
1.21.x.
Also just to make sure, the GNU triplets are:
arc-linux-gnu
arceb-linux-gnu
No ABI modifiers (stuff like “eabi”) for the libc part (“gnu“) right?
Thanks,
Guillem
From f5cae4f8fc4ef67ec5e26dffeb3b3c540949f554 Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Mon, 25 Jan 2021 05:37:06 +0100
Subject: [PATCH] test: Add unit tests for architecture bijective mapping
property
The architectures need to have the bijective property when converting
back and forth from the Debian arch name to the GNU triplet. Enforce
this in the test suite to make it easier to guarantee this when adding
new architectures to the tables.
---
scripts/t/Dpkg_Arch.t | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t
index a3a9e6fee..4f26778aa 100644
--- a/scripts/t/Dpkg_Arch.t
+++ b/scripts/t/Dpkg_Arch.t
@@ -16,7 +16,7 @@
use strict;
use warnings;
-use Test::More tests => 16836;
+use Test::More tests => 17914;
use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
debarch_eq debarch_is debarch_is_wildcard
@@ -24,9 +24,12 @@ use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
debarch_to_abiattrs debarch_to_cpubits
debarch_list_parse
debtuple_to_debarch gnutriplet_to_debarch
+debtuple_to_gnutriplet gnutriplet_to_debtuple
get_host_gnu_type
get_valid_arches));
+my @valid_arches = get_valid_arches();
+
sub get_valid_wildcards
{
my %wildcards;
@@ -37,7 +40,7 @@ sub get_valid_wildcards
any-any-any-any
);
-foreach my $archname (get_valid_arches()) {
+foreach my $archname (@valid_arches) {
my @tuple = debarch_to_debtuple($archname);
my @wildcards_arch = (
@@ -174,7 +177,17 @@ is(gnutriplet_to_debarch(undef), undef, 'undef gnutriplet');
is(gnutriplet_to_debarch('unknown-unknown-unknown'), undef, 'unknown gnutriplet');
is(gnutriplet_to_debarch('x86_64-linux-gnu'), 'amd64', 'known gnutriplet');
-is(scalar get_valid_arches(), 539, 'expected amount of known architectures');
+foreach my $arch (@valid_arches) {
+my @tuple = debarch_to_debtuple($arch);
+is(debtuple_to_debarch(@tuple), $arch,
+ "bijective arch $arch to tuple @tuple");
+
+my $triplet = debtuple_to_gnutriplet(@tuple);
+is_deeply([ gnutriplet_to_debtuple($triplet) ], \@tuple,
+ "bijective triplet $triplet to tuple @tuple");
+}
+
+is(scalar @valid_arches, 539, 'expected amount of
Re: Bug#980963: dpkg: Please add ARC architecture
Hi Alexey, On Wed, Mar 03, 2021 at 07:35:39PM +, Alexey Brodkin wrote: > Well not sure why there's a dependency on glibc as w/o ARC target support > in dpkg nothing could be built for ARC. For example I did built Binutils > with fixed dpkg. There is no hard dependency in that direction. Just pushback on adding lots of Debian architectures that never really take off. For instance, or1k was never fully bootstrapped. It'll be merged. Just not now. (Not speaking as a dpkg maintainer here, just telling what will happen from experience.) > > Things that often need architecture-specific support for a new > > architecture include: > > * guile-X.Y (cross support) > > * libgc > > Above 2 are not [yet] supported but seems to be easy ones. guile-X.Y is quite mechanical, yes. libgc can be a little more difficult. > > * libxcrypt (symbols) > > Not sure about "libxcrypt" (whatver that means), but libgpg-error supports > ARC since 2018, see: https://tracker.debian.org/pkg/libxcrypt > https://github.com/gpg/libgpg-error/commit/48c8f8ddfc80551db7615e1eb3555c1dc3f6a657 This should be unneeded. libgpg-error now defaults to force_use_syscfg=no and no longer needs arch-specific changes. > > * nspr > > Done in 2019, see > https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76 Great. > > * openssl (packaging) > > Not sure what needs to be done here as I know we build a lot of complex > things with OpenEmbedded/Yocto and openssl libs are being built for sure. https://sources.debian.org/src/openssl/1.1.1j-1/debian/patches/debian-targets.patch/ > > Are any of these fixed or confirmed working for arc? > > See above, quite some do work. Impressive. Some work is left. What also is left is demonstrating that it actually works. It seems that Vineet is working on integrating it. Helmut ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Bug#980963: dpkg: Please add ARC architecture
Hi Helmut, > On Sat, Feb 06, 2021 at 07:25:35PM +, Alexey Brodkin wrote: > > Any chances to get updates on this one some time soon? > > No. The triplet cannot be changed once added. Therefore, the addition is > often deferred. The absence of the triplet can easily be worked around. > A bootstrap can be prototyped already. A major missing piece though is > glibc 2.32 being packaged in Debian. That likely is a prerequisite for > resolving this bug. Well not sure why there's a dependency on glibc as w/o ARC target support in dpkg nothing could be built for ARC. For example I did built Binutils with fixed dpkg. > Things that often need architecture-specific support for a new > architecture include: > * guile-X.Y (cross support) > * libgc Above 2 are not [yet] supported but seems to be easy ones. > * libxcrypt (symbols) Not sure about "libxcrypt" (whatver that means), but libgpg-error supports ARC since 2018, see: https://github.com/gpg/libgpg-error/commit/48c8f8ddfc80551db7615e1eb3555c1dc3f6a657 > * nspr Done in 2019, see https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76 > * openssl (packaging) Not sure what needs to be done here as I know we build a lot of complex things with OpenEmbedded/Yocto and openssl libs are being built for sure. > Are any of these fixed or confirmed working for arc? See above, quite some do work. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Bug#980963: dpkg: Please add ARC architecture
On Wed, 3 Mar 2021 19:04:36 +0100 Helmut Grohne wrote: > On Sat, Feb 06, 2021 at 07:25:35PM +, Alexey Brodkin wrote: > > Any chances to get updates on this one some time soon? > > No. The triplet cannot be changed once added. Therefore, the addition is > often deferred. The absence of the triplet can easily be worked around. > A bootstrap can be prototyped already. A major missing piece though is > glibc 2.32 being packaged in Debian. That likely is a prerequisite for > resolving this bug. > > Things that often need architecture-specific support for a new > architecture include: > * guile-X.Y (cross support) > * libgc > * libxcrypt (symbols) > * nspr > * openssl (packaging) > > Are any of these fixed or confirmed working for arc? > > I suggest that you coordinate with Vineet Gupta as he is already working > on this. The current WIP is at https://github.com/foss-for-synopsys-dwc-arc-processors/rebootstrap.git The deal breaker is glibc support since debian is at 2.31 while ARC port was merged in 2.32. So here we patch in the entire ARC port :-) ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Bug#980963: dpkg: Please add ARC architecture
On Sat, Feb 06, 2021 at 07:25:35PM +, Alexey Brodkin wrote: > Any chances to get updates on this one some time soon? No. The triplet cannot be changed once added. Therefore, the addition is often deferred. The absence of the triplet can easily be worked around. A bootstrap can be prototyped already. A major missing piece though is glibc 2.32 being packaged in Debian. That likely is a prerequisite for resolving this bug. Things that often need architecture-specific support for a new architecture include: * guile-X.Y (cross support) * libgc * libxcrypt (symbols) * nspr * openssl (packaging) Are any of these fixed or confirmed working for arc? I suggest that you coordinate with Vineet Gupta as he is already working on this. Helmut ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
