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