On Thu, Dec 9, 2021 at 07:40 PM, Andrei Gherzan wrote:
On Thu, 9 Dec 2021, at 16:40, Khem Raj wrote:
On Thu, Dec 9, 2021 at 7:40 AM Andrei Gherzan <andrei@gherzan.com> wrote:
From: Andrei Gherzan <andrei.gherzan@huawei.com>
On x86-64, tm.h (needed to build gcc plugins) tries to include
config/i386/linux64.h, which isn't installed. Fortunately it also isn't
used, so simply removing the include statement is an ok fix.
is it due to multilib support ? if so we might be ok since we may not
be using it
but really it will be good to check it with multilib builds of x86_64/x86
I don't think it is related to multilib but I'll give multilib a try. In my case, the issue was revealed when compiling a kernel plugin config. I can't remember right now which one but I can replicate it for logs.
Hi,
I've had a closer look at the problem, and can confirm the patch doesn't break even in multilib setups.
The problem is that in a non-multilib setup, the config/i386/linux64.h header is not generated, but tm.h tries to include it nevertheless, causing any gcc plugin that #includes tm.h (such as all the gcc plugins in the kernel -- tm.h is included by scripts/gcc-plugins/gcc-common.h) to fail to build.
An alternative fix would be adding
mkdir -p ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/config/i386
touch ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/config/i386/linux64.h
(creating the file if it isn't there) instead. This would make sure that in cases where config/i386/linux64.h does exist, it doesn't get removed from tm.h (potentially fixing plugins that reference any of the #defines in i386/linux64.h without including the file manually -- but I have yet to see any such plugin).
I will try to get a better fix (not adding the include statement to tm.h in the first place rather than having to remove it later in install scripts) upstream, but in the mean time, the patch fixes our builds before the better fix is ready/applied.
ttyl
bero