diff mbox series

Azure: Add 'tools-only' build for macOS X hosts

Message ID 20200516185439.10633-1-trini@konsulko.com
State Superseded
Headers show
Series Azure: Add 'tools-only' build for macOS X hosts | expand

Commit Message

Tom Rini May 16, 2020, 6:54 p.m. UTC
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(+)

Comments

Jonathan Gray May 17, 2020, 2:48 a.m. UTC | #1
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
> 
>
Tom Rini May 18, 2020, 12:52 p.m. UTC | #2
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.
Heinrich Schuchardt May 26, 2020, 10:39 p.m. UTC | #3
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 mbox series

Patch

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: