I am not able to install the jaula in solaris 2.10 version
Status: Beta
Brought to you by:
morongo
Menu
▾
▴
config log file
Logged In: YES
user_id=1503114
Originator: NO
Hello,
ostream header is basically used for providing std::ostringstream stream class and is part of the STL library. I presume that if your C++ compiler is correctly installed this class must exist but in another header. Can you tell me if there is a ostream.h (with .h attached to the end) file in your system that includes the std::ostringstream class.
If this is the situation, by simply replacing "#include <ostream>" by "#include<ostream.h>" along the sources and by removing ostream check from configuration you could easyly compile the library.
In case you can confirm me that ostream.h exists, is usable and contains the required class, I can make the changes in the project for you but, as I don't have a Solaris 2.10 machine at hand, I can not test it.
Please tell me if the header exits and, if you prefer to make the changes by yourself or if we can work in a co-operative way in which I perform the changes on the sources and you try to compile it on a Solaris 2.10 box.
Also, if you have already solved the problem, please let me know so I can clear the bug from the pending queue.
Regards,
Morongo
Logged In: YES
user_id=1503114
Originator: NO
Hello,
In my previous answer, I gave you some alternatives to try out based on the comments you provided about the no existence of the ostream header but, now I am looking into config.log more carefully and I find a quite different situation.
The problem that config.log reports is that your compiler is unable to find headers of the type bits/*.h where bits/ is a standard directory below the compiler default header location. This header directory should be automatically installed during compiler installation or by libc6 (development package) installation and configuration process does not require its existence directly but usual standard c++ headers (like ios or fstream) does.
The only reasons for these headers (bits/*h) not to be present but still required by standard c++ headers I can figure out is that you have more than a c++ compiler available in your system and that these multiple installation have collided by overwriting some data in any way, that your c++ compiler installation have failed and is not fully operational or that the file systems that contains this data are corrupt and some information has been lost.
I consider the first option as the most likely so, please check if gcc-3.4.3 is your usual c++ compiler as the headers found by the configuration process seem to belong to it.
Case you have more than a c++ compiler available and want to try another one, you can do this by declaring it in the configuration line by:
$ CXX=full_path_to_alternative_compiler ./configure
Proceeding in a similar manner, in case you have bits/ directory available but your compiler does not default to it by any reason, you can declare its path in the configuration line by:
CPPFLAGS="-Ipath_to_alternative_bits_directory" ./configure
In case the inclusion of this new directory solves the initial problem but creates new dependency problems because of the lack of another directories (what can be seen in config.log), multiple header directories can be specified in the same line as shown below.
CPPFLAGS="-Ipath_to_alternative_bits_directory -Ipath_to_another_required_directory" ./configure
I hope this could help you solving the compilation issue. Please tell me if any of this worked.
Regards,
Morongo