> On 23 Mar 2025, at 20:09, Jeff Law <jeffreya...@gmail.com> wrote:
>
>
>
> On 3/23/25 8:28 AM, Iain Sandoe wrote:
>> Hi Jeff,
>>> On 23 Mar 2025, at 14:25, Jeff Law <jeffreya...@gmail.com> wrote:
>>> On 3/23/25 8:03 AM, Iain Sandoe wrote:
>>>> Tested on x86_64-Linux, Darwin,
>>>> OK for trunk?
>>>> backports?
>>>> thanks
>>>> Iain
>>>> --- 8< ---
>>>> Actually, the issue is not local to the libitm case, it currently affects
>>>> any 'cxx=true' top-level configured target library.
>>>> The issue is a missing export of CXX_FOR_TARGET.
>>>> PR libitm/88319
>>>> ChangeLog:
>>>> * Makefile.in: Regenerate.
>>>> * Makefile.tpl: Add CXX_FOR_TARGET to NORMAL_TARGET_EXPORTS.
>>> So how does one trigger this failure? ISTM that every libitm build should
>>> be failing. I think the patch is likely fine, but struggle to see why this
>>> hasn't been more widely reported.
>> take your current build, and then delete <target>/{,mlib}/libitm
>> then try
>> “make ….. all-target-libitm” .. I believe it will fail with a libtool error
>> (because the compiler is not passed - only the options)
>> That was certainly failing on both x86_64 linux/darwin before the patch.
> To be clear, I don't doubt it was failing, just trying to understand the
> failure mode. So it only pops up during a rebuild in an existing tree which
> explains why we haven't been seeing this reported more often.
plus it only shows up for “cxx=true” libraries which, until libcobol was added
was only libitm (and libffi)
[I noticed that the failure mode was the same while working on libcobol]
the other cxx cases are "raw_cxx=true” which already had the CXX_FOR_TARGET
added;
> Thanks. Ok for the trunk.
do you think it’s worth backporting (after some bake time)?
thanks
Iain
