Re: [patch #10569] FIx old_deplibs usage / archive-in-archive test

Hi,

Awesome, thanks a lot! This relieves me of a big pain point for the 
integration in VLC.

For the next steps, I'll probably try to dig into the dependency 
forwarding during partial linking. I've been maintaining some horrible 
hacks in our buildsystem to be able to handle this but I feel I could 
somehow allow libtool --mode=link $CC -r libpartiallylinked.la $OBJS to 
generate a convenience library with a single object and thus provides 
the dependencies which would then reuse libtool for this.

Hopefully this would be a practical libtool use case for partial linking 
that would help move this part forward.

Do you know approximately how much time I would have to implement this 
before release?

Regards,
-- 
Alexandre Janniaux

On 5/21/26 20:32, Ileana Dumitrescu wrote:
> Update of patch #10569 (group libtool):
>
>                    Status:                    None => Done
>               Open/Closed:                    Open => Closed
>
>      _______________________________________________________
>
> Follow-up Comment #2:
>
> On 16/05/2026 18:43, Alexandre Janniaux wrote:
>> Hi,
>>
>> I've investigated the testsuite with your feedback and it seems all problems
>> I missed are coming from the line merging old_deplibs into dependency_libs.
>>
>> It seems using the same loop as the snippet above, ie. checking for
>> absolute path and adding pwd if needed, is enough to fix the absolute
>> path requirement. The test was failing because, fortunately in the test,
>> the referenced static archive was used from a different working directory.
>>
>> Then it was also failing on the test producing libltdl.so. It seems that
>> I misunderstand this part of the code back then and though it would only
>> affect old libraries because the linker would use $deplibs when building
>> the shared library. However, the static archives would still be forwarded
>> to dependency_libs in the final libtool archive because of that, which the
>> testsuite fortunately catched too. By gating the code with a check on
>> library_names (so assuming static archives are squashed into the shared
>> libraries), I can finally pass this last remaining test.
>>
>> Here is a new revision. with this change. The main changes are commit
>> message to reference this issue and this line:
>>
>> +           func_append dependency_libs " $old_deplibs"
>>
>> Transformed into:
>>
>> +         # Forward old library dependencies only when no shared
>> +         # library is being built. When building the shared library,
>> +         # the linker uses $deplibs to link the archives into it, but
>> +         # then we don't want to add it as transitive dependency.
>> +         if test -z "$library_names"; then
>> +           for lib in $old_deplibs; do
>> +             case $lib in
>> +               [\\/]* | [A-Za-z]:[\\/]*) abs=$lib ;;
>> +               *) abs=`pwd`"/$lib" ;;
>> +             esac
>> +             func_append dependency_libs " $abs"
>> +           done
>> +         fi
>>
>> I've copied the code above for path handling without accounting whether
>> refactoring could be interesting or not.
> Thank you for the updated patches! Most test failures were fixed, but the grep
> check in archive-in-archive.at needed to updated for MSVC. I have applied your
> patches to the development branch, which should migrate to the master branch
> before the next libtool release.
>
> https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=2dfd9132f835657f6be7a63645a8331f048370a6
> https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=ec577ffbb3b5fc6752da7e26a23d11056a9f2cea
> https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=c6ded7d821f7bda31ed56ef968ad78ab4f945085
>
>
>      _______________________________________________________
>
> To reply to this notification, you have two options:
> * In the Web UI at <https://savannah.gnu.org/patch/?10569>.
> * By email to 408818-patch-savannah <[email protected]>, ONLY IF you preserve both
>    the 'display name' and the 'address specification' in the To: header
>    AND you sign your email with a GPG key registered in your Savannah account
>    AND you include the following line in the reply:
>
>    {savane: user = 408818; tracker = patch; item = 10569}
>
> _______________________________________________
> Message sent via Savannah
> https://savannah.gnu.org/