Re: Re: Unresolved symbols in regex libs on tru64
Sam results with static linking. I'm not good with reading mangled names but it looks to me like they are there. Am I perhaps missing a link option?
I'm not familiar with the True64 linker so I can't say. What happens if you build the examples with bjam - do those all build OK?
John.
OK I think I found it -- using the ansi object model $cxx -c ... -model
ansi
I have always just accepted the default - arm. It was in the man page
for cxx and also in the documentation for the tru64cxx65 toolset. I
should read more carefully.
So it looks like all the code has to use ansi or arm, since I have a LOT
of stuff compiled in the arm mode, it would be better to build boost
using the "-sBUILD=<object-model>arm" switch, however now I'm back to
compile errors:
cxx: Error:
/adp/local/src/boost_1_32_0/libs/program_options/build/../src/convert.cp
p, line 62: #434
a reference of type "wchar_t *&" (not const-qualified) cannot
be
initialized with a value of type "wchar_t [32]"
detected during instantiation of "std::basic_string
Mark Helzer wrote: <snip>
So it looks like all the code has to use ansi or arm, since I have a LOT of stuff compiled in the arm mode, it would be better to build boost using the "-sBUILD=<object-model>arm" switch, however now I'm back to compile errors:
cxx: Error: /adp/local/src/boost_1_32_0/libs/program_options/build/../src/convert.cp p, line 62: #434 a reference of type "wchar_t *&" (not const-qualified) cannot be initialized with a value of type "wchar_t [32]" detected during instantiation of "std::basic_string
...
The problem here is that the name mangling scheme in the arm object model
is limited and cannot express the full scope of ISO C++. That's why we have
chosen to use the ansi object model as the default object model. A small
isolated sample that works around the problem is:
---%<---
#include <iostream>
using namespace std;
template <typename T> void foo(T const &x)
{
cout << "1" << endl;
}
template <typename T> void foo(T * const &x)
{
cout << "2" << endl;
}
int main()
{
#ifdef __MODEL_ARM
foo
OK I think I found it -- using the ansi object model $cxx -c ... -model ansi I have always just accepted the default - arm. It was in the man page for cxx and also in the documentation for the tru64cxx65 toolset. I should read more carefully.
Whew, I'm glad we sorted that one out.
So it looks like all the code has to use ansi or arm, since I have a LOT of stuff compiled in the arm mode, it would be better to build boost using the "-sBUILD=<object-model>arm" switch, however now I'm back to compile errors:
Looks like the program_options library won't be usable then (unless you can figure out a fix for us), what about the regex lib did that build OK? (Note that just because one Boost lib failed to build doesn't mean that you can't use the others). John.
participants (3)
-
John Maddock
-
Mark Helzer
-
Markus Schöpflin