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

Multi tool use
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-installedlibgpg-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 thei
) that reads as above (wrong dependency) and is transported to the resulting.la
file inDESTDIR
- an
.la
file that has precisely thedependency_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
.
make configure
add a comment |
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-installedlibgpg-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 thei
) that reads as above (wrong dependency) and is transported to the resulting.la
file inDESTDIR
- an
.la
file that has precisely thedependency_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
.
make configure
add a comment |
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-installedlibgpg-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 thei
) that reads as above (wrong dependency) and is transported to the resulting.la
file inDESTDIR
- an
.la
file that has precisely thedependency_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
.
make configure
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-installedlibgpg-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 thei
) that reads as above (wrong dependency) and is transported to the resulting.la
file inDESTDIR
- an
.la
file that has precisely thedependency_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
.
make configure
make configure
edited Feb 15 at 4:56
grobber
asked Feb 15 at 2:27
grobbergrobber
62
62
add a comment |
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1405925%2fwrong-dependency-libs-in-la-file-after-make-install-with-destdir-flag%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1405925%2fwrong-dependency-libs-in-la-file-after-make-install-with-destdir-flag%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
xhUiug5tM5DN8OU