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

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2006-02-09 07:01:17

Vladimir Prus wrote:

> On Wednesday 08 February 2006 17:26, Markus Schöpflin wrote:

>> 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.
> 
> Well, I'm really confused what name is best ;-) Maybe, "hp-tru64", at least so 
> that name is associated with the current vendor?

I just had a look at HP's web page, see 
http://h30097.www3.hp.com/cplus/?jumpid=reg_R1002_USEN. They call it "HP 
C++ Version 7.1 for Tru64 UNIX".

So maybe hp-tru64 is a good choice, considering the name of the other toolsets.

>> 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.
> 
> In V2, compiler version never goes into file name, because one file can handle
> several versions. So, yes, no need for version number.

That's good.

>>>> 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.
> 
> What about renaming the feature, for V2, to "c++-abi". And one of the values 
> would be "cxx-arm", or something? I think that <object-model>arm is not 
> specific enough -- my first though that it selects object file format for the 
> ARM processor ;-) 

This makes sense. We would need cxx-arm, and cxx-ansi then, and the boost 
default should be cxx-ansi.

>>> 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.
> 
> Me too. Anyway, I've added -shared to link.dll action.

Good, I tested the second example and it works now. As soon as we have the 
object-model back, I'll do a simple regression run.

 > Do you know if V1
> toolset ever uses "-non_shared" for executables -- it seems like no.

I don't think so, but there is a comment in the V1 toolset file that 
indicates that there is no static linking on Tru64 available. This of 
course is not true. When the rest works OK, I'll see if I can add static 
linking to the toolset.

>>>> 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?
> 
> It's bad because I need extra work. Anyway, it's done too, and comitted.

Great, thanks.

Markus