Maamoun TK writes:
> fat-ppc.c uses getauxval() function to detect cpu features for Linux
> systems, the problem is that getauxval was introduced in glibc v2.16 which
> released in 2012 so in case fat option enabled, the build will fail for
> older glibc versions.
I agree it's not so nice that
On Sat, Dec 19, 2020 at 11:27 AM Niels Möller wrote:
> For the other one,
> https://git.lysator.liu.se/nettle/nettle/-/merge_requests/15 "Use signal
> to detect CPU features when getauxval() isn't available", can you
> explain for which systems is that needed? In the current code, you
> handle
Jeffrey Walton writes:
> Also see
> https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html.
It's not entirely clear to me how libtool versions maps to soname, but
from looking at GMP, I guess the number embedded in the soname is
current - age. So for gmp-6.1.2, the
On 2020-12-19 Niels Möller wrote:
> Amos Jeffries writes:
> > I would have though this needs a soname bump. Otherwise software built
> > to use bcrypt might try to link to the old version with same soname.
> My understanding is that one usually doesn't bump the soname when adding
> new
Jeffrey Walton writes:
> https://lists.lysator.liu.se/pipermail/nettle-bugs/2020/008762.html
If you don't use --enable-fat, there will be no runtime detection.
That's exactly as intended. Maybe your real problem is
"On other platforms, --enable-fat causes
SHA to be built even when the
On Sat, Dec 19, 2020 at 4:44 AM Niels Möller wrote:
>
> Amos Jeffries writes:
>
> > I would have though this needs a soname bump. Otherwise software built
> > to use bcrypt might try to link to the old version with same soname.
>
> My understanding is that one usually doesn't bump the soname
Amos Jeffries writes:
> I would have though this needs a soname bump. Otherwise software built
> to use bcrypt might try to link to the old version with same soname.
My understanding is that one usually doesn't bump the soname when adding
new functions.
I was trying to look at how it has been
On Fri, Dec 18, 2020 at 11:31 AM Niels Möller wrote:
>
> Maamoun TK writes:
>
> > It seems gcc for aarch64 doesn't support building 32-bit binaries, maybe we
> > should remove the check of ABI since 64-bit is the only option.
>
> Ok, that's a bit confusing. There's a command line flag for it,
Maamoun TK writes:
> I created a couple of merge requests in the repo, with those MRs merged I
> think the powerpc code is stable to be included in the upcoming version of
> nettle.
Thanks. I've merged the "Use 32-bit offset to load data".
For the other one,
On Sat, Dec 19, 2020 at 3:58 AM Niels Möller wrote:
>
> Jeffrey Walton writes:
>
> > It would be nice if cpu feature detection for fat builds made it into
> > the next release. It is easier than arm64, and it is needed to avoid
> > crashes at runtime.
>
> Can you be more specific on what the
Jeffrey Walton writes:
> It would be nice if cpu feature detection for fat builds made it into
> the next release. It is easier than arm64, and it is needed to avoid
> crashes at runtime.
Can you be more specific on what the problem is? I'm aware of only one
problem, and that's fat-arm.c
On 19/12/20 5:29 am, Niels Möller wrote:
Andreas Metzler writes:
it would not count as transition
https://release.debian.org/bullseye/freeze_policy.html#transition
...
* Support for bcrypt, contributed by Stephen R. van den Berg.
I would have though this needs a soname bump.
Michael Weiser writes:
> Porting over the basic
> IF_[LB]E mechanism from chacha-core-internal was easy and fixed up the
> first of the three interleaved blocks right away. For the other two I am
> still in the process of wrapping my head around how the interleaving
> works and how it would need
Hi Michael,
On Fri, Dec 18, 2020 at 8:00 PM Michael Weiser
wrote:
> qemu-user works nicely for aarch64_be. I used it to semi-natively
> compile a whole aarch64 userland. I could dust off pine64 board that is
> running that userland now for real-world testing if you like.
>
Thank you, I will
14 matches
Mail list logo
