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/
