#49 Over-consistent use of .libs
Closed 11 months ago by midipix. Opened 2 years ago by mjo.

During argument mangling, slibtool tries to open the argument of any -L flags it sees to determine if the target library is local:

mark = ldir + strlen(ldir);

if (mark[-1] == '/')

if ((fd = openat(fdcwd,ldir,O_DIRECTORY,0)) < 0)
  *mark = 0;
else {

  if ((ret = slbt_emit_fdwrap_amend_dl_path(dctx,ectx,depsmeta,"%s",ldir)) < 0)
    return ret;

When the target library is local, .libs is appended to the -L flag. This can lead to problems in some cases where the -L flag references a local library that was not built with libtool, because such a library will not have undergone the corresponding name mangling.

This issue has manifested in at least ProFTPd and web2c. The latter is also mentioned in slibtool's issue #34.

One idea might be to mangle -L<dir> to -L<dir>/.libs -L<dir>, rather than simply to -L<dir>/.libs.

Noted, and thanks for the clean and clear description!

One idea might be to mangle -L<dir> to -L<dir>/.libs -L<dir>, rather than simply to -L<dir>/.libs.

Might indeed be the right thing to do. I'll ask for more feedback on #midipix and #slibtool and will then make the necessary changes.

This is against the GNU libtool documentation, I think the offending packages should just be fixed correctly. Its just bad to use -lfoo when its not a system library.

@orbea, thanks for pointing that out. Do you happen to remember the exact section in the gnu libtool documentation which specifies that?

@midipix Actually it was in the automake documentation.

We recommend that you avoid using -l options in LDADD or prog_LDADD when referring to libraries built by your package. Instead, write the file name of the library explicitly as in the above cpio example. Use -l only to list third-party libraries. If you follow this rule, the default value of prog_DEPENDENCIES will list all your local libraries and omit the other ones.


GNU libtool was not as explicit, but its clear from the documenation they intended for .la files to be used for internal dependencies.


Since the current behavior appears to match the automake documentation and given no further comments, closing this for now.

Metadata Update from @midipix:
- Issue assigned to midipix
- Issue status updated to: Closed (was: Open)

11 months ago

Login to comment on this ticket.