On Thu, Jan 9, 2025 at 7:57 PM Ileana Dumitrescu <
ileanadumitrescu95@gmail.com> wrote:

> On 09/01/2025 15:11, Frederic Berat wrote:
> > Hello,
> >
> > I opened an issue a few years back that didn't get solved: https://
> > lists.gnu.org/archive/html/libtool/2022-02/msg00001.html <https://
> > lists.gnu.org/archive/html/libtool/2022-02/msg00001.html>
> >
> > Out of curiosity, I decided to remove my local patch for it with the new
> > libtool release. It didn't take long for builds to fail again:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2331361 <https://
> > bugzilla.redhat.com/show_bug.cgi?id=2331361>
> >
> > Considering that more and more systems prevent deduplication over the
> > years, may it be considered to be the default behavior instead of the
> > exception ?
>
> To ensure GNU Libtool continues to work with older systems, this patch
> should probably not be applied. Users can disable the deduplication
> optimization with "--preserve-dup-deps" without applying the suggested
> patch, but this affects more than just compiler generated dependencies.
>
>
Well, I'm not sure I get why keeping duplicates would harm, but fair enough
my patch is clearly overkill.


> I would be more willing to add an option to toggle
> "$opt_duplicate_compiler_generated_deps" separate from
> "$opt_preserve_dup_deps". Would this be a good alternative to the patch?
>

Not sure that's a good alternative. you'd force users from the systems that
have been excluded over the years to toggle an option that they didn't need
so far.


>
> --
> Ileana Dumitrescu
>
> GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
>
>