wrong dependency_libs in .la file after make install with DESTDIR flag

Question

I am maintaining a locally-compiled version of gpg. The end result is supposed to be a standalone suite of packages living in /opt/local (with the standard tree under that base directory: usr/bin for binaries, usr/lib for libraries, etc.).

As part of the installation process, I

• configure, compile and install libgpg-error in a temporary directory with

LDFLAGS="-L/opt/local/usr/lib" CFLAGS="-I/opt/local/usr/include" ./configure --prefix=/usr

MAKEFLAGS="-j4" DESTDIR=~/Downloads/tmp/libgpg-error make install

• make a Slackware package out of that directory and install it to /opt/local, resulting in the above-mentioned directory tree structure with executables in /opt/local/bin, etc.

• configure, compile and install libgcrypt in a temporary directory, as previously, this time taking into account that it depends on the previously-installed libgpg-error (hence the extra option passed to ./configure):

LDFLAGS="-L/opt/local/usr/lib" CFLAGS="-I/opt/local/usr/include" ./configure --prefix=/usr --with-libgpg-error-prefix=/opt/local/usr

MAKEFLAGS="-j4" DESTDIR=~/Downloads/tmp/libgcrypt make install

Since libgcrypt depends on libgpg-error, the make install step on the former produces an .la file

~/Downloads/tmp/libgcrypt/usr/lib/libgcrypt.la

containing the following dependency line:

# Libraries that this one depends upon.
dependency_libs=' -L/opt/local/usr/lib /usr/lib/libgpg-error.la'

The issue:

Now, when I compile and try to install ntbtls, which is aware of both of the above packages, it

• reads /opt/local/usr/lib/libgcrypt.la
• sees the dependency on /usr/lib/libgpg-error.la, and
• tries to read that file, which doesn't exist, resulting in an error.

Everything goes through fine if I change that dependency_libs line to

# Libraries that this one depends upon.
dependency_libs=' -L/opt/local/usr/lib /opt/local/usr/lib/libgpg-error.la'

---

I've resorted to doing that manually (well, via a small script), but there must be some way around this through options I can pass to ./configure. One reason I think that is that in the libgcrypt source directory, after running the make install command, I have both

• an .lai file (note the i) that reads as above (wrong dependency) and is transported to the resulting .la file in DESTDIR
• an .la file that has precisely the dependency_libs line I want:

diff <source_dir>/src/.libs/libgcrypt.la <source_dir>/src/.libs/libgcrypt.lai

returns

20c20
< dependency_libs=' -L/opt/local/usr/lib /opt/local/usr/lib/libgpg-error.la'
---
> dependency_libs=' -L/opt/local/usr/lib /usr/lib/libgpg-error.la'
31c31
< installed=no
---
> installed=yes

I am not familiar with the inner workings of libtool and don't know why the /opt/local is lost somewhere during the installation process resulting in this distinction between the two files (.la vs .lai).

I haven't found much discussion of .lai files at all, let alone more abstruse topics on how or when they're produced, but I'd like to understand that process in the hope of somehow hacking it for this specific purpose.

What I've tried:

Changing the --prefix or --libdir flags aren't really good options, because they result in a mangled directory structure for the installed packages under /opt/local.

Answer 1

To arrive at the end result I believe you're describing, the only method I'm aware of that could produce it is to copy your dependencies into /opt/local (consistent with the FHS) and copy the source code into a temporary build directory there as well, after which you could chroot into /opt/local and run the configure script with --prefix="".

Referring back to the FHS for a minute though, I believe your difficulties would be much reduced if you found a way to adapt the output of a build with --prefix=/usr/local to your purposes.