[PATCH] support: Use unwinder in links-dso-program-c only with libgcc_s

[Frank Scheiner]

On 26.03.25 17:47, Florian Weimer wrote:
> * Frank Scheiner:
> 
>> Dear Florian,
>>
>> On 26.03.25 16:36, Florian Weimer wrote:
>>> Do not build links-dso-program-c with exception (unwinding) support
>>> if libgcc_s is not available.  In this case, the unwinder may be
>>> part of libgcc.a or libgcc_eh.a, depending on how GCC was built.
>>> If the unwinder is in libgcc_eh.a only, linking links-dso-program-c
>>> failed before this change.  After this change, the exception
>>> handling landing pad is only generated if libgcc_s available,
>>> avoiding an undefined _Unwind_Resume (or equivalent) symbol
>>> reference in the non-libgcc_s case.
>>>
>>> Fixes commit ffd36cc27407003a6f9efcb9c16370e3435c5b1d ("support: Use
>>> unwinder in links-dso-program-c only with libgcc_s") and
>>> commit 5dfbc3c43ecc1bcfc760a032c91bb002660051bc ("support: Link
>>> links-dso-program-c with libgcc_s only if available").
>>
>> This seems to break our cross-builds for ia64 with T2 and IIUC also any
>> cross builds in T2 for other architectures, starting with
>> ffd36cc27407003a6f9efcb9c16370e3435c5b1d, where two extra lines were
>> added to support/Makefile:
> 
> What is “this”?

Sorry for the confusion. With "this" I meant all three patches. And that
the problem started with ffd36cc27407003a6f9efcb9c16370e3435c5b1d.

> You talk about
> ffd36cc27407003a6f9efcb9c16370e3435c5b1d, but the patch is supposed to
> fix that.

I wrongly assumed that the `[...] -lgcc` line had to be guarded as
well. See below.

> I've pushed this patch here (thanks Joseph for the quick review).
> Please test again.

I already tested an equivalent change to what you just pushed some days
ago when trying to solve our build issues. In my case I just commented
the `[...] -fexceptions` line to inactivate it. And I thought I had
also tested leaving:

```
LDLIBS-links-dso-program-c = -lgcc
```

...active. But after retesting now it seems not, as the glibc build
works with the above line left active.

I assume I have deactivated the `[...] -lgcc` line first when
trying to fix the build some days ago, but saw that the build still
failed, so deactivated the `[...] -fexceptions` line in addition and
after it worked - wrongly - concluded that both lines have to be
inactive for the build to complete (like it was before
ffd36cc27407003a6f9efcb9c16370e3435c5b1d).

Cheers,
Frank