Re: [Boost-build] [V2] Testing Tru64 toolset

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-02-08 08:19:20

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