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

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2006-02-08 09:26:50

Vladimir Prus wrote:

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

>> 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 vendor once was Digital, then Compaq, now it's HP. But the compiler 
still identifies Compaq as the vendor.

 > cxx -V
Compaq C++ V7.1-006 for Compaq Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V7.1-006 (cxx) cxx Driver

OTOH, uname still identifies the platform as OSF1, which was the name used 
by Digital. This is how I derived the name for the gcc toolset on this 
platform, as in gcc-4.0.2-osf1 for example.

So we could use cxx-tru64, or cxx-osf1 for the name. I wouldn't encode the 
version information in the toolset name, I always override it for running 
the regression tests, anyway.

The V1 toolset is called tru64cxx65 because it only works with V6.5 and 
later of the compiler. There also is tru64cxx which works with versions 
prior to V6.5, but I have no idea about it's state. So I would drop the 
version info from the toolset name.

> 
>> 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.

Good.

> 
>> 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"?

The problem here is that yes, -model ansi as the reasonable default and it 
has been used by boost for quite a while now. But the compiler defaults to 
-model arm, and whenever someone will want to use boost.build to build 
something other than boost, he very likely will have to use -model arm, 
because the binaries produced are not link compatible, and nearly every 
binary library on this platform uses -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?

AFAIK there are three flags which control this:

-call_shared
Produce a dynamic executable file that uses shareable objects during
run-time. This is the default. The loader uses shareable objects to
resolve undefined symbols. The run-time loader is invoked to bring in
all required shareable objects and to resolve any symbols that

-non_shared
Do not produce a dynamic executable file. The loader uses regular
archives to resolve undefined symbols and object files (.o suffix)
from archives that are included in the executable produced.

-shared
Produce a shared object. This includes creating all of the tables for
run-time linking, and resolving references to other specified shared
objects. The object created can be used by the linker to make dynamic
executables.

For static executables, you therefore need to add -non_shared to the 
command line and for dynamic libraries, -shared. I just checked the output 
of V1 for the command line used to produce a shared object file, and yes 
indeed, -shared appears on the command line. I'm wondering where this comes 
from.

>> 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.

Why is this bad? After all it's a different language, so you need a 
different tool, or don't you?

>> 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!

No problem, thanks for your work on Tru64 support. After all I'm to one 
with the interest in this platform... :-)

Markus