| Message ID | 20161123143914.3969-4-Vincent.Riera@imgtec.com |
|---|---|
| State | Accepted |
| Headers | show |
Hello, On Wed, 23 Nov 2016 14:39:12 +0000, Vicente Olivert Riera wrote: > Otherwise the compilation will fail like this: > > ./libmoar.so: undefined reference to `dcCallbackThunkEntry' > > See: https://github.com/MoarVM/MoarVM/issues/222 > > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Is this something we can see in the autobuilders? I.e, is this master or next material? Thanks, Thomas
Hi Thomas, On 23/11/16 20:56, Thomas Petazzoni wrote: > Hello, > > On Wed, 23 Nov 2016 14:39:12 +0000, Vicente Olivert Riera wrote: >> Otherwise the compilation will fail like this: >> >> ./libmoar.so: undefined reference to `dcCallbackThunkEntry' >> >> See: https://github.com/MoarVM/MoarVM/issues/222 >> >> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> > > Is this something we can see in the autobuilders? I.e, is this master > or next material? Is next material since MoarVM is not available for MIPS, so you cannot build it and you cannot hit that issue. MoarVM depends on libatomic_ops, and libatomic_ops doesn't have MIPS support in Buildroot so far. This patch series adds MIPS support to it, so, from that moment, MoarVM will be able to be built for MIPS. Regards, Vincent > > Thanks, > > Thomas >
Hello, Thanks for your feedback. On Thu, 24 Nov 2016 14:58:00 +0000, Vicente Olivert Riera wrote: > MoarVM depends on libatomic_ops, and libatomic_ops doesn't have MIPS > support in Buildroot so far. This patch series adds MIPS support to it, > so, from that moment, MoarVM will be able to be built for MIPS. If moarvm depends on libatomic_ops, then why the patch enabling MIPS support in libatomic_ops is PATCH 5/6, i.e. *after* the patch enabling moarvm? Won't things break if I apply only patches 1 to 4, but not patches 5 and 6 ? Best regards, Thomas
Hi Thomas, On 24/11/16 15:21, Thomas Petazzoni wrote: > Hello, > > Thanks for your feedback. > > On Thu, 24 Nov 2016 14:58:00 +0000, Vicente Olivert Riera wrote: > >> MoarVM depends on libatomic_ops, and libatomic_ops doesn't have MIPS >> support in Buildroot so far. This patch series adds MIPS support to it, >> so, from that moment, MoarVM will be able to be built for MIPS. > > If moarvm depends on libatomic_ops, then why the patch enabling MIPS > support in libatomic_ops is PATCH 5/6, i.e. *after* the patch enabling > moarvm? Won't things break if I apply only patches 1 to 4, but not > patches 5 and 6 ? no, there is no patch enabling or disabling MoarVM for MIPS. You won't be able to build MoarVM for MIPS until libatomic_ops has support for MIPS as well, because MoarVM depends on libatomic_ops. So, if we enable libatomic_ops, then we will be able to build MoarVM, and that will fail. What I did in my patch series is to add the code for fixing the MIPS problem in MoarVM even before we can actually build it for MIPS. Regards, Vincent > > Best regards, > > Thomas >
Hello, On Thu, 24 Nov 2016 16:23:46 +0000, Vicente Olivert Riera wrote: > no, there is no patch enabling or disabling MoarVM for MIPS. You won't > be able to build MoarVM for MIPS until libatomic_ops has support for > MIPS as well, because MoarVM depends on libatomic_ops. > > So, if we enable libatomic_ops, then we will be able to build MoarVM, > and that will fail. What I did in my patch series is to add the code for > fixing the MIPS problem in MoarVM even before we can actually build it > for MIPS. Ah, yes, moarvm has a "depends on BR2_PACKAGE_LIBATOMIC_OPS_ARCH_SUPPORTS", so indeed moarvm can't be selected for MIPS until MIPS support in libatomic_ops is enabled. So bisectability-wise we are OK. However, from a logical point of view, it is very, very strange to enable the dependencies of moarvm *after* moarvm itself. It would be much more logical to take care of libatomic_ops first (which can be used for other things than moarvm), and then handle moarvm. Thanks, Thomas
Hi Thomas, On 24/11/16 16:54, Thomas Petazzoni wrote: > Hello, > > On Thu, 24 Nov 2016 16:23:46 +0000, Vicente Olivert Riera wrote: > >> no, there is no patch enabling or disabling MoarVM for MIPS. You won't >> be able to build MoarVM for MIPS until libatomic_ops has support for >> MIPS as well, because MoarVM depends on libatomic_ops. >> >> So, if we enable libatomic_ops, then we will be able to build MoarVM, >> and that will fail. What I did in my patch series is to add the code for >> fixing the MIPS problem in MoarVM even before we can actually build it >> for MIPS. > > Ah, yes, moarvm has a "depends on > BR2_PACKAGE_LIBATOMIC_OPS_ARCH_SUPPORTS", so indeed moarvm can't be > selected for MIPS until MIPS support in libatomic_ops is enabled. So > bisectability-wise we are OK. > > However, from a logical point of view, it is very, very strange to > enable the dependencies of moarvm *after* moarvm itself. That's the thing, we are not enabling moarvm itself. It happens automatically when you enable its dependencies. > It would be > much more logical to take care of libatomic_ops first (which can be > used for other things than moarvm), and then handle moarvm. Yeah, I see your point. The thing is that I put first the fix for moarvm in place so whenever it gets enabled for MIPS it's gonna build just fine. Anyway, do you need me to resend this series with the patches in different order, or will you handle that when applying? Regards, Vincent > > Thanks, > > Thomas >
diff --git a/package/moarvm/Config.in b/package/moarvm/Config.in index 3e0a104..76343d1 100644 --- a/package/moarvm/Config.in +++ b/package/moarvm/Config.in @@ -9,6 +9,9 @@ config BR2_PACKAGE_MOARVM select BR2_PACKAGE_LIBUV select BR2_PACKAGE_LIBTOMMATH select BR2_PACKAGE_LIBATOMIC_OPS + # dyncall does not work on MIPS; libffi needs to be used. + # See: https://github.com/MoarVM/MoarVM/issues/222 + select BR2_PACKAGE_LIBFFI if BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el help Short for "Metamodel On A Runtime", MoarVM is a virtual machine built especially for Rakudo Perl 6 and the NQP Compiler Toolchain.
Otherwise the compilation will fail like this: ./libmoar.so: undefined reference to `dcCallbackThunkEntry' See: https://github.com/MoarVM/MoarVM/issues/222 Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> --- package/moarvm/Config.in | 3 +++ 1 file changed, 3 insertions(+)