On Mon, 20 Dec 2021, at 01:39, Bernhard Rosenkränzer via lists.openembedded.org
wrote:
> 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 <and...@gherzan.com> wrote:
>>>
>>>> From: Andrei Gherzan <andrei.gher...@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.
Ping on this patch. Any chance we can pull it in as a first iteration of the
solution?
---
Andrei
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159913):
https://lists.openembedded.org/g/openembedded-core/message/159913
Mute This Topic: https://lists.openembedded.org/mt/87614108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
