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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-02-09 05:29:49

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?

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

> >> 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 ;-) 

> > 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. Do you know if V1 
toolset ever uses "-non_shared" for executables -- it seems like no.

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

- Volodya