Testing Tru64 toolset

On Wednesday 08 February 2006 15:43, Markus Schöpflin wrote:

> > Overall, it should take no more that 5 mins to
either work though all
> > steps and verify that toolset works, or run into
an error.
>
> I just had a look at the new toolset. First a thing
about it's name. The
> compiler is named cxx, the platform is Tru64, so
shouldn't the toolset be
> named cxx-tru64 or tru64-cxx or something similar?

If "Tru64" is the platform, then yes, it's not a
good name for toolset. But 
"cxx" is too generic. What's the vender? What's in
the version string for 
"cxx"?

> The simple example seems to work:
>  > bjam -a -d+2 tru64
>
> tru64.compile.c++ bin/tru64/debug/hello.o
>
>      cxx  -c -std strict_ansi -nopure_cname
-noimplicit_include
> -timplicit_local -ptr
"bin/tru64/debug/cxx_repository"
-msg_display_number
> -msg_disable 186,450,1115 -D__CNAME_OVERLOADS -g3 -O0
-inline none   -o
> "bin/tru64/debug/hello.o"
"hello.cpp"
>
> But I'm missing -gall, 

There was a typo, I've fixed it.

> and -model ansi on the compiler command line. 
> Looking at the jam file, the model feature has been
disabled explicitly.
> Here is an excerpt from the compiler man page about
this feature:
>
> <quote>
> -model [ansi | arm]
> [Tru64] Determines the layout of C++ classes, name
mangling, and
> exception handling.  On Tru64 UNIX, the default is
-model arm; on
> Linux Alpha, the default is -model ansi. The -model arm
option is not
> supported on Linux Alpha.
>
> The -model arm option is the default and generates
objects that are
> link compatible with all HP C++ releases prior to
Version 6.3, and
> with all objects compiled using the -model arm option
in HP C++ Ver-
> sion 6.3 or later. Specifying this option defines the
macro
> __MODEL_ARM.
>
> The -model ansi option supports the complete ISO/ANSI
C++ specifica-
> tion, including distinct name mangling for templates. 
The ANSI model
> also reduces the size of C++ non-POD class objects. 
Note that this
> option generates objects that are not compatible with
prior releases
> of HP C++, or with objects compiled using the -model
arm option.
>
> If you specify the -model ansi option, you must
recompile your entire
> application, including libraries.  Specifying this
option defines the
> macro __MODEL_ANSI.
> </quote>

So, "the -model ansi" is the reasonable default?
Is it ever needed to use 
"-model arm"?

>
> tru64.link bin/tru64/debug/hello
>
>      cxx -noimplicit_include -g -o
"bin/tru64/debug/hello"
> "bin/tru64/debug/hello.o"    -lrt -lm
>
> Here the model flag is missing as well.

Noted.

> The next example fails:
>  > bjam -a -d+2 tru64
>
> tru64.compile.c++ app/bin/tru64/debug/app.o
>
>      cxx  -c -std strict_ansi -nopure_cname
-noimplicit_include
> -timplicit_local -ptr
"app/bin/tru64/debug/cxx_repository"
> -msg_display_number -msg_disable 186,450,1115
-D__CNAME_OVERLOADS -g3 -O0
> -inline none  -I"util/foo/include" -o
"app/bin/tru64/debug/app.o"
> "app/app.cpp"
>
> tru64.compile.c++ util/foo/bin/tru64/debug/bar.o
>
>      cxx  -c -std strict_ansi -nopure_cname
-noimplicit_include
> -timplicit_local -ptr
"util/foo/bin/tru64/debug/cxx_repository"
> -msg_display_number -msg_disable 186,450,1115
-D__CNAME_OVERLOADS -g3 -O0
> -inline none   -o
"util/foo/bin/tru64/debug/bar.o"
"util/foo/bar.cpp"
>
> cxx: Warning: util/foo/bar.cpp, line 13: #381-D extra
";" ignored
> void foo() {};
> -------------^
> tru64.link.dll util/foo/bin/tru64/debug/libbar.so
>
>      cxx  -qrtti  -noimplicit_include -g -o
> "util/foo/bin/tru64/debug/libbar.so"  
"util/foo/bin/tru64/debug/bar.o"   
> -lm
>
> ld (prelink):
> -qrtti: Unknown flag
> ld: Usage: ld [options] file [...]
> ld:
> -qrtti: Unknown flag
> ld: Usage: ld [options] file [...]
> ...skipped <papp/bin/tru64/debug>app for lack of
> <putil/foo/bin/tru64/debug>libbar.so...
> ...failed updating 1 target...
>
> I have no idea where the -qrtti flag comes from in the
original V1 toolset,
> but it seems that the corresponding rule is never used
because building
> shared libs works on Tru64 in V1. So using the regular
link rule should
> instead should work, I guess.

Does the linker auto-detect that shared library is being
built by extension, 
and without any special flag like "-shared" that's
needed with gcc?

> About the C compiler, I don't think there are any flags
that will help you
> here. You have to invoke cc and not cxx, as is the case
in the V1 toolset.

It's bad, but I'll work this around.

> I don't have time for more right now, but I will try to
address the other
> FIXME comments in the toolset file this week.

Thanks for your help!

- Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Testing Tru64 toolset

Thread: Testing Tru64 toolset