0

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.

Improve this question
1

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.

Improve this answer
3
  • Ok, although in this case, configure didn't actually fail. It went all the way through, just that the summary at the end indicated that it didn't find some packages that I know I have installed. I was trying to figure out the reason why. I'll post the config summary a bit later on when I get home. I haven't actually tried to build or test the package yet. – Time4Tea Nov 17 '17 at 16:04
  • In that case config.log will still have the reason it decided it couldn’t find things, but instead of using my recipe above, you should just look for e.g. valgrind. – Stephen Kitt Nov 17 '17 at 16:06
  • I looked through the config output again and I think I was basically just misinterpreting what it was saying. I added some more details to my question above, but I think I understand it now. Thanks for your help! – Time4Tea Nov 18 '17 at 2:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.