SCons cannot find neither Boost nor TR1 on gcc 4.2.4 / Ubuntu 8.04

[Paul Pogonyshev]

I have downloaded MCT 1.1.1 and tried installing it.
I have also installed the boost library.
However on running scons (sudo scons install) I get the following error:

 Checking for C++ type std::hash <int>... (cached) no
Checking for C++ type std::tr1::hash <int>... (cached) no
Checking for C++ type boost::hash <int>... (cached) no if not hash_header:
        raise Exit ("*** error ***: no known hash function provider found")

*** error ***: no known hash function provider found

I also ran with cache-disable option for scons but it did not help.
However, when I comment these following 2 lines in SConstruct , it just goes fine

 if not hash_header:
        raise Exit ("*** error ***: no known hash function provider found")

[Paul Pogonyshev (doublep)]

Can you please attach 'config.log' file after running SCons?

Note that G++ 4.2 has a TR1 implementation that should be enough. E.g. here (Debian unstable) I have 4.1 and it works fine:

$ CXX=g++-4.1 scons
scons: Reading SConscript files ...
Checking for C++ type std::hash <int>... no
Checking for C++ type std::tr1::hash <int>... yes

And from 'config.log' I see it really uses 4.1:

...
g++-4.1 -o .sconf_temp/conftest_1.o -c -pedantic -Wno-long-long -Wall -Wno-unused -I. .sconf_temp/conftest_1.cpp
g++-4.1 -o .sconf_temp/conftest_1 .sconf_temp/conftest_1.o
scons: Configure: yes

[Govind (sgovind)]

Attached are the logs
I had ran it MCT-1.1.1 and 1.0.0.
I am attaching both the files.

Note I am able to use the MCT library properly. In particular I use
linked_hash_map.

Regards
Govind

On 11 July 2010 19:58, Paul Pogonyshev <email address hidden> wrote:
> Can you please attach 'config.log' file after running SCons?
>
> Note that G++ 4.2 has a TR1 implementation that should be enough.  E.g.
> here (Debian unstable) I have 4.1 and it works fine:
>
> $ CXX=g++-4.1 scons
> scons: Reading SConscript files ...
> Checking for C++ type std::hash <int>... no
> Checking for C++ type std::tr1::hash <int>... yes
>
> And from 'config.log' I see it really uses 4.1:
>
> ...
> g++-4.1 -o .sconf_temp/conftest_1.o -c -pedantic -Wno-long-long -Wall -Wno-unused -I. .sconf_temp/conftest_1.cpp
> g++-4.1 -o .sconf_temp/conftest_1 .sconf_temp/conftest_1.o
> scons: Configure: yes
>
> --
> SCons cannot find neither Boost nor TR1 on gcc 4.2.4 / Ubuntu 8.04
> https://bugs.launchpad.net/bugs/604349
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Miscellaneous Container Templates: New
>
> Bug description:
> I have downloaded MCT 1.1.1 and tried installing it.
> I have also installed the boost library.
> However on running scons (sudo scons install) I get the following error:
>
>  Checking for C++ type std::hash <int>... (cached) no
> Checking for C++ type std::tr1::hash <int>... (cached) no
> Checking for C++ type boost::hash <int>... (cached) no if not hash_header:
>        raise Exit ("*** error ***: no known hash function provider found")
>
> *** error ***: no known hash function provider found
>
> I also ran with cache-disable option for scons but it did not help.
> However, when I comment these following 2 lines  in SConstruct , it just goes fine
>
>  if not hash_header:
>        raise Exit ("*** error ***: no known hash function provider found")
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/libmct/+bug/604349/+subscribe
>

[Paul Pogonyshev (doublep)]

Apparently, this is a bug in SCons, Ubuntu or your setup if your Python and/or SCons are self-compiled. If you look in the files, you can see that every check ends with

...
    self.s = io.StringIO()
AttributeError: 'module' object has no attribute 'StringIO'

and SCons treats any error as "check failed". Maybe SCons shouldn't make such broad catches here that obviously catch errors absolutely not related to the check being performed. But in any case this is not an MCT bug.

[Govind (sgovind)]

Thanks for the reply, I had checked with scons 2.0.0 and an earlier
version (1.XX).
But there was not much of a difference.
I will do some more exploration and provide updates.
I am a bit busy now it might take some time.

Regards
Govind

On 14 July 2010 21:24, Paul Pogonyshev <email address hidden> wrote:
> Apparently, this is a bug in SCons, Ubuntu or your setup if your Python
> and/or SCons are self-compiled.  If you look in the files, you can see
> that every check ends with
>
> ...
>    self.s = io.StringIO()
> AttributeError: 'module' object has no attribute 'StringIO'
>
> and SCons treats any error as "check failed".  Maybe SCons shouldn't
> make such broad catches here that obviously catch errors absolutely not
> related to the check being performed.  But in any case this is not an
> MCT bug.
>
>
> ** Changed in: libmct
>       Status: New => Invalid
>
> --
> SCons cannot find neither Boost nor TR1 on gcc 4.2.4 / Ubuntu 8.04
> https://bugs.launchpad.net/bugs/604349
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Miscellaneous Container Templates: Invalid
>
> Bug description:
> I have downloaded MCT 1.1.1 and tried installing it.
> I have also installed the boost library.
> However on running scons (sudo scons install) I get the following error:
>
>  Checking for C++ type std::hash <int>... (cached) no
> Checking for C++ type std::tr1::hash <int>... (cached) no
> Checking for C++ type boost::hash <int>... (cached) no if not hash_header:
>        raise Exit ("*** error ***: no known hash function provider found")
>
> *** error ***: no known hash function provider found
>
> I also ran with cache-disable option for scons but it did not help.
> However, when I comment these following 2 lines  in SConstruct , it just goes fine
>
>  if not hash_header:
>        raise Exit ("*** error ***: no known hash function provider found")
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/libmct/+bug/604349/+subscribe
>

[Paul Pogonyshev (doublep)]

To me it looks like SCons is used with Python version it is not supposed to be used with. That's why I suspect a bug with Ubuntu dependencies.