Configure error cannot guess build type you must specify one

Here’s a shell script I use from within the application’s source directory:

update-configure(){

CONFIG=»»

for CONFIG in $(find -name config.guess) ; do

‘http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues
s;hb=HEAD’

done

for CONFIG in $(find -name config.sub) ; do

‘http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;
hb=HEAD’

done

}

From: «Felix Schütt» [mailto:sharazam@users.sf.net]
Sent: Sunday, July 17, 2016 12:05 PM
To: [msys2:discussion] general@discussion.msys2.p.re.sf.net
Subject: [msys2:discussion] No automake installed with MSYS2 — configure:
error: cannot guess build type; you must specify one

Hi,

I posted this issue on stackoverflow
(http://stackoverflow.com/questions/38421135/windows-automake-not-available-
in-msys64), but also wanted to ask here:

I am trying to follow this
http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html tutorial on how to
build 64-bit libraries on Windows using MSYS 64-bit. I am stuck on building
libiconv. I followed the tutorial closely — the problem is the «./configure»
step.

The step fails with :
configure: error: cannot guess build type; you must specify one
More specific, here is the full output:

checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /usr/bin/mkdir -p
checking for gawk… gawk
checking whether make sets $(MAKE)… no
checking whether make sets $(MAKE)… (cached) no
checking for gcc…
D:DevelopmentSFMLearnx86_64-4.9.2-release-posix-seh-rt_v4-rev2mingw64bi
ngcc
checking whether the C compiler works… yes
checking for C compiler default output file name… a.exe
checking for suffix of executables… .exe
checking whether we are cross compiling… no
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether
D:DevelopmentSFMLearnx86_64-4.9.2-release-posix-seh-rt_v4-rev2mingw64bi
ngcc accepts -g… yes
checking for
D:DevelopmentSFMLearnx86_64-4.9.2-release-posix-seh-rt_v4-rev2mingw64bi
ngcc option to accept ISO C89… none needed
checking for style of include used by make… none
checking dependency style of
D:DevelopmentSFMLearnx86_64-4.9.2-release-posix-seh-rt_v4-rev2mingw64bi
ngcc… none
checking how to run the C preprocessor…
D:DevelopmentSFMLearnx86_64-4.9.2-release-posix-seh-rt_v4-rev2mingw64bi
ngcc -E
checking for strip… /mingw/bin/strip
checking build system type… build-aux/config.guess: unable to guess system
type

This script, last modified 2009-02-03, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess
;hb=HEAD
and

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;h
b=HEAD

If the version you run (build-aux/config.guess) is already up to date,
please
send the following data and any information you think might be
pertinent to <config-patches@gnu.org <a=»» href=»mailto:config-patches@gnu.org»>config-patches@gnu.org > in
order to provide the needed
information to handle your system.

config.guess timestamp = 2009-02-03

uname -m = x86_64
uname -r = 2.4.1(0.294/5/3)
uname -s = MSYS_NT-10.0
uname -v = 2016-02-03 10:57

/usr/bin/uname -p = unknown
/bin/uname -X =

hostinfo =
/bin/universe =
/usr/bin/arch -k =
/bin/arch = x86_64
/usr/bin/oslevel =
/usr/convex/getsysinfo =

UNAME_MACHINE = x86_64
UNAME_RELEASE = 2.4.1(0.294/5/3)
UNAME_SYSTEM = MSYS_NT-10.0
UNAME_VERSION = 2016-02-03 10:57
configure: error: cannot guess build type; you must specify one

It told me to download config.guess and config.sub from the provided URL
(since my version of the script is apparently from 2009), however, I have no
idea where to put this script.

This
http://stackoverflow.com/questions/22181215/getting-configure-error-while-c
ompiling-corkscrew-using-cygwin answer suggests to exchange
%MSYS_ROOT%/usr/share/automake.1.11.1/config.guess, however automake isn’t
even installed! There is no folder «automake» in /usr/share.

Felix@felix MSYS /usr/share
$ ls
aclocal doc info magic misc pki
zoneinfo
awk emacs libalpm makepkg Msys readline zsh
bash-completion file licenses makepkg-template p11-kit tabset
cygwin gnupg locale man pacman terminfo

I do not know how to install automake on MSYS 64-bit, Google doesn’t help
either. I have downloaded «automake-1.11.1-1-msys-1.0.13-bin» and
config.guess and config.sub, but I don’t know where to put them.

Any help is appreciated. Also, I wanted to ask:

• Why is automake not included in MSYS2? Why. I just want to get a
  toolchain up and running so I can build my damn libraries.
• Why is config.guess and config.sub outdated in the first place? I
  downloaded MSYS2 about a week ago, the files are still from 2009.
• Why does MSYS2 not have find.exe in the /bin directory? Why do I
  have to install the 32-bit version first and the copy find.exe to the 64-bit
  version?
• How do I install automake?

Thank you for reading.

No automake installed with MSYS2 — configure: error: cannot guess build
type; you must specify one
https://sourceforge.net/p/msys2/discussion/general/thread/8d346729/?limit=2
5#bb49

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/msys2/discussion/general/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

Working on arm64 platform.
uname -a
Linux e7fac9d4ba1c 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:33:57 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
node -v
v10.9.0

While installing package in arm platform, i am facing below error:
cd deps/jscoverage && ./configure && make && mv jscoverage node-jscoverage
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… gawk
checking whether make sets $(MAKE)… yes
checking build system type… ./config.guess: unable to guess system type

This script, last modified 2008-01-23, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to config-patches@gnu.org in order to provide the needed
information to handle your system.

config.guess timestamp = 2008-01-23

uname -m = aarch64
uname -r = 4.10.0-38-generic
uname -s = Linux
uname -v = #42~16.04.1-Ubuntu SMP Tue Oct 10 16:33:57 UTC 2017

/usr/bin/uname -p =
/bin/uname -X =

hostinfo =
/bin/universe =
/usr/bin/arch -k =
/bin/arch =
/usr/bin/oslevel =
/usr/convex/getsysinfo =

UNAME_MACHINE = aarch64
UNAME_RELEASE = 4.10.0-38-generic
UNAME_SYSTEM = Linux
UNAME_VERSION = #42~16.04.1-Ubuntu SMP Tue Oct 10 16:33:57 UTC 2017
configure: error: cannot guess build type; you must specify one
Makefile:30: recipe for target ‘deps/jscoverage/node-jscoverage’ failed
make: *** [deps/jscoverage/node-jscoverage] Error 1
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! expresso@0.9.2 preinstall: make deps/jscoverage/node-jscoverage
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the expresso@0.9.2 preinstall script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2018-10-09T13_30_22_356Z-debug.log

Need to update config.guess for arm support.

Please suggest how to solve this issue for arm platform.

Перенос ПО на платформу Эльбрус

При сборке существующих программ порой возникает ряд типичных проблем и вопросов, которые отчасти систематизированы ниже (см. тж. страничку по компилятору).

В ALT RPM реализован макрос %e2k, рекомендуемый к применению в %ifarch.

configure: error: cannot guess build type; you must specify one

В архив исходников программы включены устаревшие копии этих файлов, поддержка e2k добавлена в gnu-config в 2015 году; достаточно обновить их вручную из свежей системной версии этого пакета или automake (который с большей вероятностью окажется под рукой) либо выполнить autoreconf -fisv:

cp -aLt . -- /usr/share/automake/config.{guess,sub}
autoreconf -fisv

В %changelog можно добавить, например^[1]:

- fix build on newer arches

configure: error: invalid value: boost_major_version=’‘

Препроцессор из lcc 1.25 может добавить лишний пробел в препроцессированный исходник, что ломает тест версии библиотеки boost, входящий в некоторые применяющие autoconf программы с типичной диагностикой (mcst#6826):

checking for Boost's header version...
configure: error: invalid value: boost_major_version=

Обход — смягчение регулярного выражения перед запуском configure (либо в m4/boost.m4 или ином его источнике перед запуском autoreconf; поправьте команду по месту):

# lcc's cpp adds an extra space breaking this regex
sed -r -i 's,^boost(.)lib(.)version,boost1lib2version,' configure m4/boost.m4

тесты на порядок байтов/битность

Нередко попадаются программы, которые интересует только длина указателей (размер integer) и, возможно, endianness; поскольку e2k — 64-разрядная LE-архитектура, ищем подстроку вроде __amd64__, читаем контекст, добавляем аналогично __e2k__.

Про невыровненный доступ к памяти на версиях архитектуры до пятой включительно («Эльбрус-8СВ») известно, что он достаточно дорогой; поэтому про unaligned access интересующемуся коду на <e2kv6 можно сообщить, что таковой отсутствует.

Размер строки кэша L1 — 32 байта, L2+ — 64 байта; судя по патчам МЦСТ и поведению -fprefetch, указывать следует именно 64.

cmake

В альтовых пакетах на cmake исправления проверок битности порой выглядят примерно так^[2]:

-%ifarch x86_64
+%if "%_lib" == "lib64"
 export LIB_SUFFIX=64
 %endif

- fixed build on 64-bit architectures

boost

В проектах на boost порой попадается тот ax_boost_base.m4, где в проверку на lib64 забит список архитектур; его придётся поправить перед запуском autoreconf^[3] как-то так:

%ifarch %e2k ppc64le riscv64
sed -i 's,aarch64,&|riscv64|ppc64le|e2k,' m4/ax_boost_base.m4
%endif

…после чего не забываем autoreconf -fisv (или %autoreconf).

Обратите внимание: характерная диагностика configure: error: Could not link against -l… может наводить на ложный след, если сбоит тест boost (но не приводит к останову), а вываливается тест последующей библиотеки.

В альтовом пакете autoconf-archive это исправлено начиная со сборки 2019.01.06-alt1.1 в p9_e2k и с 2021.02.19-alt1 — в p10_e2k и sisyphus_e2k.

SIMD

Алгоритм портирования таких программ простой:

1. ищем в исходниках макрос __x86_64__^[4] или на худой конец i386; если они покрывают фрагменты кода с SIMD-интринсиками (функции, имена которых начинаются на _mm_), то нам повезло;
2. заменяем defined __x86_64__ на defined __x86_64__ || defined __e2k__;
3. если попадается динамическая проверка наличия MMX/SSE, то указываем, что у нас всё есть до SSE4.1^[5];
4. к asm-вставкам нужно творчески подходить, но чаще проще готовый generic-вариант кода использовать.

См. тж. проект SIMD Everywhere.

Примечание: несмотря на некоторую аппаратную поддержку выполнения SIMD-инструкций, по сути они реализуются в компиляторе и осмысленность задействования может отличаться от проекта к проекту — возможно замедление, особенно на AVX* и архитектурах ранее e2kv5.

Примечание: если собираемый код замечает arm_neon.h и радостно пытается собрать ARM-ассемблер — сообщите ему в явном виде, что NEON нет: в любом случае этот набор интринсиков хуже конвертируется в итоговые вектора на e2k.

компилятор/архитектура

Имейте в виду при выписывании #ifdef:

• __e2k__ — это архитектура;
• __LCC__ — компилятор;
• __MCST__ — поставщик и того, и другого (макрос взводится с версии 1.25).

Во-первых, lcc есть не только для e2k (привет sparc), поэтому если делается патч под особенности lcc (и, вероятнее всего, фронтенда edg), то правильнее использовать __LCC__ .

Во-вторых, со временем на e2k могут появится и другие компиляторы, например, clang через соответствующий бэкенд на основе lcc. И у них уже может не быть макроса __LCC__ , а вот __e2k__ будет.

Поэтому мне представляется правильным архитектурно-зависимые изменения в e2k заворачивать, а компиляторо-зависимые в LCC. Понятно, что в реальной жизни их отличить не всегда просто. — @bircoph

отсутствие makecontext()

На Эльбрусах makecontext_e2k() выделяет память под дополнительные стеки, поэтому если просто заменить s/makecontext/makecontext_e2k/, в программе может появиться утечка памяти. Нужно ещё поставить вызов freecontext_e2k() там, где выделенный для makecontext_e2k() ucp.uc_stack перестаёт использоваться под данный контекст, т.е. где:

1. ucp.uc_stack освобождается через free();
2. ucp.uc_stack переиспользуется, например, под другой контекст.

Должна стоять проверка на makecontext < 0: makecontext_e2k() возвращает значение int, а не void. Значение вызова необходимо проверять на статус ошибки (< 0).

Если речь про coroutines, надо уходить с fcontext на портабельную вещь, поддерживающую ucontext-e2k (например, koishi).

отсутствие cpuid.h

См. тж. wiki.elbrus.ru/CPU_id

Обуславливаем соответствующий #include и обращения к функциям так:

#if defined(__i386__) || defined(__x86_64__)

…не забывая добавить подходящую по смыслу заглушку вместо результата функции.

При необходимости подробного различения процессоров «Эльбрус» обратите внимание на __builtin_cpu_is(); в lcc от 1.23.23 и 1.24.10 должны быть доступны более удобные __builtin_cpu_name() и __builtin_cpu_arch() (#4484).

Есть альтернативный способ — через чтение регистра IDR, что позволяет определить модель процессора если код скомпилирован под другой процессор и даже если недоступен /proc/cpuinfo.
Для него написана маленькая библиотека под WTFPL.

SIGILL вместо ожидаемого сигнала

Обратите внимание, что на e2k в некоторых случаях можно получить SIGILL (Illegal instruction) вместо ожидаемого SIGSEGV (Segmentation fault), SIGBUS (Bus error) или SIGFPE (Floating point exception).

Не тот сигнал приходит, как правило, либо в результате работы оптимизаций, либо при ручном написании кода на ассемблере или ассемблерных вставках^[6]. Если по каким-то причинам нужно поймать именно тот сигнал, который бы поймался на других архитектурах, то следует использовать режим с отключением оптимизаций, задействующих полуспекулятивный режим исполнения:

• -O0 — режим компиляции без оптимизаций;
• -O1 — минимальный набор оптимизаций;
• -fcontrol-spec — запрет полуспекулятивных обращений к памяти (для сохранения сингалов SIGSEGV и SIGBUS);
• -fno-fp-spec — запрет полуспекулятивных вещественных операций (для сохранения сигнала SIGFPE).

См. тж. Руководство и posix_signals.html^[7].

наивные тесты в cmake

Если в каком-либо проекте на cmake вылезает «неизвестная опция», как в glslang:

if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS "9.0.0")
 add_compile_options(-Werror=deprecated-copy)
endif()

— это прибитая гвоздями зависимость от gcc/clang; нужно:

1. проверить доступность опции и выставить переменную, см. здесь; пример: раз, два;
2. добавить опцию, если выставлена переменная; пример.

отсутствие sys/io.h

Данный заголовок существует для небольшого количества архитектур: alpha, arm, ia64, x86, x86_64 и определяет inline-работу с портами ввода-вывода, которые только на них в этом виде и наличествуют. На всех других архитектурах (включая aarch64 и ppc64le) соответствующий код подлежит усечению (при возможности) либо переработке, если на bit banging завязана ключевая функциональность программы.

Ссылки

• эльбрус/lcc
• Руководство по эффективному программированию на платформе «Эльбрус». 3. Отличия в интерфейсах
• Шпаргалка по портированию
  • Заметки по защищённому режиму (ptr128)
• Доклады из серии ALT на e2k:
  • Free software porting on the Elbrus architecture
  • Особенности портирования СПО на Эльбрус (Андрей Савченко, OSSDEVCONF-2019)
• Портирование Embox:
  • Embox начинает восхождение на Эльбрус 2018,
  • Восхождение на Эльбрус — Разведка боем. Техническая Часть 1. Регистры, стеки и другие технические детали 2019,
  • Восхождение на Эльбрус — Разведка боем. Техническая Часть 2. Прерывания, исключения, системный таймер 2019
  • Embox на процессоре Эльбрус. Или никогда не забывайте о том, что получили при разведке 2020
• Портирование Java на Эльбрус
• Портирование JS на Эльбрус
• Константин Трушкин: ответы на вопросы (видео)
• Yandex Day: 3. Компилятор для процессоров «Эльбрус». Алексей Маркин (видео)
• Yandex Day: 4. Прикладное программирование на Эльбрусе. Антон Аникин (видео)
• Как мы переносили современные игры на процессор Эльбрус-8С (Gaijin Entertainment)
• Ускорение вычислений с использованием высокопроизводительных математических и мультимедийных библиотек для архитектуры Эльбрус (EML)
• Это непростое условное выполнение
• Узкие места производительности Эльбрусов публичный сбор запросов на оптимизацию подсистем
• Elbrus porting cheat sheet
• эльбрус/оптимизация
• Нет софта под Эльбрус?
• Опыт портирования геометрического ядра C3D на платформу «Эльбрус»
• История портирования Reindexer’а – как покорить Эльбрус за 11 дней
• Запуск на Эльбрусе платформы для нейросетей PuzzleLib

Примечания

re

вот что в результате, непойму в чем дело -(
jkcool@debian:~/Clamav/clamav-0.96$ ./configure —prefix=/usr build=i686-pc-linux
checking build system type… config/config.guess: unable to guess system type

This script, last modified 2009-06-10, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;…
and
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb…

If the version you run (config/config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to <config-patches@gnu.org> in order to provide the needed
information to handle your system.

config.guess timestamp = 2009-06-10

uname -m = i686
uname -r = 2.6.26-1-686
uname -s = Linux
uname -v = #1 SMP Sat Jan 10 18:29:31 UTC 2009

/usr/bin/uname -p =
/bin/uname -X =

hostinfo =
/bin/universe =
/usr/bin/arch -k =
/bin/arch =
/usr/bin/oslevel =
/usr/convex/getsysinfo =

UNAME_MACHINE = i686
UNAME_RELEASE = 2.6.26-1-686
UNAME_SYSTEM = Linux
UNAME_VERSION = #1 SMP Sat Jan 10 18:29:31 UTC 2009
configure: error: cannot guess build type; you must specify one

jkcool

(11.04.10 09:29:12 MSD)

First thing to say is I’m far from being competent with this task and it’s a long time since I did any builds. I’ve posted under advanced users not because I am one but because I’m hoping that an advance user can help!

I’m getting stuck with «configure: error: cannot guess build type; you must specify one» on the command ../dist/configure —enable-cxx

What I’m trying to do at this point is set up Berkeley DB version 4.8.

When I Google I find:

This script, last modified 2008-01-23, has failed to recognize the
operating system you are using. It is advised that you download the
most up to date version of the config scripts from

http://git.savannah.gnu.org/gitweb/?p=c … ss;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=c … ub;hb=HEAD

If this is the fix, how exactly can I implement it from terminal (PuTTY to a headless Raspberry Pi 4). Is there an update command or what would be the command line instruction(s) please?

Other details below.

Distributor ID: Ubuntu
Description: Ubuntu 20.04 LTS
Release: 20.04
Codename: focal

I’m trying to set up Berkeley DB version 4.8 using:

wget http://download.oracle.com/berkeley-db/ … .NC.tar.gz
tar -xzvf db-4.8.30.NC.tar.gz
sed -i ‘s/__atomic_compare_exchange/__atomic_compare_exchange_db/g’ db-4.8.30.NC/dbinc/atomic.h
cd db-4.8.30.NC/build_unix/
../dist/configure —enable-cxx
make

I’m getting stuck at
../dist/configure —enable-cxx
checking build system type… ../dist/config.guess: unable to guess system type

This script, last modified 2009-02-03, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

http://git.savannah.gnu.org/gitweb/?p=c … ss;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=c … ub;hb=HEAD

If the version you run (../dist/config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to <config-patches@gnu.org> in order to provide the needed
information to handle your system.

config.guess timestamp = 2009-02-03

uname -m = aarch64
uname -r = 5.4.0-1012-raspi
uname -s = Linux
uname -v = #12-Ubuntu SMP Wed May 27 04:08:35 UTC 2020

/usr/bin/uname -p = aarch64
/bin/uname -X =

hostinfo =
/bin/universe =
/usr/bin/arch -k =
/bin/arch = aarch64
/usr/bin/oslevel =
/usr/convex/getsysinfo =

UNAME_MACHINE = aarch64
UNAME_RELEASE = 5.4.0-1012-raspi
UNAME_SYSTEM = Linux
UNAME_VERSION = #12-Ubuntu SMP Wed May 27 04:08:35 UTC 2020
configure: error: cannot guess build type; you must specify one
user@ubuntu:/bin/db-4.8.30.NC/build_unix$

$ ./configure
.................
checking build system type... /bin/sh: ./config.guess: No such file or directory
configure: error: cannot guess build type; you must specify one

6 Answers

$ which automake
$ automake --version

This script, last modified 2008-01-23, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

  http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
  http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

./configure --build=aarch64-unknown-linux-gnu

./configure --build=x86_64-unknown-linux-gnu

./config.guess

cp /usr/share/automake-`pacman -Q --info automake|grep -i version| awk -F ":" '{print $2}'| awk '{$1=$1};1'| awk -F "." '{print $1"."$2}'`/config.guess .