[Buildroot] [RFC 0/6] Support 32-bit binaries on a 64-bit architecture
Florian Fainelli
f.fainelli at gmail.com
Fri Feb 16 23:00:31 UTC 2018
On 02/16/2018 12:59 PM, Thomas Petazzoni wrote:
> Hello,
>
> On Fri, 16 Feb 2018 08:45:57 +0200, Baruch Siach wrote:
>
>> On Thu, Feb 15, 2018 at 04:56:06PM -0800, Markus Mayer wrote:
>>> This series contains a proposal for supporting 32-bit libraries and
>>> binaries on a 64-bit platform.
>>>
>>> There are some limitations and prerequisites as to the scope this has
>>> been tested.
>>>
>>> - It has only been tested on ARM/ARM64.
>>> - It has only been tested with an external toolchain
>>> (https://github.com/Broadcom/stbgcc-6.3/releases).
>>> - It requires that the Aarch64 compiler be compiled with "multi-lib"
>>> enabled. This ensures that the sysroot doesn't contain a lib64 ->
>>> lib symlink. Instead, lib and lib64 are separate directories.
>>> - It has only been tested with a fairly limited number of packages.
>>> There might be other packages that don't correctly pass --libdir,
>>> similar to bzip2 as mentioned below.
>>
>> There is one thing I am missing here. AFAICS, this series does not add support
>> for building 32-bit libraries in addition to their 64-bit versions. So the
>> 32-bit binaries that are to run on target must have their dependencies
>> satisfied from the toolchain provided libraries. Is that correct?
>
> Yes, indeed, I'm interested in understanding that part as well. It
> seems like the assumption is that the external toolchain has a 32-bit
> sysroot, and only the libraries from this sysroot are necessary.
Correct, that is what the stbgcc-6.3 toolchain contains.
>
> This feels very limited/restricted to very specific use cases and
> therefore not very usable in a broader context.
I suppose it could be reasonably easy to extend on that and either
require a second toolchain to be built or just point to a different
location?
>
> And extending that to building packages is really difficult with
> Buildroot:
>
> (1) Kconfig has no way to easily allow to select for each and every
> package whether it should be built 32-bit, 64-bit or both.
>
> (2) Our package infrastructure is entirely based on the fact that a
> given package is built only once. So if you assume that you
> solved problem (1) by adding gazillions of Config.in options to
> each and every package, there is still no way the zlib package
> will be built two times, once 32-bit and 64-bit. No without major
> changes to the package infrastructure.
>
> So supporting multilib has already been discussed several times, but
> nobody ever came up with a proposal that could reasonably solve
> problems (1) and (2). Unfortunately, unless there are some proposals to
> solve those problems, I don't think we want to have some very limited
> and highly specific multilib support, that only works with external
> toolchains and that only works for 32-bit libraries provided by the
> external toolchain.
Would you recommend that this logic be sort of done using a two pass
build, by that I mean something like an external top-level Makefile
would be controlling the buildroot build process and do something like:
- build all relevant packages for the 32-bit architecture (that could
include the toolchain as well)
- build all relevant packages for the 64-bit architecture, and copy the
32-bit binaries and libraries of interest from the previously build
32-bit environment?
I suppose such a thing could be done, it has the advantage of not
tweaking buildroot too much, although we still need to teach the 64-bit
variant to accept seeing "foreign" binaries.
--
Florian
More information about the buildroot
mailing list