Skip to content

Commit

Permalink
sqlite: do not contaminate dependent libtool-based projects with sqli…
Browse files Browse the repository at this point in the history
…te dependencies

sqlite is built as a shared library, but libtool nevertheless adds -lz into the
link commands of the dependent projects, which fail to link if they do not
directly depend on libz.  Fix this by clearing dependency_libs in libsqlite3.la.
  • Loading branch information
orivej committed May 29, 2018
1 parent 2c92213 commit c83a530
Showing 1 changed file with 5 additions and 0 deletions.
5 changes: 5 additions & 0 deletions pkgs/development/libraries/sqlite/default.nix
Original file line number Diff line number Diff line change
Expand Up @@ -66,6 +66,11 @@ stdenv.mkDerivation rec {
echo ""
'';

postInstall = ''
# Do not contaminate dependent libtool-based projects with sqlite dependencies.
sed -i $out/lib/libsqlite3.la -e "s/dependency_libs=.*/dependency_libs='''/"
'';

meta = {
description = "A self-contained, serverless, zero-configuration, transactional SQL database engine";
downloadPage = http://sqlite.org/download.html;
Expand Down

3 comments on commit c83a530

@bjornfor
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about the other way, adding -L${zlib}/lib so that -lz works?

Or, should this change be submitted upstream?

@orivej
Copy link
Contributor Author

@orivej orivej commented on c83a530 Jun 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about the other way, adding -L${zlib}/lib so that -lz works?

Then projects that do not declare a dependency on zlib will be able to link to it. Some definitions do this, e.g. gss, but they should not do this for dynamic libraries because dynamic libraries already convey dependency information.

Or, should this change be submitted upstream?

AFAIK this is an issue with libtool, not sqlite. The list of dependencies that it generates, dependency_libs, is needed for static libraries because they do not convey their dependencies in themselves, but it is not useful and a bit harmful for dynamic libraries (because command lines get longer, and programs and libraries list indirect dependencies in their NEEDED lists, unless the linker is invoked with -Wl,--as-needed).

Bringing this issue to libtool upstream is interesting, but I don't feel confident to do it.

@orivej
Copy link
Contributor Author

@orivej orivej commented on c83a530 Jun 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact it is OK to delete .la files of shared libraries, I was just conservative with sqlite. We should probably add their deletion into the default fixup phase. (It is easy to separate them from .la files for static libraries: they contain e.g. dlname='libsqlite3.so.0'.) See also https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Handling_Libtool_Archives and https://www.archlinux.org/news/operation-libtool-slay-in-testing/

Please sign in to comment.