Hi Richard,
On Tue, 21 Dec 2021, at 12:04, Richard Purdie wrote:
> On Tue, 2021-12-21 at 11:56 +0000, Andrei Gherzan wrote:
>> 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/lin
>> > ux64.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?
>
> I don't like sed in this context as if the code changes, it silently stops
> working and we struggle to know what broke or whether we need to fix it. We
> don't have any test case.
>
> Given all that, the touch of the file is a neater solution as it is more
> obvious
> what it is doing. I'd also want to see some more detailed comments in the code
> about what it is doing and why.
>
> Maintainability of these kinds of fixes is key.
I totally agree so I dug a bit more into this and arrived at a different fix.
Pushed it to the ml -
https://lists.openembedded.org/g/openembedded-core/message/159978
---
Andrei
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159979):
https://lists.openembedded.org/g/openembedded-core/message/159979
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]
-=-=-=-=-=-=-=-=-=-=-=-
