| Message ID | 20200516185439.10633-1-trini@konsulko.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Azure: Add 'tools-only' build for macOS X hosts | expand |
On Sat, May 16, 2020 at 02:54:39PM -0400, Tom Rini wrote: > Add building the 'tools-only' target on macOS X 'Catalina'. Hopefully > this will catch changes to host tools that are incompatible on BSD style > environments. > > Signed-off-by: Tom Rini <trini at konsulko.com> > ---- > Note that at this time commit 3b4847cbee7c > ("efi_loader: support building UEFI binaries on sandbox") is causing > this to fail as non-GNU make does not support 'undefine' and there's not > gmake nor do we need (seemingly) to use gmake otherwise. If we must, we > can look in to 'brew install gmake' I think but I'm trying to have this > be a typical BSD build environment. For building U-Boot (with around 70 targets) in OpenBSD ports we depend on the following additional ports not in the base system: devel/gmake devel/bison devel/dtc devel/swig textproc/gsed (with check-config.sh patched to use it over base sed) lang/python (python3) for aarch64 targets devel/arm-none-eabi/gcc-linaro,aarch64 devel/py-elftools sysutils/arm-trusted-firmware for arm targets devel/arm-none-eabi/gcc-linaro The host/system compiler on most OpenBSD platforms is clang. I would like to move to doing native builds when building on aarch64 and armv7 platforms with the system clang. I wonder how many of the warnings in doc/README.clang still apply. > --- > .azure-pipelines.yml | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml > index 5d9645451d47..09b79f4241f8 100644 > --- a/.azure-pipelines.yml > +++ b/.azure-pipelines.yml > @@ -1,6 +1,7 @@ > variables: > windows_vm: vs2017-win2016 > ubuntu_vm: ubuntu-18.04 > + macos_vm: macOS-10.15 > ci_runner_image: trini/u-boot-gitlab-ci-runner:bionic-20200403-27Apr2020 > # Add '-u 0' options for Azure pipelines, otherwise we get "permission > # denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer", > @@ -44,6 +45,17 @@ jobs: > # Tell MSYS2 not to ?cd? our startup directory to HOME > CHERE_INVOKING: yes > > + - job: tools_only_macOS > + displayName: 'Ensure host tools build for macOS X' > + pool: > + vmImage: $(macos_vm) > + steps: > + - script: | > + make tools-only_config tools-only NO_SDL=1 \ > + HOSTCFLAGS="-I/usr/local/opt/openssl at 1.1/include" \ > + HOSTLDFLAGS="-L/usr/local/opt/openssl at 1.1/lib" \ > + -j$(sysctl -n hw.logicalcpu) > + > - job: cppcheck > displayName: 'Static code analysis with cppcheck' > pool: > -- > 2.17.1 > >
On Sun, May 17, 2020 at 12:48:42PM +1000, Jonathan Gray wrote: > On Sat, May 16, 2020 at 02:54:39PM -0400, Tom Rini wrote: > > Add building the 'tools-only' target on macOS X 'Catalina'. Hopefully > > this will catch changes to host tools that are incompatible on BSD style > > environments. > > > > Signed-off-by: Tom Rini <trini at konsulko.com> > > ---- > > Note that at this time commit 3b4847cbee7c > > ("efi_loader: support building UEFI binaries on sandbox") is causing > > this to fail as non-GNU make does not support 'undefine' and there's not > > gmake nor do we need (seemingly) to use gmake otherwise. If we must, we > > can look in to 'brew install gmake' I think but I'm trying to have this > > be a typical BSD build environment. > > For building U-Boot (with around 70 targets) in OpenBSD ports we depend > on the following additional ports not in the base system: > > devel/gmake > devel/bison > devel/dtc > devel/swig > textproc/gsed (with check-config.sh patched to use it over base sed) > lang/python (python3) > > for aarch64 targets > devel/arm-none-eabi/gcc-linaro,aarch64 > devel/py-elftools > sysutils/arm-trusted-firmware > > for arm targets > devel/arm-none-eabi/gcc-linaro > > The host/system compiler on most OpenBSD platforms is clang. > > I would like to move to doing native builds when building on aarch64 and > armv7 platforms with the system clang. I wonder how many of the > warnings in doc/README.clang still apply. Thanks. Any updates to doc/README.clang would be good. It looks like there's still a large number of blocking problems on aarch64 for someone to solve (no libgcc, but could we just solve that another way?) and linking U-Boot itself fails, but maybe we can use the clang linker by now? On both 32 and 64bit ARM, EFI loader needs to be disabled for rpi at least to finish compiling, and on 32bit it does link and run.
On 5/18/20 2:52 PM, Tom Rini wrote: > On Sun, May 17, 2020 at 12:48:42PM +1000, Jonathan Gray wrote: >> On Sat, May 16, 2020 at 02:54:39PM -0400, Tom Rini wrote: >>> Add building the 'tools-only' target on macOS X 'Catalina'. Hopefully >>> this will catch changes to host tools that are incompatible on BSD style >>> environments. >>> >>> Signed-off-by: Tom Rini <trini at konsulko.com> >>> ---- >>> Note that at this time commit 3b4847cbee7c >>> ("efi_loader: support building UEFI binaries on sandbox") is causing >>> this to fail as non-GNU make does not support 'undefine' and there's not >>> gmake nor do we need (seemingly) to use gmake otherwise. If we must, we >>> can look in to 'brew install gmake' I think but I'm trying to have this >>> be a typical BSD build environment. >> >> For building U-Boot (with around 70 targets) in OpenBSD ports we depend >> on the following additional ports not in the base system: >> >> devel/gmake >> devel/bison >> devel/dtc >> devel/swig >> textproc/gsed (with check-config.sh patched to use it over base sed) >> lang/python (python3) >> >> for aarch64 targets >> devel/arm-none-eabi/gcc-linaro,aarch64 >> devel/py-elftools >> sysutils/arm-trusted-firmware >> >> for arm targets >> devel/arm-none-eabi/gcc-linaro >> >> The host/system compiler on most OpenBSD platforms is clang. >> >> I would like to move to doing native builds when building on aarch64 and >> armv7 platforms with the system clang. I wonder how many of the >> warnings in doc/README.clang still apply. > > Thanks. Any updates to doc/README.clang would be good. It looks like > there's still a large number of blocking problems on aarch64 for someone > to solve (no libgcc, but could we just solve that another way?) and > linking U-Boot itself fails, but maybe we can use the clang linker by > now? > > On both 32 and 64bit ARM, EFI loader needs to be disabled for rpi at > least to finish compiling, and on 32bit it does link and run. > In lib/efi_loader/efi_boottime.c and in lib/trace.c we are saving and setting gd. arch/arm/include/asm/global_data.h defines a function get_gd() which is used with clang to retrieve the value of gd: #ifdef __clang__ #define DECLARE_GLOBAL_DATA_PTR #define gd??????get_gd() ... So any statement gd = foo; like in __efi_entry_check() is bound to fail with clang. Does that match your compilation problems with EFI_LOADER=y and clang? Best regards Heinrich
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 5d9645451d47..09b79f4241f8 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -1,6 +1,7 @@ variables: windows_vm: vs2017-win2016 ubuntu_vm: ubuntu-18.04 + macos_vm: macOS-10.15 ci_runner_image: trini/u-boot-gitlab-ci-runner:bionic-20200403-27Apr2020 # Add '-u 0' options for Azure pipelines, otherwise we get "permission # denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer", @@ -44,6 +45,17 @@ jobs: # Tell MSYS2 not to ?cd? our startup directory to HOME CHERE_INVOKING: yes + - job: tools_only_macOS + displayName: 'Ensure host tools build for macOS X' + pool: + vmImage: $(macos_vm) + steps: + - script: | + make tools-only_config tools-only NO_SDL=1 \ + HOSTCFLAGS="-I/usr/local/opt/openssl at 1.1/include" \ + HOSTLDFLAGS="-L/usr/local/opt/openssl at 1.1/lib" \ + -j$(sysctl -n hw.logicalcpu) + - job: cppcheck displayName: 'Static code analysis with cppcheck' pool:
Add building the 'tools-only' target on macOS X 'Catalina'. Hopefully this will catch changes to host tools that are incompatible on BSD style environments. Signed-off-by: Tom Rini <trini at konsulko.com> ---- Note that at this time commit 3b4847cbee7c ("efi_loader: support building UEFI binaries on sandbox") is causing this to fail as non-GNU make does not support 'undefine' and there's not gmake nor do we need (seemingly) to use gmake otherwise. If we must, we can look in to 'brew install gmake' I think but I'm trying to have this be a typical BSD build environment. --- .azure-pipelines.yml | 12 ++++++++++++ 1 file changed, 12 insertions(+)