slibtool presently does not include -L... pathnames from the command line in ${LD_LIBRARY_PATH} in wrapper scripts whereas, in particular, -L... pathnames from dependent shared objects' slibtool dependency files are included. This results in wrapper scripts failing to locate directly dependent shared objects and is addressed by calling slbt_emit_fdwrap_amend_dl_path() on -L... command line arguments.
-L...
${LD_LIBRARY_PATH}
slbt_emit_fdwrap_amend_dl_path()
This fixes the following slibtool-related Gentoo package build failures (WIP): app-text/atril as of at least 1.24.0-r1
<img alt="slibtoolinclude_Ldirs_in_wrapper_ldpathenv.patch" src="/cross/slibtool/issue/raw/files/2f1481a1eecfed204f6ad4d62946076c5c307f6dda815dd1ac7c4614a682c13e-slibtoolinclude_Ldirs_in_wrapper_ldpathenv.patch" />
I think this is an atril bug.
https://github.com/mate-desktop/atril/pull/528
Also I still think projects should not use -Lfoo -lbar for internal dependencies.
-Lfoo -lbar
While I do agree with you and the general consensus here, this is a slightly more subtle case than #34 which is furthermore not limited to internal dependencies - this would still be triggered given e.g. -L/non/system/wide/standard/path/name -lexternallib.
-L/non/system/wide/standard/path/name -lexternallib
I would defer to you and @midipix for the fix on the slibtool side, but I think regardless atril should use a correct --library argument for g-ir-scanner.
--library
g-ir-scanner
I would defer to you and @midipix on the fix on the slibtool side, but I think regardless atril should use a correct --library argument for g-ir-scanner.
Agreed.
Merged as bdfc624.
Metadata Update from @lalbornoz: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.