wrong dependency_libs in .la file after make install with DESTDIR flag
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-errorin 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
libgcryptin 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
.laifile (note thei) that reads as above (wrong dependency) and is transported to the resulting.lafile inDESTDIR - an
.lafile that has precisely thedependency_libsline 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-errorin 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
libgcryptin 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
.laifile (note thei) that reads as above (wrong dependency) and is transported to the resulting.lafile inDESTDIR - an
.lafile that has precisely thedependency_libsline 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-errorin 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
libgcryptin 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
.laifile (note thei) that reads as above (wrong dependency) and is transported to the resulting.lafile inDESTDIR - an
.lafile that has precisely thedependency_libsline 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-errorin 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
libgcryptin 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
.laifile (note thei) that reads as above (wrong dependency) and is transported to the resulting.lafile inDESTDIR - an
.lafile that has precisely thedependency_libsline 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