Re: git: e7a629c851d7 - main - libmd, kern, stand: consolidate md5 implementations (NFC)
Date: Mon, 30 Sep 2024 20:32:21 UTC
On 9/30/24 15:04, Dima Panov wrote:
> Hello!
>
> On 30.09.2024 21:57, Herbert J. Skuhra wrote:
>> On Mon, 30 Sep 2024 05:36:04 +0200, Kyle Evans wrote:
>>>
>>> The branch main has been updated by kevans:
>>>
>>> URL:
>>> https://cgit.FreeBSD.org/src/commit/?id=e7a629c851d747772cc138efcb0418809ecdea55
>>>
>>> commit e7a629c851d747772cc138efcb0418809ecdea55
>>> Author: Kyle Evans <kevans@FreeBSD.org>
>>> AuthorDate: 2022-03-08 15:39:52 +0000
>>> Commit: Kyle Evans <kevans@FreeBSD.org>
>>> CommitDate: 2024-09-30 03:34:18 +0000
>>>
>>> libmd, kern, stand: consolidate md5 implementations (NFC)
>>> Reduce the number of md5c.c between the three of these from two
>>> to one
>>> by just reaching into the kernel build for both userland
>>> builds. The
>>> precedent for this already exists for sha2 in both cases.
>>> _libmd_ symbol privatization bits have been moved to sys/md5.h and
>>> md5.h remains to #include <sys/md5.h> for compatibility.
>>> This stops exporting MD5Pad() in the process because the kernel
>>> stopped
>>> exporting it in 502a35d60f4c. soversion is bumped accordingly.
>>> This also renames the libc version of stack_protector.c; it
>>> previously
>>> only worked by coincidence because .PATH ordering worked out
>>> such that
>>> we got the right one, but this is not the case anymore. Remove the
>>> landmine.
>>> PR: 280784 (exp-run)
>>> Reviewed by: allanjude, delphij
>>> Differential Revision: https://reviews.freebsd.org/D34497
>>> ---
>>> ObsoleteFiles.inc | 3 +
>>> lib/libc/Makefile | 2 +-
>>> lib/libc/md/Makefile.inc | 2 +-
>>> lib/libc/secure/Makefile.inc | 2 +-
>>> .../{stack_protector.c => libc_stack_protector.c} | 0
>>> lib/libcrypt/Makefile | 2 +-
>>> lib/libmd/Makefile | 3 +-
>>> lib/libmd/md5.h | 40 ---
>>> lib/libmd/md5c.c | 344
>>> ---------------------
>>> lib/libssp/Makefile | 2 +-
>>> stand/libsa/Makefile | 4 +-
>>> sys/kern/md5c.c | 23 +-
>>> sys/sys/md5.h | 42 +++
>>> 13 files changed, 72 insertions(+), 397 deletions(-)
>>
>> Don't run make delete-old-libs. :-)
>>
>> Does this change break building ports-mgmt/pkg (on arm64)?
>>
>> --- pkg ---
>> cc -o pkg add.o alias.o annotate.o audit.o autoremove.o check.o
>> clean.o config.o create.o delete.o event.o fetch.o globals.o info.o
>> install.o key.o lock.o main.o plugins.o query.o register.o repo.o
>> rquery.o search.o set.o shell.o shlib.o ssh.o stats.o triggers.o
>> update.o updating.o upgrade.o utils.o version.o which.o
>> -fstack-protector-strong -Wl,-Bstatic -Wl,-whole-archive
>> -L/usr/ports/ports-mgmt/pkg/work/pkg-1.21.3/libpkg -lpkg_flat
>> -Wl,-no-whole-archive -Wl,-Bdynamic -lelf -ljail -lssl -lcrypto
>> -larchive -lbz2 -lz -llzma -lprivatezstd -lm -pthread -lutil -lmd
>> -Wl,--export-dynamic
>> --- pkg-static ---
>> cc -o pkg-static add.o alias.o annotate.o audit.o autoremove.o check.o
>> clean.o config.o create.o delete.o event.o fetch.o globals.o info.o
>> install.o key.o lock.o main.o plugins.o query.o register.o repo.o
>> rquery.o search.o set.o shell.o shlib.o ssh.o stats.o triggers.o
>> update.o updating.o upgrade.o utils.o version.o which.o -static
>> -L/usr/ports/ports-mgmt/pkg/work/pkg-1.21.3/libpkg -lpkg_flat -lelf
>> -ljail -lssl -lcrypto -larchive -lbz2 -lz -llzma -lprivatezstd -lm
>> -pthread -lutil -lmd
>> ld: error: duplicate symbol: SHA256_Transform
>>>>> defined at sha256.c
>>>>> sha256.o:(SHA256_Transform) in archive
>>>>> /usr/lib/libcrypto.a
>>>>> defined at sha256c.c
>>>>> sha256c.o:(SHA256_Transform_resolver) in archive
>>>>> /usr/lib/libmd.a
>> cc: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>> *** [pkg-static] Error code 1
>>
>
This one is fixed in c02bc0aa0b22009e4bc, sorry about that. I forgot
that exp-runs are inherently x86, and there's some aarch64 specific bits
in here that shouldn't have been missed.
>
> also, this prevent to run anything builded with libmd.so.6
>
> $ pkg upg
> ld-elf.so.1: /usr/local/lib/compat/pkg/libmd.so.6: unsupported file layout
>
This one doesn't seem to make any sense, though. That message in
particular implies the elf header itself is damaged somehow.
Thanks,
Kyle Evans