dpdk fails to cross build from source for ppc64el, because it passes -mcpu=ppc64el there and that doesn't make gcc happy. Digging into it, its build system behaves differently for a cross build from a native build. When a cross build is encountered, it takes the host's cpu value and passes it to -mcpu directly whereas in a native build, it matches the host's cpu family and carefully crafts values accepted by gcc. In particular, a native ppc64el build causes the cpu value to be "ppc64el", which is not accepted by gcc. Hence there is no way of correctly supplying the host cpu in a cross build for ppc64el. As a result, I question the cross branch entirely and propose deleting it. Once it is absent, the option logic can be used again. Please do not blindly accept this patch but discuss it with upstream. I don't think someone added this branch with the intention of breaking stuff, but they solved some other problem and reverting their change will break their problem. I don't understand what problem is being solved with the branch, so revert is what I propose here, but I don't think it is the final solution. You may also consider adding it as a Debian-specific patch, but then you get to maintain the divergence forever. Helmut
Hi Helmut, Luca and I had a look today and confirmed what you found, not by testing but by reviewing code. Let us just check that it really is what you meant when you said "the cross branch" In [1] it checks for a cross build and since [2] wrongly sets the cpu architecture [3] as instruction set which is doomed to fail. Is that what you refeered to? Just like you, we assume this is working for someone, maybe arm people? And hence, again as you suggested, it would need to go upstream for discussion there. Of course we could just forward that, but since neither Luca nor I are cross-builders we wondered if it would not be better if you would do so, to be available for cross-questions that might be returned. If you happen to be OK to do so please send a mail to dev [4] + Bruce Richardson (mail see [2]) + Luca and me (mail see the dpdk upload changelogs). [1]: https://github.com/DPDK/dpdk/blob/main/config/meson.build#L115 [2]: https://github.com/DPDK/dpdk/commit/bf66003b51ece4defb15d45c6c1cad812b994073#diff-003da2c5d180a8d7d3723988895f7fa6cd96a30ac69cfd36025a1eadb8d460f2R72 [3]: https://mesonbuild.com/Reference-manual_builtin_host_machine.html [4]: https://mails.dpdk.org/listinfo/dev
Hi Helmut o/ In a bug scrub today we found this in our backlog. But this case is kind of stuck, from our maintianers POV it isn't broken by the packaging. It needs upstream engagement and backing, hence we asked to please consider reporting it there. It isn't a case evil enough that we'd jump and do that - we'd hope you reporting it is better anyway as you also have all the background and context on your cross build use-case. Anyway, what I want to say is please excuse us for not having shown any action for a year. But for transparency of expectations I wanted to make it clear that we think without a forwarded report to upstream the state will likely stay that way. I hope this ping unblocks the case, if not I think if once another year passes (= no pressure for anyone) we might close it as un-actionable to clear up our backlog.