| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Revise the version check from commit e14300816b (librhash: aligned_alloc
is not available with glibc < 2.15, 2024-02-14, v3.29.0-rc2~30^2).
Issue: #25679
|
| |
|
| |
|
|
|
|
|
| |
The declaration exists in `<stdlib.h>` but the compiler warns about
its allocation alignment attribute.
|
| |
|
|
|
|
|
|
| |
Extend commit 53048afa8d (librhash: Remove source fragments not needed
for CMake, 2016-11-03, v3.8.0-rc1~262^2~9) for fragments new after
updating to librhash 1.4.4.
|
|
|
|
|
| |
* upstream-librhash:
librhash 2023-07-14 (cfe77846)
|
| |
|
|
|
|
|
| |
`_LARGEFILE_SOURCE` is needed at least on SunOS i386 if compiler
extensions are not enabled.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
|
| |
|
| |
|
|
|
|
| |
Fixes: #20666
|
| |
|
| |
|
|
|
|
|
| |
* upstream-librhash:
librhash 2019-12-14 (75716b45)
|
| |
|
|
|
|
|
|
| |
In commit beb991110d (Remove now-unused code once used on IRIX,
2019-01-11, v3.14.0-rc1~167^2) we removed remnants of IRIX support.
Also remove remnants of MIPSpro compiler support.
|
|
|
|
|
| |
`sys/types.h` defines `int8_t` incorrectly as `char` which is unsigned.
Adjust ordering so `inttypes.h` defines it as `signed char` first.
|
|\
| |
| |
| |
| | |
9e07ffa4 librhash: Avoid signed left-shift overflow in sha256
|
| |
| |
| |
| |
| | |
Fix `rhash_sha256_final` to use unsigned integers for left shifting to
avoid the possibility of undefined overflow behavior.
|
| | |
|
|/
|
|
|
| |
* upstream-librhash:
librhash 2016-11-06 (de79828d)
|
| |
|
|
|
|
|
| |
Fix `rhash_md5_final` to use unsigned integers for left shifting to
avoid the possibility of undefined overflow behavior.
|
|
|
|
|
| |
We cannot fall back to the macro implementation because some call sites
may call it with an argument like `*ptr++` that has side effects.
|
| |
|
| |
|
|
|
|
|
| |
When we install using the bundled librhash source, notify users of its
license terms.
|
|
|
|
|
| |
Add '-w' or equivalent flag on compilers supporting it.
Tell MSVC to use its lowest warning level inside librhash sources.
|
|
|
|
|
|
|
|
| |
Update `ustd.h` to include KWSys Large File Support configuration so
that consistent stream libraries are used (on AIX with XL).
Add a `cm_rhash.h` header to include the CMake-provided copy of the
`rhash.h` header from CMake sources.
|
|
|
|
|
|
|
|
|
| |
We only need a subset of the hash algorithms supported by librhash.
Add preprocessor conditionals to remove source fragments that we do
not need. Write an alternative algorithm enumeration that matches
the indexing on our reduced array.
Also remove a few fragments outright.
|
|
* upstream-librhash:
librhash 2016-11-01 (d839a1a8)
|