Re: Can't build evbarm
> Now that Christos moved the function around, that declaration in the > header is just noise, and could be removed. Thank you for fixing this. Adam
Re: Can't build evbarm
On Sat, Jan 27, 2024 at 03:33:06PM +0700, Robert Elz wrote: > Now that Christos moved the function around, that declaration in the > header is just noise, and could be removed. Yes, that would be consistent then (but isn't it against the new style rules?) Martin
Re: Can't build evbarm
Date:Sat, 27 Jan 2024 09:11:58 +0100 From:Martin Husemann Message-ID: <20240127081158.gb16...@mail.duskware.de> | Because the declaration in the relevant header is already there, Now that Christos moved the function around, that declaration in the header is just noise, and could be removed. kre
Re: Can't build evbarm
Date:Fri, 26 Jan 2024 21:09:30 +0100 From:Adam Message-ID: <7be03ef0-a516-4102-951a-be8a0d468...@netbsd.org> | Why not just change the order? Christos has done that now, so I guess that more or less "fixes" the issue. I didn't want to do it that way, as it still leaves _LIBC_INTERNAL unset when building the parts of libc which go in the tools libcompat and one day, we're likely to have the same problem again, for the same reason, and I would have preferred to have the Makefile(s) for the tools libcompat build fixed instead, which would have also solved it. If the "static" hadn't been commented out for MD2Transform() this would certainly have been the right way (then there would have not been any prototype in any md2.h, _LIBC_INTERNAL or not) - either that or just adding a prototype to the .c file (sometimes that is necessary, as there can be 2 such functions which refer to each other, they both can't come first). In this case moving it, rather than adding a prototype is better, as the prototype would have needed another commented out "static" in it, to match the actual function, and that would have been overboard. In any case, my strategy had been to leave md2.c as it was, and attempt to get someone who knew how, to fix the Makefile so that _LIBC_TNTERNAL was defined (those functions are still part of a libc lookalike, even when in libcompat so deserve to be compiled the same way as in libc). I guess we just wait for the next time. kre
Re: Can't build evbarm
On Fri, Jan 26, 2024 at 09:09:30PM +0100, Adam wrote: > Simple and elegant. No hacks involved. Because the declaration in the relevant header is already there, and the order does not matter. But the #ifdef around the declaration needs to do the right thing. No need to move things around and its like this code is compiled everwhere else where it is used. Martin
Re: Can't build evbarm
> The right way is to put an appropriate -D in the right place in
> a CPPFLAGS definition in some Makefile or other - I tried to do
> it that way, but obviously not correctly, as the build didn't
> add the -D to the compile line - when I start looking at modern
> Makefiles my eyes just glaze over at the absurdity of the whole
> system as it is now (makefiles used to be a nice simple declarative
> specification of what depended on what, and how to build things,
> they have turned into a truly baroque and horrid programming language
> instead ... but that rant is off topic here.)
>
> So, what it needs is for someone to work out how to pass -D_LIBC_INTERNAL
> to the tools libcompat build, and fix things properly.
Why not just change the order?
This:
void MD2Update() {
MD2Transform();
}
void MD2Transform() {
}
doesn't compile.
This:
void MD2Transform() {
}
void MD2Update() {
MD2Transform();
}
compiles fine.
Simple and elegant. No hacks involved.
Kind regards,
Adam
Re: Can't build evbarm
On Sat, Jan 27, 2024 at 02:49:09AM +0700, Robert Elz wrote: > | It doesn't accept implicit function declarations. > > Yes, that's fine - you do not need to explain the issue, we all > understand that --- but there's supposed to be a prototype for > the function, it isn't intended to be implicit. Robert is right, the missing prototype is a bug in the makefiles. Adam: that your clang host compiler requires a newer C standard than C99 for building tools is another bug, you can probably add something like -std=c99 to HOST_CFLAGS / HOST_CXXFLAGS to fix that. Martin
Re: Can't build evbarm
Date:Fri, 26 Jan 2024 16:54:13 +0100 From:Adam Message-ID: | The above is a hack. IMHO my fix is a cleaner one. The question is really why we're building libc functions (for the tools libcompat) without _LIBC_INTERNAL defined. I think it should be. | Anyway, the problem seems to be related to Clang, Not really, the issue is more what flags are passed to the compiler, what is a warning, and what is treated as an error. It looks as if the tool build is just treating this as a warning (using gcc - or whataver the native host compiler is) and your clang is not. That's all understandable, we have little control of host compilers, they can do whatever they normally do, and we just need to live with it (the tools build cannot really start giving compiler specific options to turn on, or off, warnings or errors). | It doesn't accept implicit function declarations. Yes, that's fine - you do not need to explain the issue, we all understand that --- but there's supposed to be a prototype for the function, it isn't intended to be implicit. That's what we really need to fix. My "hack" was doing that in a relevant include file, but you're right, that is a hack, and wouldn't fix any similar issues that might arise in some other function some other time (protototypes for public functions (which this one shouldn't be, apparently, but is) are gradually moving out of .c files and into .h files instead). The right way is to put an appropriate -D in the right place in a CPPFLAGS definition in some Makefile or other - I tried to do it that way, but obviously not correctly, as the build didn't add the -D to the compile line - when I start looking at modern Makefiles my eyes just glaze over at the absurdity of the whole system as it is now (makefiles used to be a nice simple declarative specification of what depended on what, and how to build things, they have turned into a truly baroque and horrid programming language instead ... but that rant is off topic here.) So, what it needs is for someone to work out how to pass -D_LIBC_INTERNAL to the tools libcompat build, and fix things properly. kre
Re: Can't build evbarm
On Fri, Jan 26, 2024 at 04:42:43PM +0100, Adam wrote: > % cat /tmp/pkgsrc/obj.aarch64/tools/compat/md2.d [..] > md2.o: > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/assert.h > md2.o: /dist/src/tools/compat/md2.h > md2.o: /dist/src/tools/compat/../../include/md2.h OK, so that wasn't it. Martin
Re: Can't build evbarm
> | Correct, _LIBC_INTERNAL is not defined for tools/compat.
>
> I wonder what the difference is between your environment, and
> a standard build on a NetBSD host.
>
> | MD2Transform() must be defined for MD2Update() in lib/libc/hash/md2/md2.c.
>
> Yes, that I understand.
>
> Try the following patch to src/tools/compat/md2.h and see if that helps
> (though I think there should be a better way).
>
> kre
>
> Index: md2.h
> ===
> RCS file: /cvsroot/src/tools/compat/md2.h,v
> retrieving revision 1.2
> diff -u -r1.2 md2.h
> --- md2.h 27 Oct 2003 00:12:43 - 1.2
> +++ md2.h 25 Jan 2024 19:59:10 -
> @@ -1,5 +1,8 @@
> /* $NetBSD: md2.h,v 1.2 2003/10/27 00:12:43 lukem Exp $ */
>
> /* We unconditionally use the NetBSD MD2 in libnbcompat. */
> +#ifndef _LIBC_INTERNAL
> +#define _LIBC_INTERNAL
> +#endif
> #include "nbtool_config.h"
> #include "../../include/md2.h"
The above is a hack. IMHO my fix is a cleaner one.
Anyway, the problem seems to be related to Clang, which in my case is the
native compiler. It doesn't accept implicit function declarations. Consider the
following example:
-
// file zz.c
void MD2Update() {
MD2Transform();
}
void MD2Transform() {
}
-
% clang -std=c89 -c zz.c
zz.c:5:6: error: conflicting types for 'MD2Transform'
5 | void MD2Transform() {
| ^
zz.c:2:3: note: previous implicit declaration is here
2 | MD2Transform();
| ^
1 error generated.
% clang -std=gnu99 -c zz.c
zz.c:2:3: error: call to undeclared function 'MD2Transform'; ISO C99 and later
do not support implicit function declarations [-Wimplicit-function-declaration]
2 | MD2Transform();
| ^
zz.c:5:6: error: conflicting types for 'MD2Transform'
5 | void MD2Transform() {
| ^
zz.c:2:3: note: previous implicit declaration is here
2 | MD2Transform();
| ^
2 errors generated.
% gcc -c zz.c
zz.c:5:6: warning: conflicting types for 'MD2Transform'; have 'void()'
5 | void MD2Transform() {
| ^~~~
zz.c:2:3: note: previous implicit declaration of 'MD2Transform' with type
'void()'
2 | MD2Transform();
| ^~~~
Of course it will fail with -Werror. And my guess it the release engineering
builds are using NOGCCERROR=yes, as the warning shows up in the logs, like here
http://releng.netbsd.org/builds/HEAD/202401252350Z/evbarm-aarch64.build (or any
other architecture):
/home/source/ab/HEAD/src/tools/compat/../../lib/libc/hash/md2/md2.c: In
function 'MD2Update':
/home/source/ab/HEAD/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4:
warning: implicit declaration of function 'MD2Transform'
[-Wimplicit-function-declaration]
MD2Transform(context); /* resets i */
^~~~
/home/source/ab/HEAD/src/tools/compat/../../lib/libc/hash/md2/md2.c: At top
level:
/home/source/ab/HEAD/src/tools/compat/../../lib/libc/hash/md2/md2.c:163:1:
warning: conflicting types for 'MD2Transform'
MD2Transform(MD2_CTX *context)
^~~~
/home/source/ab/HEAD/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4:
note: previous implicit declaration of 'MD2Transform' was here
MD2Transform(context); /* resets i */
^~~~
Re: Can't build evbarm
> My guess is a system header (md2.h?) being found unintendly (either only > on macOS or in case of NetBSD having the "right" bits in the system header). > > Adam, can you check the *.d file in your objdir correspoding to the failing > compiler invocation and show us what system headers are mentioned there? > > Martin % cat /tmp/pkgsrc/obj.aarch64/tools/compat/md2.d md2.o: /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c md2.o: md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_symbol_aliasing.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_posix_availability.h md2.o: /dist/src/tools/compat/namespace.h md2.o: nbtool_config.h md2.o: /dist/src/tools/compat/compat_defs.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/types.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/appleapiopts.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/machine/types.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/arm/types.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/arm/_types.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_int8_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_int16_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_int32_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_int64_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_u_int8_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_u_int16_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_u_int32_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_u_int64_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_intptr_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_uintptr_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/machine/_types.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_pthread/_pthread_types.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/machine/endian.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/arm/endian.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_endian.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libkern/_OSByteOrder.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libkern/arm/OSByteOrder.h md2.o: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/include/stdint.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdint.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_types/_uint8_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_types/_uint16_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_types/_uint32_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_types/_uint64_t.h md2.o: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_types/_intmax_t.h md2.o:
Re: Can't build evbarm
On Fri, Jan 26, 2024 at 03:03:24AM +0700, Robert Elz wrote: > Date:Thu, 25 Jan 2024 20:12:36 +0100 > From:Adam > Message-ID: > > | Correct, _LIBC_INTERNAL is not defined for tools/compat. > > I wonder what the difference is between your environment, and > a standard build on a NetBSD host. My guess is a system header (md2.h?) being found unintendly (either only on macOS or in case of NetBSD having the "right" bits in the system header). Adam, can you check the *.d file in your objdir correspoding to the failing compiler invocation and show us what system headers are mentioned there? Martin
Re: Can't build evbarm
>> My setup is cross-building NetBSD on macOS.
>>
>> Adam
>
> I’ve have issues building on macOS (since Big Sur) where the target is amd64,
> arm64 or i386. The tools for CTF do not work properly. Lukem put some fixes
> in place but I’m not sure if they were fully resolved. You might get away
> with building with 1 thread IIRC.
> Can you paste the errors you are getting please?
>
>
> Kind regards
> Chris
The build fails rather quickly.
===> build.sh command:./build.sh -N2 -U -j12 -X/dist/xsrc -aaarch64
-mevbarm -T/dist/tools.aarch64 -O/tmp/pkgsrc/obj.aarch64
-D/tmp/pkgsrc/destdir.aarch64 -R/dist/releases -V MAKECONF=/dist/mk.conf -V
HOST_CC=/usr/bin/clang -V HOST_CXX=/usr/bin/clang++ -V HOST_CFLAGS=-O2
-mcpu=native -fno-stack-protector -V HOST_CXXFLAGS=-O2 -mcpu=native
-fno-stack-protector release
===> build.sh started:Thu Jan 25 20:02:12 CET 2024
===> NetBSD version: 10.99.10
===> MACHINE: evbarm
===> MACHINE_ARCH:aarch64
===> Build platform: Darwin 23.3.0 arm64
===> HOST_SH: /bin/sh
===> getenv MAKECONF: /dist/mk.conf
===> MAKECONF file: /dist/mk.conf
#objdir /tmp/pkgsrc/obj.aarch64/tools
===> TOOLDIR path:/dist/tools.aarch64
===> DESTDIR path:/tmp/pkgsrc/destdir.aarch64
===> RELEASEDIR path: /dist/releases
===> Updated makewrapper: /dist/tools.aarch64/bin/nbmake-evbarm
[...]
/usr/bin/clang -O2 -mcpu=native -fno-stack-protector -no-cpp-precomp -I.
-I./include -I/dist/src/tools/compat -I/dist/src/tools/compat/sys
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -no-cpp-precomp -I.
-I./include -I/dist/src/tools/compat -I/dist/src/tools/compat/sys
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D__DBINTERFACE_PRIVATE -c -o
pwcache.lo.o/dist/src/tools/compat/../../lib/libc/gen/pwcache.c
--- md2.lo ---
/dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4: error: call to
undeclared function 'MD2Transform'; ISO C99 and later do not support implicit
function declarations [-Wimplicit-function-declaration]
MD2Transform(context); /* resets i */
^
/dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:163:1: error: conflicting
types for 'MD2Transform'
MD2Transform(MD2_CTX *context)
^
/dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4: note: previous
implicit declaration is here
MD2Transform(context); /* resets i */
^
2 errors generated.
*** Failed target: md2.lo
*** Failed commands:
${_MKTARGET_COMPILE}
=> @echo '# ' "compile " compat/md2.lo
${HOST_COMPILE.c} -o ${.TARGET}.o ${COPTS.${.IMPSRC:T}}
${CPUFLAGS.${.IMPSRC:T}} ${CPPFLAGS.${.IMPSRC:T}} ${.IMPSRC}
=> /usr/bin/clang -O2 -mcpu=native -fno-stack-protector -no-cpp-precomp -I.
-I./include -I/dist/src/tools/compat -I/dist/src/tools/compat/sys
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -no-cpp-precomp -I.
-I./include -I/dist/src/tools/compat -I/dist/src/tools/compat/sys
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D__DBINTERFACE_PRIVATE -c -o
md2.lo.o/dist/src/tools/compat/../../lib/libc/hash/md2/md2.c
${MV} ${.TARGET}.o ${.TARGET}
=> mv -f md2.lo.o md2.lo
*** [md2.lo] Error code 1
nbmake[7]: stopped in /dist/src/tools/compat
Re: Can't build evbarm
Date:Thu, 25 Jan 2024 20:12:36 +0100 From:Adam Message-ID: | Correct, _LIBC_INTERNAL is not defined for tools/compat. I wonder what the difference is between your environment, and a standard build on a NetBSD host. | MD2Transform() must be defined for MD2Update() in lib/libc/hash/md2/md2.c. Yes, that I understand. Try the following patch to src/tools/compat/md2.h and see if that helps (though I think there should be a better way). kre Index: md2.h === RCS file: /cvsroot/src/tools/compat/md2.h,v retrieving revision 1.2 diff -u -r1.2 md2.h --- md2.h 27 Oct 2003 00:12:43 - 1.2 +++ md2.h 25 Jan 2024 19:59:10 - @@ -1,5 +1,8 @@ /* $NetBSD: md2.h,v 1.2 2003/10/27 00:12:43 lukem Exp $*/ /* We unconditionally use the NetBSD MD2 in libnbcompat. */ +#ifndef _LIBC_INTERNAL +#define_LIBC_INTERNAL +#endif #include "nbtool_config.h" #include "../../include/md2.h"
Re: Can't build evbarm
> I don't know what's different in your build, but reeling.netbsd.org shows all > the builds are working. Are you cross building? > > christos Yes. This is a cross-build on macOS 14.3 with clang. Adam
Re: Can't build evbarm
> On 25 Jan 2024, at 09:52, Adam wrote: > >> All builds are working again, if this still fails for you there must be >> a local problem in your setup. >> >> Martin > > My setup is cross-building NetBSD on macOS. > > Adam I’ve have issues building on macOS (since Big Sur) where the target is amd64, arm64 or i386. The tools for CTF do not work properly. Lukem put some fixes in place but I’m not sure if they were fully resolved. You might get away with building with 1 thread IIRC. Can you paste the errors you are getting please? Kind regards Chris smime.p7s Description: S/MIME cryptographic signature
Re: Can't build evbarm
I don't know what's different in your build, but reeling.netbsd.org shows all
the builds are working. Are you cross building?
christos
> On Jan 25, 2024, at 3:20 AM, Adam wrote:
>
>> Today, the build fails while making tools:
>>
>>
>> --- md2.lo ---
>> /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4: error: call to
>> undeclared function 'MD2Transform'; ISO C99 and later do not support
>> implicit function declarations [-Wimplicit-function-declaration]
>> MD2Transform(context); /* resets i */
>> ^
>> /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:163:1: error:
>> conflicting types for 'MD2Transform'
>> MD2Transform(MD2_CTX *context)
>> ^
>> /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4: note: previous
>> implicit declaration is here
>> MD2Transform(context); /* resets i */
>> ^
>> 2 errors generated.
>
> Reverting lib/libc/hash/md2/md2.c to v1.7 fixes the build.
>
> As I understand, MD2Transform() is used (in MD2Update()) before it is
> defined, so to fix it properly I suggest the following patch.
>
> Commit?
>
> Kind regards,
> Adam
>
>
>
> diff -u -r1.8 md2.c
> --- md2.c 20 Jan 2024 14:52:47 - 1.8
> +++ md2.c 25 Jan 2024 08:17:43 -
> @@ -113,6 +113,30 @@
> memset(>X[0], 0, sizeof(context->X));
> }
> +/*
> + * XXX This should not be visible, but due to an accident, it is
> + * XXX so it must remain so.
> + */
> +/*static*/ void
> +MD2Transform(MD2_CTX *context)
> +{
> + uint32_t l, j, k, t;
> +
> + /* set block "3" and update "checksum" */
> + for (l = context->C[15], j = 0; j < 16; j++) {
> + context->X[32 + j] = context->X[j] ^ context->X[16 + j];
> + l = context->C[j] ^= S[context->X[16 + j] ^ l];
> + }
> +
> + /* mangle input block */
> + for (t = j = 0; j < 18; t = (t + j) % 256, j++)
> + for (k = 0; k < 48; k++)
> + t = context->X[k] = (context->X[k] ^ S[t]);
> +
> + /* reset input pointer */
> + context->i = 16;
> +}
> +
> void
> MD2Update(MD2_CTX *context, const unsigned char *input, unsigned int inputLen)
> {
> @@ -155,28 +179,4 @@
> MD2Init(context);
> }
> -/*
> - * XXX This should not be visible, but due to an accident, it is
> - * XXX so it must remain so.
> - */
> -/*static*/ void
> -MD2Transform(MD2_CTX *context)
> -{
> - uint32_t l, j, k, t;
> -
> - /* set block "3" and update "checksum" */
> - for (l = context->C[15], j = 0; j < 16; j++) {
> - context->X[32 + j] = context->X[j] ^ context->X[16 + j];
> - l = context->C[j] ^= S[context->X[16 + j] ^ l];
> - }
> -
> - /* mangle input block */
> - for (t = j = 0; j < 18; t = (t + j) % 256, j++)
> - for (k = 0; k < 48; k++)
> - t = context->X[k] = (context->X[k] ^ S[t]);
> -
> - /* reset input pointer */
> - context->i = 16;
> -}
> -
> #endif /* !HAVE_MD2_H */
Re: Can't build evbarm
Date:Thu, 25 Jan 2024 09:20:50 +0100 From:Adam Message-ID: <39200422-f15b-42c6-87c0-b23f92d13...@netbsd.org> | > Today, the build fails while making tools: | > Please show me the full command line for the compile which is producing that error (and confirm all your sources are up to date - for this, anything within the past few days should be OK). The patch you suggest should not be needed, there's a prototype fot MD2Transform() in md2.h which should be enough ... but it is only visible when __LIBC_INTERNAL is defined, which it should be when builing any libc, tools version included. This does not fail for me, but I don't have a macOS system to test with (I just rebuilt the complete tools set for aarch64 to confirm that). kre
Re: Can't build evbarm
On Thu, Jan 25, 2024 at 10:52:30AM +0100, Adam wrote: > > All builds are working again, if this still fails for you there must be > > a local problem in your setup. > > > > Martin > > My setup is cross-building NetBSD on macOS. But that doesn't explain the issues you are seeing, no host tools should be involved in that part or am I missing something? Can you start the build from scratch (remove obj and destdir upfront) and provide a bit more build output before the failure, please? Martin
Re: Can't build evbarm
> All builds are working again, if this still fails for you there must be > a local problem in your setup. > > Martin My setup is cross-building NetBSD on macOS. Adam
Re: Can't build evbarm
On Thu, Jan 25, 2024 at 09:20:50AM +0100, Adam wrote: > Reverting lib/libc/hash/md2/md2.c to v1.7 fixes the build. All builds are working again, if this still fails for you there must be a local problem in your setup. Martin
Re: Can't build evbarm
> Today, the build fails while making tools:
>
>
> --- md2.lo ---
> /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4: error: call to
> undeclared function 'MD2Transform'; ISO C99 and later do not support implicit
> function declarations [-Wimplicit-function-declaration]
>MD2Transform(context); /* resets i */
>^
> /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:163:1: error:
> conflicting types for 'MD2Transform'
> MD2Transform(MD2_CTX *context)
> ^
> /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4: note: previous
> implicit declaration is here
>MD2Transform(context); /* resets i */
>^
> 2 errors generated.
Reverting lib/libc/hash/md2/md2.c to v1.7 fixes the build.
As I understand, MD2Transform() is used (in MD2Update()) before it is defined,
so to fix it properly I suggest the following patch.
Commit?
Kind regards,
Adam
diff -u -r1.8 md2.c
--- md2.c 20 Jan 2024 14:52:47 - 1.8
+++ md2.c 25 Jan 2024 08:17:43 -
@@ -113,6 +113,30 @@
memset(>X[0], 0, sizeof(context->X));
}
+/*
+ * XXX This should not be visible, but due to an accident, it is
+ * XXX so it must remain so.
+ */
+/*static*/ void
+MD2Transform(MD2_CTX *context)
+{
+ uint32_t l, j, k, t;
+
+ /* set block "3" and update "checksum" */
+ for (l = context->C[15], j = 0; j < 16; j++) {
+ context->X[32 + j] = context->X[j] ^ context->X[16 + j];
+ l = context->C[j] ^= S[context->X[16 + j] ^ l];
+ }
+
+ /* mangle input block */
+ for (t = j = 0; j < 18; t = (t + j) % 256, j++)
+ for (k = 0; k < 48; k++)
+ t = context->X[k] = (context->X[k] ^ S[t]);
+
+ /* reset input pointer */
+ context->i = 16;
+}
+
void
MD2Update(MD2_CTX *context, const unsigned char *input, unsigned int inputLen)
{
@@ -155,28 +179,4 @@
MD2Init(context);
}
-/*
- * XXX This should not be visible, but due to an accident, it is
- * XXX so it must remain so.
- */
-/*static*/ void
-MD2Transform(MD2_CTX *context)
-{
- uint32_t l, j, k, t;
-
- /* set block "3" and update "checksum" */
- for (l = context->C[15], j = 0; j < 16; j++) {
- context->X[32 + j] = context->X[j] ^ context->X[16 + j];
- l = context->C[j] ^= S[context->X[16 + j] ^ l];
- }
-
- /* mangle input block */
- for (t = j = 0; j < 18; t = (t + j) % 256, j++)
- for (k = 0; k < 48; k++)
- t = context->X[k] = (context->X[k] ^ S[t]);
-
- /* reset input pointer */
- context->i = 16;
-}
-
#endif /* !HAVE_MD2_H */
Re: Can't build evbarm
Today, the build fails while making tools: --- md2.lo --- /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4: error: call to undeclared function 'MD2Transform'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] MD2Transform(context); /* resets i */ ^ /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:163:1: error: conflicting types for 'MD2Transform' MD2Transform(MD2_CTX *context) ^ /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4: note: previous implicit declaration is here MD2Transform(context); /* resets i */ ^ 2 errors generated. Kind regards, Adam
Re: Can't build evbarm
> Update to HEAD (after receiving this e-mail) and try again. I think it > is "fixed" now - but the fix is as UGLY as I can imagine is possible, > and I expect it to get redone some other way... It builds fine now. Thanks :) Adam
Re: Can't build evbarm
On Sat, Jan 20, 2024 at 05:19:25PM +0700, Robert Elz wrote: > Not that particular one I didn't, didn't know about that particular > breakage, will look at it now. Oops, mixed the breakage - but thanks for fixing it now :-) Martin
Re: Can't build evbarm
Date:Sat, 20 Jan 2024 10:50:27 +0100 From:Adam Message-ID: <29d271cd-36ed-4890-ace2-fa209685b...@netbsd.org> | NetBSD-current fails to build on aarch64. Update to HEAD (after receiving this e-mail) and try again. I think it is "fixed" now - but the fix is as UGLY as I can imagine is possible, and I expect it to get redone some other way... kre
Re: Can't build evbarm
Date:Sat, 20 Jan 2024 11:02:36 +0100 From:Martin Husemann Message-ID: <20240120100236.gb14...@mail.duskware.de> | Robert fixed it in the meantime. Not that particular one I didn't, didn't know about that particular breakage, will look at it now. kre
Re: Can't build evbarm
On Sat, Jan 20, 2024 at 10:50:27AM +0100, Adam wrote: > NetBSD-current fails to build on aarch64. > > Please, help :) As you can see here: https://releng.NetBSD.org/cgi-bin/builds.cgi it was not only evbarm/aarch64 affected, but all builds were broken. Robert fixed it in the meantime. Martin
Can't build evbarm
NetBSD-current fails to build on aarch64.
Please, help :)
Adam
dependall ===> lib/libkern
--- atomic_init_cas.d ---
#create libkern/atomic_init_cas.d
CC=/dist/tools.aarch64/bin/aarch64--netbsd-gcc /dist/tools.aarch64/bin/nbmkdep
-f atomic_init_cas.d.tmp -- -std=gnu99 -Werror -Wall -Wmissing-prototypes
-Wstrict-prototypes -Wpointer-arith --sysroot=/tmp/pkgsrc/destdir.aarch64
-nostdinc -I/tmp/pkgsrc/obj.aarch64/lib/libkern -I/dist/src/sys
-I/dist/src/sys/arch -D_STANDALONE -D_KERNTYPES
-I/dist/src/sys/lib/libkern/arch/aarch64
-I/dist/src/sys/lib/libkern/../../../common/lib/libc/quad
-I/dist/src/sys/lib/libkern/../../../common/lib/libc/string
-I/dist/src/sys/lib/libkern/../../../common/lib/libc/arch/aarch64/string
-I/dist/src/sys/lib/libkern/../../../common/lib/libc/arch/aarch64/atomic
-I/dist/src/sys/lib/libkern/../../../common/lib/libc/hash/sha3
-I/dist/src/sys/lib/libkern/../../../common/include
-I/dist/src/sys/lib/libkern/../../../common/libc/hash/sha3
/dist/src/sys/lib/libkern/../../../common/lib/libc/atomic/atomic_init_cas.c &&
mv -f atomic_init_cas.d.tmp atomic_init_cas.d
/dist/src/sys/lib/libkern/../../../common/lib/libc/atomic/atomic_init_cas.c:36:10:
fatal error: extern.h: No such file or directory
36 | #include "extern.h"
| ^~
compilation terminated.
nbmkdep: compile failed.
*** Failed target: atomic_init_cas.d
*** Failed commands:
${_MKTARGET_CREATE}
=> @echo '# ' " create " libkern/atomic_init_cas.d
${MKDEP} -f ${.TARGET}.tmp ${_MKDEP_FILEFLAGS} -- ${MKDEPFLAGS}
${CFLAGS:M-std=*} ${CFLAGS:C/-([IDUW])[ ]*/-\1/Wg:M-[IDUW]*}
${CPPFLAGS:N-Wp,-iremap,*} ${COPTS.${.IMPSRC:T}} ${CPUFLAGS.${.IMPSRC:T}}
${CPPFLAGS.${.IMPSRC:T}} ${.IMPSRC} && ${MV} ${.TARGET}.tmp ${.TARGET}
=> CC=/dist/tools.aarch64/bin/aarch64--netbsd-gcc
/dist/tools.aarch64/bin/nbmkdep -f atomic_init_cas.d.tmp -- -std=gnu99
-Werror -Wall -Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith
--sysroot=/tmp/pkgsrc/destdir.aarch64 -nostdinc
-I/tmp/pkgsrc/obj.aarch64/lib/libkern -I/dist/src/sys -I/dist/src/sys/arch
-D_STANDALONE -D_KERNTYPES -I/dist/src/sys/lib/libkern/arch/aarch64
-I/dist/src/sys/lib/libkern/../../../common/lib/libc/quad
-I/dist/src/sys/lib/libkern/../../../common/lib/libc/string
-I/dist/src/sys/lib/libkern/../../../common/lib/libc/arch/aarch64/string
-I/dist/src/sys/lib/libkern/../../../common/lib/libc/arch/aarch64/atomic
-I/dist/src/sys/lib/libkern/../../../common/lib/libc/hash/sha3
-I/dist/src/sys/lib/libkern/../../../common/include
-I/dist/src/sys/lib/libkern/../../../common/libc/hash/sha3
/dist/src/sys/lib/libkern/../../../common/lib/libc/atomic/atomic_init_cas.c &&
mv -f atomic_init_cas.d.tmp atomic_init_cas.d
*** [atomic_init_cas.d] Error code 1
