Contradiction between cling and compiler

I have recompiled Root 6.24.02 from scratch.
Then I recompiled the all STAR software. It is working.
Then I run cling macro and got:
In module ‘std’ imported from input_line_1:1:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/…/…/…/…/include/c++/4.8.5/bits/stl_vector.h:415:37: error: no member named ‘_M_start’ in ‘std::_Vector_base<unsigned int, std::allocator >::_Vector_impl’
{ std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
~~~~~~~~~~~~~ ^
.sl73_x8664_gcc485/include/StObject.h:183:4: note: in instantiation of member function ‘std::vector<unsigned int, std::allocator >::~vector’ requested here
StProxyUrr(TObject *coll){fArr = coll; fType=0;}
^
Error in TInterpreter::AutoParse: Error parsing payload code for class StStrangeMuDstMaker with content:

So it blames that stl_vector.h does not have member ‘_M_start’. I checked the all versions of stl_vector.h, and all of them have this member. But the mentioned above file:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/…/…/…/…/include/c++/4.8.5/bits/stl_vector.h
does not exist at all.
From where the cling got this non existing file?
Thank you,
Victor

Dear Victor,

Thanks for reporting this! It’s likely an issue we are aware of; @hahnjo is looking into this.

The header should indeed exist - at least on the build machine. There seems to be an extra . in the directories though; it should read /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_vector.h instead of .... That’s the regular /usr/include/c++/4.8.5/bits/stl_vector.h that’s part of your compilers’ install tree.

Cheers, Axel

Dear Axel,

directories though; it should read
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/…/…/…/…/include/c++/4.8.5/bits/stl_vector.h
instead of … That’s the regular /usr/include/c++/4.8.5/bits/stl_vector.h
that’s part of your compilers’ install tree.

Yes you right, the path /usr/include/c++/4.8.5/bits/ exists but there is no stl_vector.h
in this path. It looks like Cling is sure that this .h file MUST be there.
Cling some how is tied tightly to this path, but stl_vector.h is not in the system there.
How to convince Cling to use another version of stl_vector.h
There is a lot of different stl_vectors there:

/opt/gcc/4.8.2/include/c++/4.8.2/bits/stl_vector.h
/usr/include/c++/4.4.7/bits/stl_vector.h
/usr/include/c++/4.8.2/bits/stl_vector.h
Thank you,
Victor

Axel, I do not know how these “…” was created. Really there are “…” only.
Probably it is conversion from linux to Mac. So it is not this problem
Victor

Well, I see there is again three dots. No, there are only two dots there.
Victor

Dear Victor,

thanks for the report. Could you share the macro that is causing such problem? As Axel said, I have been investigating similar symptoms, but the problem I know about (and that is solved in master and for the next 6.26 release) concerns only a very specific set of conditions, including a templated member of a struct that is loaded via the IO layer. Also so far, it was only observed with GCC 10+, so knowing where we can hit this in GCC 4.8.5 would be really interesting.

Regarding the header files, I assume that you are on CentOS 7? In that case /usr/include/c++/4.8.5 should be linked to /usr/include/c++/4.8.2, so both the compiler and Cling should find the mentioned headers. If it doesn’t then either something is wrong with the system or there is a configuration that we are not correctly handling in Cling. Either case should be investigated, I think.

Regards
Jonas

Hi Victor,

In addition to the above recommendations, what is the newest gcc version that is available to you? gcc 4.8.5. is quite old now and will soonish no longer be supported by ROOT. It might be easier (and more fruitful) to start with a newer version of gcc.

Cheers,
Philippe.

Dear Jonas and Philippe,
sorry for the anxiety, it was a problem not with ROOT6 but with our system.
It was a problem that /usr/include/c++/bits/stl_vector.h was not existing.
Now it does exist, and error is absolutely different which I am investigating right now.
I did not modify anything and got a different result. I should ask our system programer
about it.
Thank you,
Victor

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.