Date: Mon, 18 Dec 2023 08:16:50 +0100 From: Alex Samorukov <samm@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) Message-ID: <cdc20cd7382c73fa35a50cea181ac048@freebsd.org> In-Reply-To: <DEF715CB-6FF1-415C-A316-8B309E2F2BFD@yahoo.com> References: <2025707260.15114.1702739060451@localhost> <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> <fca474837836af15bf097dc2a788951c@freebsd.org> <A98DDDE3-DE73-4908-B224-C288E6A36180@yahoo.com> <7115fd399a58084266b71ecfbd400334@freebsd.org> <DEF715CB-6FF1-415C-A316-8B309E2F2BFD@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2023/12/18 01:41, Mark Millard wrote: ch to poudrier to make it possible [1], but it seems that upstream does not care about patches anymore. >> >> Regarding bug 256132 - so far i cant find that it impacting my builds >> at all - binaries are running well. > > Is all that testing only on an armv6-only processor? Testing on armv7 > or aarch64-that-supports-armv7 would execute code that armv6 would > not. Testing was done on armv6 CPI, RPI1-B board I have. Of course i was not testing everything, as it hard to expect from 512Mb 1CPU board to run Java or Firefox. But at least things like boost, gdb, domoticz, busybox, nginx, ebusd and +-10 other ports I tried are working fine. Now i am running bulk -a to do more extensive checks. > >> I could assume that some configure scripts could try to check (and >> enable) some flags for armv7 while building, but I think the chances >> are very low and it could be handled on ad-hoc basis. > > What have you done to avoid armv7 specific defaults from being used, > instead causing armv6 defaults? I think it should be done out of the box. As I am using chroot from armv6 - the compiler by default should generate armv6 code, otherwise it would be cross-compilation which you have to specify explicitly. Also, it probably will be a good idea to add corresponding `-m` flags to default C/CXX flags. What I need to check - is if llvm* compiled from ports is still assuming that the target is the correct one. I will do that once my bulk run is complete and will let you know the results. I also think that this situation is not that much different from i386 compilation on amd64, potentially some "too smart" configure scripts may detect extensions that are not supposed to be present on i386 and build a broken binary, but in 90+% cases, it should not be the thing as compiler will have default target set correctly. > >> Please correct me if I am missing something. Thank you, Oleksij > > I'll note that I've never done such "armv6-only processor" testing. > I'll not have access to any FreeBSD arm6, arm7, or aarch64 contexts > until after something like 2024-Jan-01. Anyway, thank you for your help. Maybe I will get +1 board (they are very cheap now anyway) to set up as a playground and testing. Especially because we may get a very similar situation at some point with v8+ arms on 64-bit :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cdc20cd7382c73fa35a50cea181ac048>