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
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
Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Vineet, On Wed, Feb 24, 2021 at 08:17:53PM +, Vineet Gupta wrote: > Checking in to see if things have change since my last posting on this > topic. Appreciated. I would have forgotten about arc. > Is glibc 2.32 now packaged for debian so we can attempt ARC rebootstrap ? Unfortunately, no. Debian has started freezing in preparating of the bullseye release. Only up to version 2.31 is packaged and Aurelien seems a little busy these days. If I recall correctly, 2.32 drops some backwards compatibility stuff that Debian still relies on $somewhere, but is transitioning away already. So it's not just dumping 2.32 together with the 2.31 packaging in experimental. Before that happens, there is little I can do to help. With 2.31, we still get: | checking sysdep dirs... configure: error: The arc is not supported. I'm still interested in supporting the arc bootstrap. Please get back with me when we can move on. You can check Debian's glibc version at https://tracker.debian.org/pkg/glibc at any time in the version column. Helmut ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Vineet, On Wed, Aug 26, 2020 at 02:39:53PM +, Vineet Gupta wrote: > Following up as ARC glibc port was merged upstream in 2.32. Can we now give > rebootstrap a spin for ARC Debian enablement. That's great news. Unfortunately, it's not that easy yet. rebootstrap requires the relevant software to be packaged for Debian and the glibc packaging has only reached 2.31 yet. 2.32 is not even in experimental yet. Trying rebootstrap with an experimental glibc is not entirely trivial, but possible. Aurelien (Cced via d-glibc@l.d.o), are there plans to upload 2.32 to experimental anytime soon? Alternatively, can we segregate the relevant diff between 2.31 and 2.32 and apply it to the unstable package without bumping the version? Helmut ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Alexey, On Thu, Mar 26, 2020 at 12:53:45PM +, Alexey Brodkin wrote: > Sorry for this stupid question but I'm not very familiar with use-cases for > libatomic-ops so would like to get some more clarification on what's needed > here. > > I know that GCC has quite a few built-ins for atomic ops and we do implement > them. > I'm adding our GCC maintainer (Claudiu) in the Cc so he may jump in if needed. One part of the question here is "why do we need libatomic-ops?". The answer to that is, because libgc uses it and libgc is used by e.g. gcc, gnutls, guile, and make. Possibly, some of these could be built without libgc, but this is how they are packaged for Debian at present. Package dependencies currently say that we need libatomic-ops. The other part is "what is missing in libatomic-ops"? If you look at a more recent implementation, such as riscv, you see that it basically says "trust gcc". So I guess all you need here is an arc-specific implementation that says "gcc knows what it is doing, use its primitives". Given sufficient work, I guess libatomic-ops could be removed in favour of using the gcc built-ins directly. Not sure whether that'd fly with libgc upstream though. So no, this is not a stupid question. Thank you for asking. Helmut ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Alexey, On Thu, Mar 26, 2020 at 11:51:44AM +, Alexey Brodkin wrote: > I guess almost all of the packages you mentioned already have > needed improvements for ARC. I didn't mean to imply that anything was missing. I just mentioned those that usually need work without having checked any. > 2. libgpg-error has ARC support since v1.33, see: > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=48c8f8ddfc80 This is only the native-support. For rebootstrap, we also need cross build support, i.e. recording the generated lock-obj header (once glibc is done). > And only for "libatomic-ops" & "guile" nothing has been done yet so if > there's something > that really needs to be done please let us know. I suggest that you focus on libatomic-ops then. And on glibc of course. I guess that the other issues are easily solvable when they arise. Helmut ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Vineet, On Wed, Mar 25, 2020 at 05:25:58PM -0700, Vineet Gupta wrote: > ARC glibc is still in works, but assuming that will happen in near future what > other upstream prerequisites are needed. The obvious ones would be Linux > kernel, > gcc, binutils: all 3 of which are supported for ARC. From a quick glance at > debian > wiki pages, I presume *bootstrap is mostly done native, so needs qemu ? > (full/user > emulation ? And does qemu need to be upstream too ? Given that I ran into the glibc issue, I can tell that at least rudimentary arc support support is already available in Debian unstable for binutils, linux and gcc. (Otherwise, I would not have come as far as glibc.) Once glibc is in place, work can proceed on the Debian side. guile, libatomic-ops, libffi, libgpg-error and nspr ususally need a little upstream support. dpkg, gmp, openssl, and perl usually need Debian-specific changes. I'd recommend looking into libatomic-ops and libffi early. The other packages are usually simple. The aim of rebootstrap is to create a package set for essential + build-essential using cross builds without using any qemu. Beyond that point, you'd switch to native building. Unless real hardware is available, you'd need qemu after the reboostrap phase. Whether you use full or user emulation is your choice, but I guess that you can speed up builds using user emulation, because it allows you to mix and match binaries. When you upstream your qemu is also your choice. Please get in touch with me once a suitable glibc is packaged for Debian unstable or experimental. Please use debian-cr...@lists.debian.org or irc.oftc.net #debian-bootstrap at that point. Alternatively, package a glibc locally (like Arnd did). Helmut ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Arnd, On Thu, Feb 20, 2020 at 09:31:32AM +0100, Arnd Bergmann wrote: > > > How do I build a latest RISCV 32-bit kernel + userland - do you have > > > a buildroot branch somewhere that I can build / test with qemu ? > > > > Maybe a bit off topic - there is such QEMU and Yocto/OE based test > > sandbox for ARM32: > > > > https://github.com/lmajewski/meta-y2038 > > > > (the README provides steps for setup). > > (continuing off-topic, with debian-arm and Helmut on Cc) > > Would it be possible to take a snapshot of your glibc tree and > start testing this out with debian-rebootstrap [1]? This is exacty what rebootstrap is for. You should be able to experiment with different ABIs without committing to a particular ABI. You can fiddle with such aspects and then cross build a pile of around 120 Debian packages. That should uncover the most significant problems. You don't even have to change the GNU triplet. You can just create an incompatible throw-away port with an existing architecture name as rebootstrap refuses to reuse any existing binary packages for the host architecture. If you want to pursue that route, get in touch with debian-cr...@lists.debian.org or #debian-bootstrap on irc.oftc.net. The usual route is forking the rebootstrap.git repository. You just hack up your toolchain modifications an retry the bootstrap from scratch until you are satisfied. Be prepared to put up with half a day or a day of CPU time for a single run. Don't hesitate to ask for help if you have undecipherable build failures. Balint Reczey has done something quite similar to what you're up to: He attempted creating ports that are instrumented with sanitizers. Since I saw arc in the subject, I also threw arc at rebootstrap. Turns out that glibc 2.30 does not yet cover arc and using unpackaged versions of glibc is non-trivial for rebootstrap, so I cannot do much about that. Once arc support is in a released version of glibc, I'd be happy to be pinged about it. Helmut ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
