I've been trying to compile the GnuTLS package from source, as part of a BLFS (Linux From Scratch) system. Here is the LFS page for it.
I have installed all of the required and recommended packages that are listed on that page; however, when I ran ./configure at the top of the source tree for GnuTLS, according to the script output, it didn't seem to find several of those packages, for example valgrind, libunistring, libtasn1.
So, I am just wondering what is the best way to troubleshoot this, if a configure script doesn't seem to work correctly? I had a look at config.log, but that didn't seem very helpful (at least in the case of valgrind). I also tried to have a look through the configure script itself, but it's a 40,000+ line monster.
Ok, I think I've been a bit silly and misunderstood the configure script. The configure summary said this:
configure: summary of build options:
version: 3.5.14 shared 44:6:14
Host/Target system: x86_64-pc-linux-gnu
Build system: x86_64-pc-linux-gnu
Install prefix: /usr
Compiler: gcc
Valgrind: no
CFlags: -g -O2
Library types: Shared=yes, Static=no
Local libopts: yes
Local libtasn1: no
Local unistring: no
Use nettle-mini: no
Documentation: yes (manpages: yes)
Which I took to mean that it hadn't found those packages (I interpreted 'Local' as meaning 'on my computer'). However, searching in more detail through the output, I found these:
checking for LIBTASN1... yes
checking whether to use the included minitasn1... no
checking for libunistring... yes
checking how to link with libunistring... /usr/lib/libunistring.so
It seems that it did actually find those packages, and 'Local' in the summary must have been referring to GnuTLS' own built-in version of those libraries. It was a bit confusing, but it makes sense now. For valgrind, I see this:
checking for valgrind... valgrind
checking whether self tests are run under valgrind... no
So, again it seems to have found it, although it doesn't seem to want to use it for the self tests, for some reason.
Anyway, I'll go ahead and build it and see if it tests ok.
config.log should contain the exact reason why configure failed, but it can be hard to find it. To do so, you should start from the end of config.log; there you’ll see a dump of the full configure state at the point where it stopped, which is daunting, but if you skip past that, you should find the error which broke configure. Look for Running config.status, and scroll up...
In the case of an Autoconf-generated setup, there’s not much point in reading configure itself; it’s much more useful to look at its source code, configure.ac (or configure.in if it’s an old piece of software), along with any .m4 file which is pulled in.
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加