#49 Over-consistent use of .libs
Closed a year 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] == '/')
  strcpy(mark,".libs");
else
  strcpy(mark,"/.libs");

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

  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.

https://www.gnu.org/software/automake/manual/html_node/Linking.html

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

https://www.gnu.org/software/libtool/manual/html_node/Linking-libraries.html#Linking-libraries

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)

a year ago

Login to comment on this ticket.

Metadata