ninja build failure (hash_map not found)

multix

multix

Hi,

I need to build graphics/dri which requires and pulls in a build of devel/ninja, which fails with the following error. Any ideas? isn't hash_map something part of C++?


Code: 
===>  Building for ninja-1.6.0,2
bootstrapping ninja...
warning: A compatible version of re2c (>= 0.11.3) was not found; changes to src/*.in.cc will not affect your build.
In file included from src/build.cc:27:
In file included from src/build_log.h:22:
src/hash_map.h:91:10: fatal error: 'ext/hash_map' file not found
#include <ext/hash_map>
  ^
1 error generated.
when running:  c++ -MMD -MT build/build.o -MF build/build.o.d -Wall -Wextra -Wno-deprecated -Wno-unused-parameter -fno-rtti -fno-exceptions -fvisibility=hidden -pipe -Wno-missing-field-initializers '-DNINJA_PYTHON="python2.7"' -O2 -DNDEBUG -fdiagnostics-color -I/usr/local/include -DNINJA_HAVE_BROWSE -O2 -pipe -march=pentium4 -fstack-protector -fno-strict-aliasing  -c src/build.cc -o build/build.o
Traceback (most recent call last):
 
Code: 
FreeBSD 10.1-RELEASE-p16 (GENERIC) #0: Tue Jul 28 11:41:12 UTC 2015

I may also add that my clang version is:

Code: 
clang36-3.6.2  C, Objective-C, and C++ compiler
 
Actually very little, look:
Code: 
> cat /etc/make.conf
CPUTYPE?=pentium4
DISABLE_VULNERABILITIES=yes
DEFAULT_VERSIONS+=perl5=5.20

Where should ext/hash_map

Should it be in clang? Or could a dependency/port need rebuilding?
 
Remove CPUTYPE - it is not needed - the system should recognize it (and may causes errors) and DISABLE_VULNERABILITIES may comfortable but is not good in /etc/make.conf.

=> pentium4 maybe you try to compile it with MAKE_JOBS_UNSAFE=yes (maybe it is something with parallel).

where should ext/hash_map
Click to expand...

Code: 
locate ext/hash_map
/usr/include/c++/v1/ext/hash_map
/usr/local/lib/gcc48/include/c++/ext/hash_map
/usr/src/contrib/libc++/include/ext/hash_map
/usr/src/contrib/libstdc++/include/ext/hash_map

maybe there is something wrong with your sources?
( wget ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/10.1-RELEASE/src.txz)
 
multix said:
DISABLE_VULNERABILITIES=yes
Click to expand...

This means "yes, go ahead and install packages with known security vulnerabilities. Do not put this in /etc/make.conf, and remember that it is a safety mechanism when you override it manually.
 
wblock@ said:
This means "yes, go ahead and install packages with known security vulnerabilities. Do not put this in /etc/make.conf, and remember that it is a safety mechanism when you override it manually.
Click to expand...
Well, I know it is not finest, but when certain packages go on for months having this (e.g. seamonkey) this was just the most honest solution.
I don't suppose this is relevant with my problem though.
 
talsamon said:
Code: 
locate ext/hash_map
[CODE]/usr/include/c++/v1/ext/hash_map
/usr/local/lib/gcc48/include/c++/ext/hash_map
/usr/src/contrib/libc++/include/ext/hash_map
/usr/src/contrib/libstdc++/include/ext/hash_map[/CODE]

maybe there is something wrong with your sources?
( wget ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/10.1-RELEASE/src.txz)
Click to expand...

Interesting. I did this:
Code: 
> sudo find / -name hash_map.h
/usr/src/contrib/libstdc++/include/backward/hash_map.h
/usr/src/contrib/libstdc++/include/debug/hash_map.h
/usr/ports/devel/ninja/work/ninja-1.6.0/src/hash_map.h

and this:
Code: 
> sudo find / -name hash_map
/usr/local/lib/gcc5/include/c++/backward/hash_map
/usr/local/lib/gcc5/include/c++/ext/hash_map
/usr/src/contrib/libc++/include/ext/hash_map
/usr/src/contrib/libstdc++/include/ext/hash_map
/usr/src/contrib/libstdc++/include/debug/hash_map

while you have gcc48 and I gcc5, I suppose it is not relevant, since ninja appears to build with clang. Your first line
Code: 
/usr/include/c++/v1/ext/hash_map
Is relevant, I think that is indeed the file looked after!

Should this come from a "compiler" package? How does your c++ includes look like? here mine:
Code: 
> ls -l /usr/include/c++/
total 4
drwxr-xr-x  7 root  wheel  1024 Oct 14 09:34 4.2
drwxr-xr-x  3 root  wheel  2048 Oct 14 08:55 v1

Inside v1, I have lots of file but no "ext". The files are all form Oct 14, so from the time I did the upgrade to 10.1, they aren't a leftover.

Something in the upgrade went wrong? What is the best way to fix it?
 
cd /usr/src
rm -rf *
Either you fetch it like I posted above with wget and decompress it in /usr/src or (better)
svn checkout http://svn.freebsd.org/base/release/10.1.0/ /usr/src.
 
I did so... but it didn't help: the problem I guess is not /usr/src, but
/usr/include.
I then had another idea: searching for base for the c++ includes, with:
tar xzpvf /root/base.txz ./usr/include/c++/

This apparently worked, at least, it allowed me to build ninja.

My only concern is that I am running 10.1.0 p24, while the tgz tarballs are from "RELEASE" so I think I could miss potential update? Or do these updates that to not modify minor FreeBSD releases not include changes to the headers?
 
You must log in or register to reply here.
Back
Top