In this article, we will see how to solve ltconfig: you must specify a host type if you use `--no-verify' error. If you are installing older version of libxml2-X.X from source code then during running of configure script, you might notice this error in your system. This error basically means that the ltconfig script, which is part of the Libtool suite used for managing the compilation of shared libraries, requires additional information about the host system type when the --no-verify option is used.

The --no-verify option in ltconfig is used to bypass some of the configuration checks, but when this option is used, you must explicitly specify the host system type to ensure that ltconfig can configure the build environment correctly.

 

Solved "ltconfig: you must specify a host type if you use `--no-verify'"

Also Read: 20+ Practical tar command examples for Linux Administrators

In my case, when I was trying to install libxml2-2.0.0 on Ubuntu server then while running configure script I noticed ltconfig: you must specify a host type if you use `--no-verify' error as shown below.

cyberithub@ubuntu:~/libxml2-2.0.0$ ./configure
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... missing
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for a BSD compatible install... /usr/bin/install -c
checking how to run the C preprocessor... gcc -E
checking for rm... /usr/bin/rm
checking for mv... /usr/bin/mv
checking for tar... /usr/bin/tar
checking host system type... Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized

checking build system type... Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized

checking for ranlib... ranlib
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
updating cache ./config.cache
ltconfig: you must specify a host type if you use `--no-verify'
Try `ltconfig --help' for more information.
configure: error: libtool configure failed

While above error can occur due to many reasons but in my case it was due to usage of outdated build script i.e config.sub. If this is the case with you as well then to fix above error, you have to replace config.sub configuration with the latest one. You can get the correct configuration from here. You can take the configuration and replace the older one with the latest one. But it is important that before changing the configuration, you take the backup of current config.sub contents first in case the latest one does not work, just to be on safe side.

cyberithub@ubuntu:~/libxml2-2.0.0$ cp config.sub config.sub_bkp

Then replace the configuration as shown below.

cyberithub@ubuntu:~/libxml2-2.0.0$ nano config.sub

Once done, run configure script again to verify if this works now. This time you will notice that the script runs successfully as shown below.

cyberithub@ubuntu:~/libxml2-2.0.0$ ./configure
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... missing
checking for gcc... (cached) gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for a BSD compatible install... /usr/bin/install -c
checking how to run the C preprocessor... (cached) gcc -E
checking for rm... (cached) /usr/bin/rm
checking for mv... (cached) /usr/bin/mv
checking for tar... (cached) /usr/bin/tar
checking host system type... x86_64-unknown-linux-gnu
checking build system type... x86_64-unknown-linux-gnu
checking for ranlib... (cached) ranlib
checking for ld used by GCC... (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes
checking for BSD-compatible nm... (cached) /usr/bin/nm -B
checking whether ln -s works... (cached) yes
checking for object suffix... o
checking for executable suffix... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions ... no
checking if gcc static flag -static works... -static
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking command to parse /usr/bin/nm -B output... ok
checking how to hardcode library paths into programs... immediate
checking for /usr/bin/ld option to reload object files... -r
checking dynamic linker characteristics... Linux ld.so
checking if libtool supports shared libraries... yes

*** Warning: the command libtool uses to detect shared libraries,
*** /usr/bin/file, produces output that libtool cannot recognize.
*** The result is that libtool may fail to recognize shared libraries
*** as such. This will affect the creation of libtool libraries that
*** depend on shared libraries, but programs linked with such libtool
*** libraries will work regardless of this problem. Nevertheless, you
*** may want to report the problem to your system manager and/or to
*** bug-libtool@gnu.org

checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for objdir... .libs
creating libtool
loading cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for zlib.h... yes
checking for gzread in -lz... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for ANSI C header files... yes
checking for fcntl.h... yes
checking for unistd.h... yes
checking for ctype.h... yes
checking for dirent.h... yes
checking for errno.h... yes
checking for malloc.h... yes
checking for stdarg.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for time.h... yes
checking for ieeefp.h... no
checking for nan.h... no
checking for math.h... yes
checking for fp_class.h... no
checking for float.h... yes
checking for stdlib.h... yes
checking for sys/socket.h... yes
checking for netinet/in.h... yes
checking for arpa/inet.h... yes
checking for netdb.h... yes
checking for sys/time.h... yes
checking for sys/select.h... yes
checking for strftime... yes
checking for strdup... yes
checking for strndup... yes
checking for strerror... yes
checking for snprintf... yes
checking for finite... yes
checking for isnand... no
checking for fp_class... no
checking for class... no
checking for fpclass... no
checking for strftime... (cached) yes
checking for localtime... yes
checking for gethostent... yes
checking for setsockopt... yes
checking for connect... yes
checking for isnan... yes
checking for isinf... yes
checking for append_history in -lhistory... yes
checking for readline in -lreadline... yes
updating cache ./config.cache
creating ./config.status
creating libxml.spec
creating Makefile
creating doc/Makefile
creating example/Makefile
sed: can't read ./example/Makefile.in: No such file or directory
creating xmlversion.h
creating xml-config
creating win32config.h
creating config.h

 

In case after following above solution, if you still see the same error then to resolve you can follow below solution, whichever works for you:-

1. Specify the Host Type: Determine the host system type (e.g., x86_64-pc-linux-gnu) and explicitly specify it using the --host option when running the configure script. The host type is typically a triplet consisting of CPU architecture, manufacturer, and operating system.

2. Avoid Using --no-verify: If possible, avoid using the --no-verify option unless it's necessary for your specific use case. Removing this option might allow the configuration process to proceed without requiring the explicit specification of the host type.