libffi: v3.2.1 doesn't support riscv targets yet
RFC PATCH 1/1 libffi: v3.2.1 doesn't support riscv targets yet
Fixes:
http://autobuild.buildroot.org/?reason=libffi-3.2.1&arch=riscv64
---
The upcoming version 3.3.0 will support riscv [1], so this patch would be temporary. Do we wait for that release, or should we explicitly disable libffi for riscv in the meantime?
[1] https://github.com/libffi/libffi/commit/3840d49aaa831d649b1597518a2903dfed0d57f3
--- package/libffi/Config.in | 3 +++ 1 file changed, 3 insertions(+)
package/libffi/Config.in +3 -0
@@ -1,6 +1,7 @@ config BR2_PACKAGE_LIBFFI bool "libffi" depends on BR2_TOOLCHAIN_HAS_THREADS + depends on !BR2_riscv help The libffi library provides a portable, high level programming interface to various calling conventions. This
@@ -11,3 +12,5 @@ config BR2_PACKAGE_LIBFFI comment "libffi needs a toolchain w/ threads" depends on !BR2_TOOLCHAIN_HAS_THREADS +comment "libffi is not supported on RISCV." + depends on BR2_riscv
Signature · 1 line
2.19.0
RFC PATCH 1/1 libffi: v3.2.1 doesn't support riscv targets yet
Hi Ferdinand,
I'm afraid you made some unfortunate choices for the autobuild failures to fix :-)
Quoted 9 lines · Ferdinand van Aartsen
Fixes:
http://autobuild.buildroot.org/?reason=libffi-3.2.1&arch=riscv64
---The upcoming version 3.3.0 will support riscv [1], so this patch would be temporary. Do we wait for that release, or should we explicitly disable libffi for riscv in the meantime?
[1] https://github.com/libffi/libffi/commit/3840d49aaa831d649b1597518a2903dfed0d57f3
Just backporting that patch is also a possibility.
Quoted 10 lines
--- package/libffi/Config.in | 3 +++ 1 file changed, 3 insertions(+)package/libffi/Config.in +0
-0
package/libffi/Config.in line 4
Quoted 4 lines
package/libffi/Config.in +1
-0@@ -1,6 +1,7 @@ config BR2_PACKAGE_LIBFFI bool "libffi" depends on BR2_TOOLCHAIN_HAS_THREADS + depends on !BR2_riscv
The problem is that this creates a Config.in dependency cycle, because there
are other packages (e.g. libglib2) that don't have this !riscv dependency and that select libffi. Just try it: select libglib2 on a riscv architecture and after exiting menuconfig you'll see a warning message. This will eventually lead to a build failure because it will still try to build libffi.
So what you should do in theory is to propagate that dependency to all packages
that select libffi, and propagate it further to all packages selecting those packages, etc.
Unfortunately that is hardly feasible. libglib2 selects libffi, and there are
almost 100 packages that select libglib2...
There are in fact already a few architectures that are not supported by libffi.
To avoid failures with those, we just blacklist them in the autobuild script - see lines 258-267 in utils/genrandconfig. So the easiest solution is to add a blacklist there.
If you *do* feel up to it to generate a patch that touches roughly 150
Config.in files, you're welcome to do so! The proper approach to do that would be as follows: in libffi, start the Config.in file with:
config BR2_PACKAGE_LIBFFI_ARCH_SUPPORTS
bool
default y
depends on !BR2_sh2a
depends on !BR2_ARM_CPU_ARMV7M
depends on !BR2_riscv
config BR2_PACKAGE_LIBFFI
bool "libffi"
depends on BR2_PACKAGE_LIBFFI_ARCH_SUPPORTS depends on BR2_TOOLCHAIN_HAS_THREADS
comment "libffi needs a toolchain w/ threads"
depends on BR2_PACKAGE_LIBFFI_ARCH_SUPPORTS depends on !BR2_TOOLCHAIN_HAS_THREADS
Then, each package that selects libffi should get the following as its first
dependency:
depends on BR2_PACKAGE_LIBFFI_ARCH_SUPPORTS # libffi
And each package that recursively selects it, e.g. a package that selects libglib2:
depends on BR2_PACKAGE_LIBFFI_ARCH_SUPPORTS # libglib2 -> libffi
This dependency should also be added to the toolchain comments of those packages.
Personally, I would be fine with doing this gradually, i.e. it is not needed to
fix all 150 packages in a single commit. Indeed, the build is already broken anyway, so if this is shown as a circular dependency warning or as a build failure of libffi doesn't matter that much.
package/libffi/Config.in config BR2_PACKAGE_LIBFFI · line 16
Quoted 9 lines
package/libffi/Config.in +2
-0help The libffi library provides a portable, high level programming interface to various calling conventions. This@@ -11,3 +12,5 @@ config BR2_PACKAGE_LIBFFI comment "libffi needs a toolchain w/ threads" depends on !BR2_TOOLCHAIN_HAS_THREADS +comment "libffi is not supported on RISCV." + depends on BR2_riscv
We don't show these warnings for the architecture dependencies, because there
is anyway nothing the user can do about it. Instead, we even hide the other warnings if the package anyway can't be selected. This is why in the example I gave above, there is only one comment, and it depends on the ARCH_SUPPORTS.
Regards,
Arnout
RFC PATCH 1/1 libffi: v3.2.1 doesn't support riscv targets yet
?Something I forgot...
Quoted 4 lines · Arnout Vandecappelle
Personally, I would be fine with doing this gradually, i.e. it is not needed to
fix all 150 packages in a single commit. Indeed, the build is already broken anyway, so if this is shown as a circular dependency warning or as a build failure of libffi doesn't matter that much.
?In fact, if you would start doing this, it's best that you post a small patch (fixing just libffi and one or two dependencies) quickly, so we can check if you're on the right track.
?Regards,
?Arnout
RFC PATCH 1/1 libffi: v3.2.1 doesn't support riscv targets yet
In reply to Arnout VandecappelleHello,
+Mark Corbin in Cc.
Quoted 5 lines · Arnout Vandecappelle
Quoted 5 lines
The upcoming version 3.3.0 will support riscv [1], so this patch would be temporary. Do we wait for that release, or should we explicitly disable libffi for riscv in the meantime?
[1] https://github.com/libffi/libffi/commit/3840d49aaa831d649b1597518a2903dfed0d57f3
FYI, we already discussed the libffi/RISC-V situation during the Buildroot meeting last week end with Mark Corbin (who added the RISC-V 64 support). And I think he was working on backporting the RISC-V libffi support so that we can add it as a patch in Buildroot.
That being said...
Quoted 4 lines
Personally, I would be fine with doing this gradually, i.e. it is not needed to
fix all 150 packages in a single commit. Indeed, the build is already broken anyway, so if this is shown as a circular dependency warning or as a build failure of libffi doesn't matter that much.
... I am indeed not opposed to fixing properly the libffi arch dependencies. It is true that with the autobuilders in place, we can do this gradually. It would be cleaner than the magic exception we have in the autobuilder script. The downside is that we will have for a fairly long time a significant number of autobuilder failures.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
RFC PATCH 1/1 libffi: v3.2.1 doesn't support riscv targets yet
Hello
Quoted 10 lines · Thomas Petazzoni
Hello,
+Mark Corbin in Cc.
Quoted 4 lines · Arnout Vandecappelle
Quoted 4 lines
The upcoming version 3.3.0 will support riscv [1], so this patch would be temporary. Do we wait for that release, or should we explicitly disable libffi for riscv in the meantime?
Quoted 5 lines
Quoted 1 line
FYI, we already discussed the libffi/RISC-V situation during the Buildroot meeting last week end with Mark Corbin (who added the RISC-V 64 support). And I think he was working on backporting the RISC-V libffi support so that we can add it as a patch in Buildroot.
I ran a quick diff and it didn't look like there are that many RISC-V changes to port. However, I probably won't get a chance to look at this until next week.
Regards
Mark
Quoted 16 lines
That being said...
Quoted 4 lines
Personally, I would be fine with doing this gradually, i.e. it is not needed to
fix all 150 packages in a single commit. Indeed, the build is already broken anyway, so if this is shown as a circular dependency warning or as a build failure of libffi doesn't matter that much.... I am indeed not opposed to fixing properly the libffi arch dependencies. It is true that with the autobuilders in place, we can do this gradually. It would be cleaner than the magic exception we have in the autobuilder script. The downside is that we will have for a fairly long time a significant number of autobuilder failures.
Best regards,
Thomas
Signature · 22 lines
*Mark Corbin* Embedded Operating Systems Lead Phone: +44 1590 610184?????Mobile: +44 7765 703479 Email: mark.corbin at embecosm.com <mailto:[email protected]>?????Web: https://www.embecosm.com Embecosm Logo Embecosm Ltd., Palamos House #208, 66/67 High Street, Lymington, SO41 9AL, UK Company No. 6577021 (England & Wales). -- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20181024/f516e879/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 8442 bytes Desc: not available URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20181024/f516e879/attachment.png>
RFC PATCH 1/1 libffi: v3.2.1 doesn't support riscv targets yet
Quoted 17 lines · Mark Corbin
Hello
On 24/10/2018 09:36, Thomas Petazzoni wrote:
Hello,
+Mark Corbin in Cc.
On Wed, 24 Oct 2018 01:24:09 +0100, Arnout Vandecappelle wrote:
The upcoming version 3.3.0 will support riscv [1], so this patch would be temporary. Do we wait for that release, or should we explicitly disable libffi for riscv in the meantime?
[1] https://github.com/libffi/libffi/commit/3840d49aaa831d649b1597518a2903dfed0d57f3
Quoted 7 lines
FYI, we already discussed the libffi/RISC-V situation during the Buildroot meeting last week end with Mark Corbin (who added the RISC-V 64 support). And I think he was working on backporting the RISC-V libffi support so that we can add it as a patch in Buildroot.
I ran a quick diff and it didn't look like there are that many RISC-V changes to port. However, I probably won't get a chance to look at this until next week.
it is a big patch, but Yocto just has a single patch to add support:
https://github.com/riscv/meta-riscv/blob/master/recipes-support/libffi/files/0001-Add-riscv-support.patch
Alistair
Quoted 39 lines
Regards
Mark
That being said...
Personally, I would be fine with doing this gradually, i.e. it is not needed to
fix all 150 packages in a single commit. Indeed, the build is already broken anyway, so if this is shown as a circular dependency warning or as a build failure of libffi doesn't matter that much.... I am indeed not opposed to fixing properly the libffi arch dependencies. It is true that with the autobuilders in place, we can do this gradually. It would be cleaner than the magic exception we have in the autobuilder script. The downside is that we will have for a fairly long time a significant number of autobuilder failures.
Best regards,
Thomas
--
Mark Corbin
Embedded Operating Systems Lead
Phone: +44 1590 610184 Mobile: +44 7765 703479
Email: mark.corbin at embecosm.com Web: https://www.embecosm.comEmbecosm Ltd., Palamos House #208, 66/67 High Street, Lymington, SO41 9AL, UK Company No. 6577021 (England & Wales).
--
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
RFC PATCH 1/1 libffi: v3.2.1 doesn't support riscv targets yet
In reply to Thomas PetazzoniQuoted 10 lines · Thomas Petazzoni
Hello,
+Mark Corbin in Cc.
Quoted 4 lines · Arnout Vandecappelle
Personally, I would be fine with doing this gradually, i.e. it is not needed to
fix all 150 packages in a single commit. Indeed, the build is already broken anyway, so if this is shown as a circular dependency warning or as a build failure of libffi doesn't matter that much.
Quoted 5 lines
... I am indeed not opposed to fixing properly the libffi arch dependencies. It is true that with the autobuilders in place, we can do this gradually. It would be cleaner than the magic exception we have in the autobuilder script. The downside is that we will have for a fairly long time a significant number of autobuilder failures.
We can leave the autobuilder exceptions in place until we think that most of
the dependencies have been fixed.
Regards,
Arnout
RFC PATCH 1/1 libffi: v3.2.1 doesn't support riscv targets yet
In reply to Arnout VandecappelleArnout Vandecappelle schreef op 2018-10-24 02:24:
Quoted 6 lines
Hi Ferdinand,
I'm afraid you made some unfortunate choices for the autobuild
failures to fix :-)
Oh well, that's what happens when you're looking for a place in the sandbox that hasn't been claimed yet. To be sure, I did ask about this on irc, and trawled through the mailing list, without seeing any indication that anyone was working on it.
Quoted 5 lines · Ferdinand van Aartsen
Quoted 4 lines
Fixes:
http://autobuild.buildroot.org/?reason=libffi-3.2.1&arch=riscv64
---
Quoted 9 lines
Quoted 6 lines
The upcoming version 3.3.0 will support riscv [1], so this patch would be temporary. Do we wait for that release, or should we explicitly disable libffi for riscv in the meantime?
[1]
https://github.com/libffi/libffi/commit/3840d49aaa831d649b1597518a2903dfed0d57f3Just backporting that patch is also a possibility.
I assumed that would be out of scope, but Buildroot really is an all-encompassing project. That's what I like about it.
Quoted 80 lines
Quoted 10 lines
--- package/libffi/Config.in | 3 +++ 1 file changed, 3 insertions(+)package/libffi/Config.in +0
-0package/libffi/Config.in line 4
Quoted 4 lines
package/libffi/Config.in +1
-0@@ -1,6 +1,7 @@ config BR2_PACKAGE_LIBFFI bool "libffi" depends on BR2_TOOLCHAIN_HAS_THREADS + depends on !BR2_riscvThe problem is that this creates a Config.in dependency cycle, because
there
are other packages (e.g. libglib2) that don't have this !riscv dependency and
that select libffi. Just try it: select libglib2 on a riscv architecture and
after exiting menuconfig you'll see a warning message. This will eventually lead
to a build failure because it will still try to build libffi.So what you should do in theory is to propagate that dependency to all
packages
that select libffi, and propagate it further to all packages selecting those
packages, etc.Unfortunately that is hardly feasible. libglib2 selects libffi, and
there are
almost 100 packages that select libglib2...There are in fact already a few architectures that are not supported
by libffi.
To avoid failures with those, we just blacklist them in the autobuild script -
see lines 258-267 in utils/genrandconfig. So the easiest solution is to add a
blacklist there.If you *do* feel up to it to generate a patch that touches roughly 150
Config.in files, you're welcome to do so! The proper approach to do that would
be as follows: in libffi, start the Config.in file with:config
BR2_PACKAGE_LIBFFI_ARCH_SUPPORTS
bool
default y
depends on !BR2_sh2a
depends on !BR2_ARM_CPU_ARMV7M
depends on !BR2_riscvconfig
BR2_PACKAGE_LIBFFI
bool "libffi"
depends onBR2_PACKAGE_LIBFFI_ARCH_SUPPORTSdepends onBR2_TOOLCHAIN_HAS_THREADScomment "libffi needs a toolchain w/ threads"
depends onBR2_PACKAGE_LIBFFI_ARCH_SUPPORTSdepends on !BR2_TOOLCHAIN_HAS_THREADSThen, each package that selects libffi should get the following as its
first
dependency:depends on
BR2_PACKAGE_LIBFFI_ARCH_SUPPORTS# libffiAnd each package that recursively selects it, e.g. a package that selects libglib2:
depends on BR2_PACKAGE_LIBFFI_ARCH_SUPPORTS # libglib2 -> libffiThis dependency should also be added to the toolchain comments of those packages.
Quoted 9 lines
Personally, I would be fine with doing this gradually, i.e. it is not
needed to
fix all 150 packages in a single commit. Indeed, the build is already broken
anyway, so if this is shown as a circular dependency warning or as a build
failure of libffi doesn't matter that much.
I hadn't yet realised that dependencies override each other that way. I'll start mapping out the territory, and work on a gradual approach.
Ferdinand
Quoted 21 lines
package/libffi/Config.in config BR2_PACKAGE_LIBFFI · line 16
Quoted 9 lines
package/libffi/Config.in +2
-0help The libffi library provides a portable, high level programming interface to various calling conventions. This@@ -11,3 +12,5 @@ config BR2_PACKAGE_LIBFFI comment "libffi needs a toolchain w/ threads" depends on !BR2_TOOLCHAIN_HAS_THREADS +comment "libffi is not supported on RISCV." + depends on BR2_riscvWe don't show these warnings for the architecture dependencies,
because there
is anyway nothing the user can do about it. Instead, we even hide the other
warnings if the package anyway can't be selected. This is why in the example I
gave above, there is only one comment, and it depends on theARCH_SUPPORTS.Regards,
Arnout