Is arm64 silicon now shipping to developers? AMD announced a kit for
end of March, but this has not materialized yet. Are there any other
options?
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
* Roland McGrath:
I can't see why you think --as-needed is fundamentally wrong or unnecessary.
It is fundamentally wrong because -lfoo means I demand that the
initializers of libfoo.so run, whether or not I called anything in it.
So it's more like static linking. 8-)
IMHO, the current
* Luke Kenneth Casson Leighton:
forcing people to sign NDAs to receive GPL source code is in direct
violation of the GPL license.
It is widely accepted that programmers can work on GPLed code under
NDA, even if the NDA is not imposed by the copyright owner. So this
depends on the terms of the
* Lennart Sorensen:
> There are a lot of 32bit powerpc chips still going into embedded systems
> being built today. They are not going away anytime soon.
Do they implement the ISA required by the existing Debian port?
> In other words, i don't think a s390x box will ever just die.
I'm sure “death” encompasses all events which might lead Debian to
lose access to relevant hardware. It's not just about faults with a
piece of equipment.
* Riku Voipio:
> On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote:
>> * Niels Thykier:
>>
>> > armel/armhf:
>> >
>> >
>> > * Undesirable to keep the hardware running beyond 2020. armhf VM
>> >s
* Luke Kenneth Casson Leighton:
> that is not a surprise to hear: the massive thrashing caused by the
> linker phase not being possible to be RAM-resident will be absolutely
> hammering the drives beyond reasonable wear-and-tear limits. which is
> why i'm recommending people try
* Niels Thykier:
> armel/armhf:
>
>
> * Undesirable to keep the hardware running beyond 2020. armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]
Fedora is facing an issue running armhf under virtualization on arm64:
* Ben Hutchings:
> On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
>> * Ben Hutchings:
>>
>> > If I recall correctly, glibc *will* provide both entry points, so there
>> > is no ABI break. But the size of time_t (etc.) exposed through libc-
>
* Ben Hutchings:
> If I recall correctly, glibc *will* provide both entry points, so there
> is no ABI break. But the size of time_t (etc.) exposed through libc-
> dev is fixed at glibc build time.
Is this a Debian-specific decision?
There has been a proposal upstream not to support 32-bit
* Steve McIntyre:
> The kernel is *basically* fixed now. Internally, data structures
> should now be safe. There are a small number places where 32-bit time
> is still a thing, but it's in hand. A number of syscalls, ioctls,
> etc. have needed updates for the user-kernel interface level.
XFS is
* Sam Hartman:
> Steve, you're presuming that we would not create a new soname for libc6
> on architectures where we want a new time ABI.
That seems to be a reasonable assumption because Debian would have to
use a different soname from upstream. glibc upstream does not seem
likely to change
* Ansgar:
> Arnd Bergmann writes:
>> On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer wrote:
>>> There's going to be a _TIME_BITS selector, similar to
>>> _FILE_OFFSET_BITS.
>>>
>>> There was a proposal to have only one API before, but I think the
* Noah Meyerhans:
> On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote:
>> > Significant performance impact has also been observed in less contrived
>> > cases (MariaDB and Postgres), but I don't have a repro to share.
>>
>> But indeed what counts is number on real workloads. It
* Ben Hutchings:
> On Mon, 2020-03-16 at 16:02 +0100, Arnd Bergmann wrote:
>> On Mon, Mar 16, 2020 at 3:47 PM Rich Felker wrote:
>>
>> > libtirpc is the replacement. I wasn't aware if uses libc-provided rpc
>> > headers (presumably only if they exist, since folks are using it fine
>> > on musl)
* Florian Weimer:
>> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>>in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
>
> I'm surprised to read this. ppc64el features prominently in the
> toolchain work I do (thou
* Emanuele Rocca:
> Hello!
>
> On 2023-11-24 01:34, Guillem Jover wrote:
>> According to https://bugs.debian.org/918914#73 there were no pending
>> toolchain issues related to this.
>
> That is correct. The GCC maintainers at Arm confirm that
> stack-clash-protection is supported on 32 bit too.
17 matches
Mail list logo
