Re: [Boost-build] vacpp.jam

Subject: Re: [Boost-build] vacpp.jam
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-03-16 06:57:39

On Monday 16 March 2009 13:36:48 Jim Hague wrote:
> Vladimir Prus <ghost <at> cs.msu.su> writes:
> > > diff -r 5b628f6ec088 boost-build/tools/vacpp.jam
> > > --- a/boost-build/tools/vacpp.jam       Fri Mar 13 16:42:46 2009 +0000
> > > +++ b/boost-build/tools/vacpp.jam       Fri Mar 13 17:30:22 2009 +0000
> > > @@ -16,7 +16,8 @@
> > >
> > >  feature.extend toolset : vacpp ;
> > >  toolset.inherit vacpp : unix ;
> > > -generators.override vacpp.prebuilt : builtin.lib-generator ;
> > > +generators.override vacpp.prebuilt : builtin.prebuilt ;
> > >  generators.override vacpp.searched-lib-generator :
> > > searched-lib-generator ;
> >
> > This is the right fix. I've checked it in in SVN.
>
> So, I made a good guess. Thanks.
>
> > > The offender is the '-qtwolink' link option. The docs at
> > > http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic
> > >=/co m.ibm.vacpp7a.doc/compiler/ref/ruopttwo.htm describe this option
> > > [...]
> > >
> > > I suggest that this should only be applied by vacpp.jam as an option; I
> > > think it too aggressive for a universal link option.
> >
> > I must admit I don't understand neither the problem your had, nor the
> > linker option. But if you say this option breaks builds, then so it does
> > I've removed it, in SVN HEAD. Can you update and see if things are
> > better?
>
> Sorry, I edited the included text very badly. -qtwolink attempts to
> minimize the number of C++ static constructors included in the final
> executable by omitting them if the object is question does not appear to be
> referenced. The linked page above has a simple example. The page notes
> explicitly
> 'Before using -qtwolink, make sure that any .o files placed in an archive
> do not change the behavior of the program.' In other words, putting a .o
> into an archive and using this option CAN change the behaviour of the
> program. As I see it, having '-qtwolink' cannot be a universally applied
> option for this reason.

Jim,

Thanks for the explanation!

> In my case, the (third-party, binary only) library contains components that
> (I guess) use the static constructor to link themselves into a pool of
> available components. -qtwolink causes the program to fail, as some
> components are suddely not available. Note as well that on AIX shared
> libraries are more akin to Windows DLLs than Unix shared objects, so the
> option may (I am not clear) be doing stuff when creating a shared library.
>
> I checked your change. It removed the first -qtwolink, but a second
> -qtwolink remains in the EXE-LINKFLAGS; it needs to go too for my program
> to work.

Doh. This is now fixed, too.

- Volodya