[wave] Recent check-ins broke wave on Tru64/CXX/RC_1_34_0
The compilation of wave actually succeeds, but linking libboost_wave-d-1_34.so.1.34.0 complains about multiply defined symbols. See http://tinyurl.com/ysqbex for further details. This has been broken recently (not more than 2 weeks ago) and I noticed that there are some check-ins related to wave in this time frame. Does that ring a bell with anyone? BTW, there are two references to 1.34 in the name of the generated library. Is that how it's supposed to be? Isn't the 1.34.0 suffix after .so somehow wrong? Markus
Markus Schöpflin wrote:
The compilation of wave actually succeeds, but linking libboost_wave-d-1_34.so.1.34.0 complains about multiply defined symbols. See http://tinyurl.com/ysqbex for further details.
This has been broken recently (not more than 2 weeks ago) and I noticed that there are some check-ins related to wave in this time frame.
Does that ring a bell with anyone?
It looks like the type of some symbol changed, but compiler sees both the old and the new symbol. Does CXX uses some template repository, or compile cache, or whatever? I don't have any ideas except for cleaning all .o files and caches related to wave.
BTW, there are two references to 1.34 in the name of the generated library. Is that how it's supposed to be? Isn't the 1.34.0 suffix after .so somehow wrong?
No, I think that's being there since forever. - Volodya
Hi, On 1/23/07, Vladimir Prus <ghost@cs.msu.su> wrote:
It looks like the type of some symbol changed, but compiler sees both the old and the new symbol. Does CXX uses some template repository, or compile cache, or whatever? I don't have any ideas except for cleaning all .o files and caches related to wave.
Yes, it has a repository - by default this is in the subdirectory "cxx_repository". Michael
Vladimir Prus wrote:
Markus Schöpflin wrote:
The compilation of wave actually succeeds, but linking libboost_wave-d-1_34.so.1.34.0 complains about multiply defined symbols. See http://tinyurl.com/ysqbex for further details.
This has been broken recently (not more than 2 weeks ago) and I noticed that there are some check-ins related to wave in this time frame.
Does that ring a bell with anyone?
It looks like the type of some symbol changed, but compiler sees both the old and the new symbol. Does CXX uses some template repository, or compile cache, or whatever? I don't have any ideas except for cleaning all .o files and caches related to wave.
The template repository is deactivated by a compiler command line switch. Also, there has been a non-incremental run over the weekend which also showed this error. The log files show: # Cleaning up "/vol2/boost/boost/bin" directory ... # Cleaning up "/vol2/boost/boost/bin.v2" directory ... # Cleaning up "/vol2/boost/results" directory ... # Updating sources from CVS (2007-01-20T01:14:27Z)... AFAICT, this deletes all possible leftovers.
BTW, there are two references to 1.34 in the name of the generated library. Is that how it's supposed to be? Isn't the 1.34.0 suffix after .so somehow wrong?
No, I think that's being there since forever.
OK, thank you. It just looked odd to me. Markus
Markus,
The compilation of wave actually succeeds, but linking libboost_wave-d-1_34.so.1.34.0 complains about multiply defined symbols. See http://tinyurl.com/ysqbex for further details.
This has been broken recently (not more than 2 weeks ago) and I noticed that there are some check-ins related to wave in this time frame.
Does that ring a bell with anyone?
BTW, there are two references to 1.34 in the name of the generated library. Is that how it's supposed to be? Isn't the 1.34.0 suffix after .so somehow wrong?
Is there a tool to unmangle the names? This could help me finding a clue what's wrong. Regards Hartmut
Hartmut Kaiser wrote:
Is there a tool to unmangle the names?
nm -mangled_name_also *.o | grep symbol_reported_as_multiply_defined Markus, the problem may go away if you compile -tlocal instead of -timplicit_local, but you, probably, would not want to change instantiation mode just for one library. Boris ----- Original Message ----- From: "Hartmut Kaiser" <hartmut.kaiser@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 23, 2007 8:55 AM Subject: Re: [boost] [wave] Recent check-ins broke wave onTru64/CXX/RC_1_34_0
Markus,
The compilation of wave actually succeeds, but linking libboost_wave-d-1_34.so.1.34.0 complains about multiply defined symbols. See http://tinyurl.com/ysqbex for further details.
This has been broken recently (not more than 2 weeks ago) and I noticed that there are some check-ins related to wave in this time frame.
Does that ring a bell with anyone?
BTW, there are two references to 1.34 in the name of the generated library. Is that how it's supposed to be? Isn't the 1.34.0 suffix after .so somehow wrong?
Is there a tool to unmangle the names? This could help me finding a clue what's wrong.
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
Hartmut Kaiser wrote:
Is there a tool to unmangle the names?
nm -mangled_name_also *.o | grep symbol_reported_as_multiply_defined
This doesn't give any output. "demangle" return just the mangled name. Is there some length limitation to nm or demangle? Or some sort of name compression scheme that those tools don't understand?
Markus, the problem may go away if you compile -tlocal instead of -timplicit_local, but you, probably, would not want to change instantiation mode just for one library.
Other parts of boost depend on the control given by -timplicit_local, I even have no idea if spirit would work with -tlocal. Hartmut, did you recently add some manually instantiated templates to wave? If yes, please have a look at the CXX workaround in 'boost/test/utils/trivial_singleton.hpp' to see if it helps in any way. Markus
Markus,
Boris Gubenko wrote:
Hartmut Kaiser wrote:
Is there a tool to unmangle the names?
nm -mangled_name_also *.o | grep symbol_reported_as_multiply_defined
This doesn't give any output. "demangle" return just the mangled name. Is there some length limitation to nm or demangle? Or some sort of name compression scheme that those tools don't understand?
Seems to work for gcc based compilers only.
Markus, the problem may go away if you compile -tlocal instead of -timplicit_local, but you, probably, would not want to change instantiation mode just for one library.
Other parts of boost depend on the control given by -timplicit_local, I even have no idea if spirit would work with -tlocal.
Hartmut, did you recently add some manually instantiated templates to wave?
No, I didn't add any template instantiations lately :-( The only change I made in the RC brancch was to fix a bug involving a really minor code change.
If yes, please have a look at the CXX workaround in 'boost/test/utils/trivial_singleton.hpp' to see if it helps in any way.
The CXX workaround seems to _add_ a template specialization, where in the case of wave we have a multiply defined symbol indicating to have too much template instantiations... I'm still clueless here ... Regards Hartmut
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Markus Schoepflin wrote:
Boris Gubenko wrote:
Hartmut Kaiser wrote:
Is there a tool to unmangle the names?
nm -mangled_name_also *.o | grep symbol_reported_as_multiply_defined
This doesn't give any output. "demangle" return just the mangled name. Is there some length limitation to nm or demangle? Or some sort of name compression scheme that those tools don't understand?
The names are indeed very long, but nm works for me on Tru64 V5.1 2650. On my Tru64 machine, the compiler runs out of memory when compiling some wave library modules, so I cannot reproduce the link failure. Did you run nm on the wave library object files (e.g. instantiate_defined_grammar.o) or on object files in the repository? The muldefs may come from the latter. After more thinking about it, it occurred to me, that by default, ld (prelink) actually reports original, non-mangled, source-code names.
From cxx manpage:
-nodemangle Causes linker messages to contain mangled names. By default, names are mangled in both Tru64 UNIX and Linux Alpha. So, the names in http://tinyurl.com/ysqbex should be original names and you, probably, don't need nm or demangle. The names do look strange: __CPR475__new_lexer__...lex_token<Z2Z> Boris ----- Original Message ----- From: "Markus Schöpflin" <markus.schoepflin@comsoft.de> To: <boost@lists.boost.org> Sent: Tuesday, January 23, 2007 10:03 AM Subject: Re: [boost] [wave] Recent check-ins broke wave onTru64/CXX/RC_1_34_0
Boris Gubenko wrote:
Hartmut Kaiser wrote:
Is there a tool to unmangle the names?
nm -mangled_name_also *.o | grep symbol_reported_as_multiply_defined
This doesn't give any output. "demangle" return just the mangled name. Is there some length limitation to nm or demangle? Or some sort of name compression scheme that those tools don't understand?
Markus, the problem may go away if you compile -tlocal instead of -timplicit_local, but you, probably, would not want to change instantiation mode just for one library.
Other parts of boost depend on the control given by -timplicit_local, I even have no idea if spirit would work with -tlocal.
Hartmut, did you recently add some manually instantiated templates to wave? If yes, please have a look at the CXX workaround in 'boost/test/utils/trivial_singleton.hpp' to see if it helps in any way.
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris,
After more thinking about it, it occurred to me, that by default, ld (prelink) actually reports original, non-mangled, source-code names.
From cxx manpage:
-nodemangle Causes linker messages to contain mangled names. By default, names are mangled in both Tru64 UNIX and Linux Alpha.
So, the names in http://tinyurl.com/ysqbex should be original names and you, probably, don't need nm or demangle. The names do look strange: __CPR475__new_lexer__...lex_token<Z2Z>
What do you mean by 'original names'? Names in the original C++ program? Regards Hartmut
Hartmut Kaiser wrote:
What do you mean by 'original names'? Names in the original C++ program?
Yes. Here's an example: cxxosf.zko.hp.com> cat > main.cpp void foo() {} int main() {} cxxosf.zko.hp.com> cat > foo.cpp void foo() {} cxxosf.zko.hp.com> cxx -c main.cpp foo.cpp main.cpp: foo.cpp: cxxosf.zko.hp.com> cxx -o main.out main.o foo.o ld (prelink): foo.o compressed: foo(void): multiply defined ld: foo.o compressed: foo(void): multiply defined cxxosf.zko.hp.com> cxx -o main.out main.o foo.o -nodemangle ld (prelink): foo.o compressed: foo__Xv: multiply defined ld: foo.o compressed: foo__Xv: multiply defined cxxosf.zko.hp.com> ----- Original Message ----- From: "Hartmut Kaiser" <hartmut.kaiser@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 23, 2007 2:03 PM Subject: Re: [boost] [wave] Recent check-ins broke wave onTru64/CXX/RC_1_34_0
Boris,
After more thinking about it, it occurred to me, that by default, ld (prelink) actually reports original, non-mangled, source-code names.
From cxx manpage:
-nodemangle Causes linker messages to contain mangled names. By default, names are mangled in both Tru64 UNIX and Linux Alpha.
So, the names in http://tinyurl.com/ysqbex should be original names and you, probably, don't need nm or demangle. The names do look strange: __CPR475__new_lexer__...lex_token<Z2Z>
What do you mean by 'original names'? Names in the original C++ program?
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris,
What do you mean by 'original names'? Names in the original C++ program?
Yes. Here's an example:
Ok. But in this case the names are not 'original'. They come from manual template instatiations. Regards Hartmut
Hartmut Kaiser wrote:
Ok. But in this case the names are not 'original'. They come from manual template instatiations.
Perhaps, 'original' is not the best term here, but I don't know what the best term would be. Source code names? Below is an example of "source code name" and its corresponding mangled name, as reported by 'nm -mangled_name_also'. In <http://tinyurl.com/yvvcy4>, the linker shows "source code names" as multiply defined, as opposite to mangled names.
From instantiate_re2c_lexer_str.o:
__CPR475__new_lexer__Q4_5boost4wave8cpplexer292new_lexer_gen__tm__270_ PcQJ12JostJ20J4util245file_position__tm__223_QJ12JostJ20JJ76J200flex_string_ _tm__180_cQ2_3std20char_traits__tm__2_cQ2_3std18allocator__tm__2_cQJ12JostJ2 0JJ76J100CowString__tm__83_QJ12JostJ20JJ76J59AllocatorStringStorage__tm__29_ cQ2_3stdJ187JPcSFRCZ1ZT1RCZ2ZQ3_J14JJ20J16language_support_PQJ12JostJ20JJ25J 73lex_input_interface__tm__46_QJ12JostJ20JJ25J20lex_token<Z2Z> __7__CPR475__new_lexer__Q4_5boost4wave8cpplexer292new_lexer_gen__tm__270_ PcQJ12JostJ20J4util245file_position__tm__223_QJ12JostJ20JJ76J200flex_string_ _tm__180_cQ2_3std20char_traits__tm__2_cQ2_3std18allocator__tm__2_cQJ12JostJ 20JJ76J100CowString__tm__83_QJ12JostJ20JJ76J59AllocatorStringStorage__tm__29_c Q2_3stdJ187JPcSFRCZ1ZT1RCZ2ZQ3_J14JJ20J16language_support_PQJ12JostJ20JJ25J73lex _input_interface__tm__46_QJ12JostJ20JJ25J20lex_token__tm__4_Z2Z Thanks, Boris ----- Original Message ----- From: "Hartmut Kaiser" <hartmut.kaiser@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 23, 2007 4:05 PM Subject: Re: [boost] [wave] Recent check-ins broke wave onTru64/CXX/RC_1_34_0
Boris,
What do you mean by 'original names'? Names in the original C++ program?
Yes. Here's an example:
Ok. But in this case the names are not 'original'. They come from manual template instatiations.
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hartmut Kaiser wrote:
Ok. But in this case the names are not 'original'. They come from manual template instatiations.
I, obviously, don't know all the details, but it seems to me that the problem has to do with manual instantiations in instantiate_re2c_lexer.cpp and instantiate_re2c_lexer_str.cpp modules: instantiate_re2c_lexer.cpp: --------------------------- template struct boost::wave::cpplexer::new_lexer_gen< BOOST_WAVE_STRINGTYPE::iterator>; template struct boost::wave::cpplexer::new_lexer_gen< BOOST_WAVE_STRINGTYPE::const_iterator>; instantiate_re2c_lexer_str.cpp: ------------------------------- template struct boost::wave::cpplexer::new_lexer_gen<std::string::iterator>; template struct boost::wave::cpplexer::new_lexer_gen<std::string::const_iterator>; Assuming that BOOST_WAVE_STRINGTYPE evaluates to std::string, it results in two identical instantiations. It is OK on a platform supporting comdats, but Tru64 (and AlphaVMS for that matter) can deal with it only in local template instantiation mode. Follows an example. Thanks, Boris main.cpp -------- #include <string> #include <vector> int main() {} template class std::vector<std::string>; foo.cpp ------- #include <string> #include <vector> template class std::vector<std::string>; bash-2.03$ aCC -V aCC: HP aC++/ANSI C B3910B A.06.10 [Mar 22 2006] bash-2.03$ aCC main.cpp foo.cpp main.cpp: foo.cpp: bash-2.03$ bash-2.04$ cxx -V Compaq C++ V7.1-006 for Compaq Tru64 UNIX V5.1B (Rev. 2650) Compiler Driver V7.1-006 (cxx) cxx Driver bash-2.04$ cxx main.cpp foo.cpp main.cpp: foo.cpp: ld (prelink): foo.o compressed: std::vector<std::basic_string<char, ... multiply defined ... bash-2.04$ cxx -tlocal main.cpp foo.cpp main.cpp: foo.cpp: bash-2.04$ ----- Original Message ----- From: "Hartmut Kaiser" <hartmut.kaiser@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 23, 2007 4:05 PM Subject: Re: [boost] [wave] Recent check-ins broke wave onTru64/CXX/RC_1_34_0
Boris,
What do you mean by 'original names'? Names in the original C++ program?
Yes. Here's an example:
Ok. But in this case the names are not 'original'. They come from manual template instatiations.
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris,
Hartmut Kaiser wrote:
Ok. But in this case the names are not 'original'. They come from manual template instatiations.
I, obviously, don't know all the details, but it seems to me that the problem has to do with manual instantiations in instantiate_re2c_lexer.cpp and instantiate_re2c_lexer_str.cpp modules:
instantiate_re2c_lexer.cpp: --------------------------- template struct boost::wave::cpplexer::new_lexer_gen< BOOST_WAVE_STRINGTYPE::iterator>; template struct boost::wave::cpplexer::new_lexer_gen< BOOST_WAVE_STRINGTYPE::const_iterator>;
instantiate_re2c_lexer_str.cpp: ------------------------------- template struct boost::wave::cpplexer::new_lexer_gen<std::string::iterator>; template struct boost::wave::cpplexer::new_lexer_gen<std::string::const_iterator>;
Assuming that BOOST_WAVE_STRINGTYPE evaluates to std::string, it results in two identical instantiations. It is OK on a platform supporting comdats, but Tru64 (and AlphaVMS for that matter) can deal with it only in local template instantiation mode. Follows an example.
Thanks for looking into this. I initially had the same idea. But unfortunately your assumption is not correct, as BOOST_WAVE_STRINGTYPE normally is defined as some flex_string<...> type (see the mangled names refer to flex_string as well). I will add some safe guards to avoid this situation, though. Still not sure, what's going on here. I'm pretty sure I have not even touched these template instantiations for years. Regards Hartmut
Hartmut Kaiser wrote:
[...] I initially had the same idea. But unfortunately your assumption is not correct, as BOOST_WAVE_STRINGTYPE normally is defined as some flex_string<...> type (see the mangled names refer to flex_string as well).
You are right, of course. I've compiled instantiate_re2c_lexer.cpp with -source_listing and confirmed that BOOST_WAVE_STRINGTYPE is defined as flex_string (and that flex_string is not defined as std::string). The templates in two modules are instantiated on std::string::iterator and flex_string::iterator, respectively, and it seems to me, that the problem has something to do with fact, that underlying type for both std::string::iterator and flex_string::iterator is 'char*'. The problem is reproducible with: template struct boost::wave::cpplexer::new_lexer_gen<char*>; template struct boost::wave::cpplexer::new_lexer_gen<const char*>; instead of: template struct boost::wave::cpplexer::new_lexer_gen<std::string::iterator>; template struct boost::wave::cpplexer::new_lexer_gen<std::string::const_iterator>; but goes away with, for example, 'unsigned char*' instead of 'char*'.
I will add some safe guards to avoid this situation, though.
I don't know if this is a problem on both Tru64 and AlphaVMS, (the latter has the same compiler and STL that Tru64 and is also a non-comdat platform), but if you're planning to conditionalize the code to "avoid this situation", the condition that would work on both Tru64 and AlphaVMS is: #if defined(__DECCXX) && defined(__alpha)
Still not sure, what's going on here. I'm pretty sure I have not even touched these template instantiations for years.
This, of course, is the most interesting question: how it used to work and what change has triggered this problem. Thanks, Boris ----- Original Message ----- From: "Hartmut Kaiser" <hartmut.kaiser@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, January 24, 2007 10:30 AM Subject: Re: [boost] [wave] Recent check-ins broke wave onTru64/CXX/RC_1_34_0
Boris,
Hartmut Kaiser wrote:
Ok. But in this case the names are not 'original'. They come from manual template instatiations.
I, obviously, don't know all the details, but it seems to me that the problem has to do with manual instantiations in instantiate_re2c_lexer.cpp and instantiate_re2c_lexer_str.cpp modules:
instantiate_re2c_lexer.cpp: --------------------------- template struct boost::wave::cpplexer::new_lexer_gen< BOOST_WAVE_STRINGTYPE::iterator>; template struct boost::wave::cpplexer::new_lexer_gen< BOOST_WAVE_STRINGTYPE::const_iterator>;
instantiate_re2c_lexer_str.cpp: ------------------------------- template struct boost::wave::cpplexer::new_lexer_gen<std::string::iterator>; template struct boost::wave::cpplexer::new_lexer_gen<std::string::const_iterator>;
Assuming that BOOST_WAVE_STRINGTYPE evaluates to std::string, it results in two identical instantiations. It is OK on a platform supporting comdats, but Tru64 (and AlphaVMS for that matter) can deal with it only in local template instantiation mode. Follows an example.
Thanks for looking into this. I initially had the same idea. But unfortunately your assumption is not correct, as BOOST_WAVE_STRINGTYPE normally is defined as some flex_string<...> type (see the mangled names refer to flex_string as well). I will add some safe guards to avoid this situation, though.
Still not sure, what's going on here. I'm pretty sure I have not even touched these template instantiations for years. Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Markus Schoepflin wrote:
Boris Gubenko wrote:
Markus, the problem may go away if you compile -tlocal instead of -timplicit_local, but you, probably, would not want to change instantiation mode just for one library.
Other parts of boost depend on the control given by -timplicit_local,
I understand. I'm not suggesting tweaking template instantiation mode just for this issue.
I even have no idea if spirit would work with -tlocal.
I'm not sure why you mention spirit in this context, but it works, at least the tests pass with -tlocal (I've replaced -timplicit_local with -tlocal in hp_cxx.jam): bash-2.04$ export X="boost/bin.v2/libs/spirit/test/" bash-2.04$ find $X -name "*.test" -type f | wc -l 124 bash-2.04$ find $X -name "*.test" -type f -exec cat {} \; | sort -u passed bash-2.04$ There are, actually, 128 tests in the spirit library 4 of which are expected failures (I *think*). Thanks, Boris ----- Original Message ----- From: "Markus Schöpflin" <markus.schoepflin@comsoft.de> To: <boost@lists.boost.org> Sent: Tuesday, January 23, 2007 10:03 AM Subject: Re: [boost] [wave] Recent check-ins broke wave onTru64/CXX/RC_1_34_0
Boris Gubenko wrote:
Hartmut Kaiser wrote:
Is there a tool to unmangle the names?
nm -mangled_name_also *.o | grep symbol_reported_as_multiply_defined
This doesn't give any output. "demangle" return just the mangled name. Is there some length limitation to nm or demangle? Or some sort of name compression scheme that those tools don't understand?
Markus, the problem may go away if you compile -tlocal instead of -timplicit_local, but you, probably, would not want to change instantiation mode just for one library.
Other parts of boost depend on the control given by -timplicit_local, I even have no idea if spirit would work with -tlocal.
Hartmut, did you recently add some manually instantiated templates to wave? If yes, please have a look at the CXX workaround in 'boost/test/utils/trivial_singleton.hpp' to see if it helps in any way.
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
Markus Schoepflin wrote:
Boris Gubenko wrote:
Markus, the problem may go away if you compile -tlocal instead of -timplicit_local, but you, probably, would not want to change instantiation mode just for one library. Other parts of boost depend on the control given by -timplicit_local,
I understand. I'm not suggesting tweaking template instantiation mode just for this issue.
I even have no idea if spirit would work with -tlocal.
I'm not sure why you mention spirit in this context, but it works, at least the tests pass with -tlocal (I've replaced -timplicit_local with -tlocal in hp_cxx.jam):
Wave is built upon spirit, if my memory serves me right. Markus
Markus Schoepflin wrote:
Boris Gubenko wrote:
I'm not sure why you mention spirit in this context, but it works, at least the tests pass with -tlocal (I've replaced -timplicit_local with -tlocal in hp_cxx.jam):
Wave is built upon spirit, if my memory serves me right.
Ok, thanks for the clarification, Markus. Boris ----- Original Message ----- From: "Markus Schöpflin" <markus.schoepflin@comsoft.de> To: <boost@lists.boost.org> Sent: Wednesday, January 24, 2007 8:52 AM Subject: Re: [boost] [wave] Recent check-ins broke wave onTru64/CXX/RC_1_34_0
Boris Gubenko wrote:
Markus Schoepflin wrote:
Boris Gubenko wrote:
Markus, the problem may go away if you compile -tlocal instead of -timplicit_local, but you, probably, would not want to change instantiation mode just for one library. Other parts of boost depend on the control given by -timplicit_local,
I understand. I'm not suggesting tweaking template instantiation mode just for this issue.
I even have no idea if spirit would work with -tlocal.
I'm not sure why you mention spirit in this context, but it works, at least the tests pass with -tlocal (I've replaced -timplicit_local with -tlocal in hp_cxx.jam):
Wave is built upon spirit, if my memory serves me right.
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Marcus,
The compilation of wave actually succeeds, but linking libboost_wave-d-1_34.so.1.34.0 complains about multiply defined symbols. See http://tinyurl.com/ysqbex for further details.
This has been broken recently (not more than 2 weeks ago) and I noticed that there are some check-ins related to wave in this time frame.
Does that ring a bell with anyone?
BTW, there are two references to 1.34 in the name of the generated library. Is that how it's supposed to be? Isn't the 1.34.0 suffix after .so somehow wrong?
Based on Boris' analysis I disabled the usage of the flex_string class for the True64 platform. Could you please trigger a rebuilt for me to see if that did help? Regards Hartmut
Hartmut Kaiser wrote:
Based on Boris' analysis I disabled the usage of the flex_string class for the True64 platform. Could you please trigger a rebuilt for me to see if that did help?
The regression tests are running 24/7, so your changes should be picked up and tested automatically within a few days at most... That said, I just noticed that I forgot to reenable them after the last config changes. :-( Well, I restarted the system now, the results should show up in 24 hours latest. Markus
participants (5)
-
Boris Gubenko -
Hartmut Kaiser -
Markus Schöpflin -
Michael van der Westhuizen -
Vladimir Prus