| Message ID | 20180419135901.30035-32-alex.bennee@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | fix building of tests/tcg | expand |
On 04/19/2018 10:58 AM, Alex Bennée wrote: > This doesn't add any additional tests but enables building the > multiarch tests for MIPS using docker cross compilers. We don't have a > cross compiler for mips64 big endian though. Oh we have one, using CFLAGS+=-EB we don't have cross libraries although. > Signed-off-by: Alex Bennée <alex.bennee@linaro.org> > --- > tests/tcg/mips/Makefile.include | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > create mode 100644 tests/tcg/mips/Makefile.include > > diff --git a/tests/tcg/mips/Makefile.include b/tests/tcg/mips/Makefile.include > new file mode 100644 > index 0000000000..a9beceb623 > --- /dev/null > +++ b/tests/tcg/mips/Makefile.include > @@ -0,0 +1,17 @@ > +# > +# Makefile.include for all MIPs targets > +# > +# As Debian doesn't support mip64 in big endian mode the only way to > +# build BE is to pass a working cross compiler to ./configure > +# > + > +ifeq ($(TARGET_NAME),mips64el) > +DOCKER_IMAGE=debian-mips64el-cross > +DOCKER_CROSS_COMPILER=mips64el-linux-gnuabi64-gcc > +else ifeq ($(TARGET_NAME),mipsel) > +DOCKER_IMAGE=debian-mipsel-cross > +DOCKER_CROSS_COMPILER=mipsel-linux-gnu-gcc > +else ifeq ($(TARGET_NAME),mips) > +DOCKER_IMAGE=debian-mips-cross > +DOCKER_CROSS_COMPILER=mips-linux-gnu-gcc > +endif >
Philippe Mathieu-Daudé <f4bug@amsat.org> writes: > On 04/19/2018 10:58 AM, Alex Bennée wrote: >> This doesn't add any additional tests but enables building the >> multiarch tests for MIPS using docker cross compilers. We don't have a >> cross compiler for mips64 big endian though. > > Oh we have one, using CFLAGS+=-EB > > we don't have cross libraries although. Yeah I thought the same with the ARM compilers (-mbig-endian) but it's the libraries that let us down. If, as you say, newlib gets this right I suspect we should use that to build the compilers not supported out of the box by Debian. > >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> >> --- >> tests/tcg/mips/Makefile.include | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> create mode 100644 tests/tcg/mips/Makefile.include >> >> diff --git a/tests/tcg/mips/Makefile.include b/tests/tcg/mips/Makefile.include >> new file mode 100644 >> index 0000000000..a9beceb623 >> --- /dev/null >> +++ b/tests/tcg/mips/Makefile.include >> @@ -0,0 +1,17 @@ >> +# >> +# Makefile.include for all MIPs targets >> +# >> +# As Debian doesn't support mip64 in big endian mode the only way to >> +# build BE is to pass a working cross compiler to ./configure >> +# >> + >> +ifeq ($(TARGET_NAME),mips64el) >> +DOCKER_IMAGE=debian-mips64el-cross >> +DOCKER_CROSS_COMPILER=mips64el-linux-gnuabi64-gcc >> +else ifeq ($(TARGET_NAME),mipsel) >> +DOCKER_IMAGE=debian-mipsel-cross >> +DOCKER_CROSS_COMPILER=mipsel-linux-gnu-gcc >> +else ifeq ($(TARGET_NAME),mips) >> +DOCKER_IMAGE=debian-mips-cross >> +DOCKER_CROSS_COMPILER=mips-linux-gnu-gcc >> +endif >> -- Alex Bennée
On 19 April 2018 at 18:49, Alex Bennée <alex.bennee@linaro.org> wrote: > > Philippe Mathieu-Daudé <f4bug@amsat.org> writes: > >> On 04/19/2018 10:58 AM, Alex Bennée wrote: >>> This doesn't add any additional tests but enables building the >>> multiarch tests for MIPS using docker cross compilers. We don't have a >>> cross compiler for mips64 big endian though. >> >> Oh we have one, using CFLAGS+=-EB >> >> we don't have cross libraries although. > > Yeah I thought the same with the ARM compilers (-mbig-endian) but it's > the libraries that let us down. If, as you say, newlib gets this right I > suspect we should use that to build the compilers not supported out of > the box by Debian. I don't think we really want to get into the business of building our own cross compilers if we can avoid it...it's harder than it looks and we would be essentially reinventing the wheel. thanks -- PMM
On 04/19/2018 02:58 PM, Peter Maydell wrote: > On 19 April 2018 at 18:49, Alex Bennée <alex.bennee@linaro.org> wrote: >> Philippe Mathieu-Daudé <f4bug@amsat.org> writes: >>> On 04/19/2018 10:58 AM, Alex Bennée wrote: >>>> This doesn't add any additional tests but enables building the >>>> multiarch tests for MIPS using docker cross compilers. We don't have a >>>> cross compiler for mips64 big endian though. >>> >>> Oh we have one, using CFLAGS+=-EB >>> >>> we don't have cross libraries although. >> >> Yeah I thought the same with the ARM compilers (-mbig-endian) but it's >> the libraries that let us down. If, as you say, newlib gets this right I >> suspect we should use that to build the compilers not supported out of >> the box by Debian. > > I don't think we really want to get into the business of > building our own cross compilers if we can avoid it...it's harder > than it looks and we would be essentially reinventing the wheel. I totally agree. I'v been looking at existing maintained images we can use to cross-build, so we only have to pull (download) and image and use it, not wasting cpu time building it. However some images might be huge, full of things we don't need. But I prefer that rather than having to maintain cross toolchains. An example I like to use is the coreboot-sdk, designed to build i386/amd64 binaries, it fulfills our needs. But takes 2GB... $ docker pull coreboot/coreboot-sdk:1.47 1.47: Pulling from coreboot/coreboot-sdk 3d6aedfc3e47: Downloading [> ] 538.2kB/1.201GB d23c9a72f1e5: Waiting Another candidate is crossbuild, ~1GB $ docker pull multiarch/crossbuild
On Thu, 04/19 23:57, Philippe Mathieu-Daudé wrote: > On 04/19/2018 02:58 PM, Peter Maydell wrote: > > On 19 April 2018 at 18:49, Alex Bennée <alex.bennee@linaro.org> wrote: > >> Philippe Mathieu-Daudé <f4bug@amsat.org> writes: > >>> On 04/19/2018 10:58 AM, Alex Bennée wrote: > >>>> This doesn't add any additional tests but enables building the > >>>> multiarch tests for MIPS using docker cross compilers. We don't have a > >>>> cross compiler for mips64 big endian though. > >>> > >>> Oh we have one, using CFLAGS+=-EB > >>> > >>> we don't have cross libraries although. > >> > >> Yeah I thought the same with the ARM compilers (-mbig-endian) but it's > >> the libraries that let us down. If, as you say, newlib gets this right I > >> suspect we should use that to build the compilers not supported out of > >> the box by Debian. > > > > I don't think we really want to get into the business of > > building our own cross compilers if we can avoid it...it's harder > > than it looks and we would be essentially reinventing the wheel. > > I totally agree. > > I'v been looking at existing maintained images we can use to > cross-build, so we only have to pull (download) and image and use it, > not wasting cpu time building it. > > However some images might be huge, full of things we don't need. But I > prefer that rather than having to maintain cross toolchains. > > An example I like to use is the coreboot-sdk, designed to build > i386/amd64 binaries, it fulfills our needs. But takes 2GB... > > $ docker pull coreboot/coreboot-sdk:1.47 > 1.47: Pulling from coreboot/coreboot-sdk > 3d6aedfc3e47: Downloading [> ] 538.2kB/1.201GB > d23c9a72f1e5: Waiting > > Another candidate is crossbuild, ~1GB > $ docker pull multiarch/crossbuild Makes sense to me. It is not insanely big. It might take some time to download depending on the network but it's more likely a one-off thing compared to building one from a handcraft dockerfile we make, which probably will involve even more downloading time and disk usage. Fam
Philippe Mathieu-Daudé <f4bug@amsat.org> writes: > On 04/19/2018 02:58 PM, Peter Maydell wrote: >> On 19 April 2018 at 18:49, Alex Bennée <alex.bennee@linaro.org> wrote: >>> Philippe Mathieu-Daudé <f4bug@amsat.org> writes: >>>> On 04/19/2018 10:58 AM, Alex Bennée wrote: >>>>> This doesn't add any additional tests but enables building the >>>>> multiarch tests for MIPS using docker cross compilers. We don't have a >>>>> cross compiler for mips64 big endian though. >>>> >>>> Oh we have one, using CFLAGS+=-EB >>>> >>>> we don't have cross libraries although. >>> >>> Yeah I thought the same with the ARM compilers (-mbig-endian) but it's >>> the libraries that let us down. If, as you say, newlib gets this right I >>> suspect we should use that to build the compilers not supported out of >>> the box by Debian. >> >> I don't think we really want to get into the business of >> building our own cross compilers if we can avoid it...it's harder >> than it looks and we would be essentially reinventing the wheel. > > I totally agree. > > I'v been looking at existing maintained images we can use to > cross-build, so we only have to pull (download) and image and use it, > not wasting cpu time building it. > > However some images might be huge, full of things we don't need. But I > prefer that rather than having to maintain cross toolchains. > > An example I like to use is the coreboot-sdk, designed to build > i386/amd64 binaries, it fulfills our needs. But takes 2GB... > > $ docker pull coreboot/coreboot-sdk:1.47 > 1.47: Pulling from coreboot/coreboot-sdk > 3d6aedfc3e47: Downloading [> ] 538.2kB/1.201GB > d23c9a72f1e5: Waiting > > Another candidate is crossbuild, ~1GB > $ docker pull multiarch/crossbuild I agree to a point. Our current images are all based off "official" docker hub images. I'm probably giving the state of officialness too much credit but I'm at least reasonably certain the Debian images can be re-created ourselves if we wanted to and have publicly available recipes. As a bonus, being Debian based, we meet our GPL compliance because everything on the image can have its source pulled with apt. I'm unsure about how the coreboot image was built or indeed if it is an official image. From my point of view it is just a bunch of binaries in a set of docker layers. So personally I would put "build our own compiler from source inside docker" slightly above "unpack a random binary tarball into docker". That said with some of our funkier supported guests we may end up having to do just that :-/ -- Alex Bennée
Philippe Mathieu-Daudé <f4bug@amsat.org> writes: > On 04/19/2018 02:58 PM, Peter Maydell wrote: >> On 19 April 2018 at 18:49, Alex Bennée <alex.bennee@linaro.org> wrote: >>> Philippe Mathieu-Daudé <f4bug@amsat.org> writes: >>>> On 04/19/2018 10:58 AM, Alex Bennée wrote: >>>>> This doesn't add any additional tests but enables building the >>>>> multiarch tests for MIPS using docker cross compilers. We don't have a >>>>> cross compiler for mips64 big endian though. >>>> >>>> Oh we have one, using CFLAGS+=-EB >>>> >>>> we don't have cross libraries although. >>> >>> Yeah I thought the same with the ARM compilers (-mbig-endian) but it's >>> the libraries that let us down. If, as you say, newlib gets this right I >>> suspect we should use that to build the compilers not supported out of >>> the box by Debian. >> >> I don't think we really want to get into the business of >> building our own cross compilers if we can avoid it...it's harder >> than it looks and we would be essentially reinventing the wheel. > > I totally agree. > > I'v been looking at existing maintained images we can use to > cross-build, so we only have to pull (download) and image and use it, > not wasting cpu time building it. > > However some images might be huge, full of things we don't need. But I > prefer that rather than having to maintain cross toolchains. > > An example I like to use is the coreboot-sdk, designed to build > i386/amd64 binaries, it fulfills our needs. But takes 2GB... > > $ docker pull coreboot/coreboot-sdk:1.47 > 1.47: Pulling from coreboot/coreboot-sdk > 3d6aedfc3e47: Downloading [> ] 538.2kB/1.201GB > d23c9a72f1e5: Waiting Found the dockerfile: https://github.com/MattDevo/coreboot/blob/master/util/docker/coreboot-sdk/Dockerfile > > Another candidate is crossbuild, ~1GB > $ docker pull multiarch/crossbuild This looks like it is just a multiarch debian setup much like our own. -- Alex Bennée
On 20 April 2018 at 03:57, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > On 04/19/2018 02:58 PM, Peter Maydell wrote: >> I don't think we really want to get into the business of >> building our own cross compilers if we can avoid it...it's harder >> than it looks and we would be essentially reinventing the wheel. > > I totally agree. > > I'v been looking at existing maintained images we can use to > cross-build, so we only have to pull (download) and image and use it, > not wasting cpu time building it. Projects that are in the "maintain cross toolchains" business: * buildroot * https://github.com/richfelker/musl-cross-make But really my feeling is that we should for the moment stick to getting a reliable test setup for the architectures that Debian does provide cross toolchains for. That will give us: * much more coverage than we have at the moment * coverage for the guests that people actually care about We can always come back and think about filling in the gaps later. thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On 20 April 2018 at 03:57, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >> On 04/19/2018 02:58 PM, Peter Maydell wrote: >>> I don't think we really want to get into the business of >>> building our own cross compilers if we can avoid it...it's harder >>> than it looks and we would be essentially reinventing the wheel. >> >> I totally agree. >> >> I'v been looking at existing maintained images we can use to >> cross-build, so we only have to pull (download) and image and use it, >> not wasting cpu time building it. > > Projects that are in the "maintain cross toolchains" business: > * buildroot > * https://github.com/richfelker/musl-cross-make I'll have a look at those. My previous attempts were using: https://wiki.linaro.org/ABE https://crosstool-ng.github.io/ I certainly don't want to be in the business of inventing yet another set of scripts to build cross compilers! > > But really my feeling is that we should for the moment stick > to getting a reliable test setup for the architectures that > Debian does provide cross toolchains for. That will give us: > * much more coverage than we have at the moment > * coverage for the guests that people actually care about > > We can always come back and think about filling in the gaps later. Don't worry - not having every single architecture done isn't going to stop the eventual submission. However it would be nice to have at least one non-Debian cross-compiler setup as an example and to validate the compiler-in-docker approach. > > thanks > -- PMM -- Alex Bennée
diff --git a/tests/tcg/mips/Makefile.include b/tests/tcg/mips/Makefile.include new file mode 100644 index 0000000000..a9beceb623 --- /dev/null +++ b/tests/tcg/mips/Makefile.include @@ -0,0 +1,17 @@ +# +# Makefile.include for all MIPs targets +# +# As Debian doesn't support mip64 in big endian mode the only way to +# build BE is to pass a working cross compiler to ./configure +# + +ifeq ($(TARGET_NAME),mips64el) +DOCKER_IMAGE=debian-mips64el-cross +DOCKER_CROSS_COMPILER=mips64el-linux-gnuabi64-gcc +else ifeq ($(TARGET_NAME),mipsel) +DOCKER_IMAGE=debian-mipsel-cross +DOCKER_CROSS_COMPILER=mipsel-linux-gnu-gcc +else ifeq ($(TARGET_NAME),mips) +DOCKER_IMAGE=debian-mips-cross +DOCKER_CROSS_COMPILER=mips-linux-gnu-gcc +endif
This doesn't add any additional tests but enables building the multiarch tests for MIPS using docker cross compilers. We don't have a cross compiler for mips64 big endian though. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> --- tests/tcg/mips/Makefile.include | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 tests/tcg/mips/Makefile.include -- 2.17.0