Re: [Boost-build] [Boost][build] Bjam ordering source $(>) list

Subject: Re: [Boost-build] [Boost][build] Bjam ordering source $(>) list
From: K. Noel Belcourt (kbelco_at_[hidden])
Date: 2009-06-25 19:13:26

Hi Steven,

On Jun 25, 2009, at 4:49 PM, Steven Watanabe wrote:

> K. Noel Belcourt wrote:
>> In jam/src/make1.c, make1list(), I find this comment
>>
>> * make1list() - turn a list of targets into a LIST, for $(<) and $ 
>> (>).
>>
>> which seems like the place where I could ensure that sources for, say
>> a link action $(>) are ordered so that objects occur before archives
>> or shared libraries.  Some background.
>>
>> We're bringing up support for linking Fortran programs and have
>> discovered that when linking C programs, the objects in $(>) always
>> precede the libraries, which is good since the main is often in an
>> object file.  This is an issue if, for example, your linker doesn't
>> support start / end group and the library precedes the object
>> containing main (you get linker errors).
>
> I'm not quite sure that I follow.  Libraries ought to be in a separate
> variable from sources.

Ignore for a second that start group / end group is available to us.   
Consider this gcc link action from gcc.jam:

actions link bind LIBRARIES
{
     "$(CONFIG_COMMAND)" -L"$(LINKPATH)" -Wl,$(RPATH_OPTION:E=-R)$ 
(SPACE)-Wl,"$(RPATH)" -Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)" -o "$ 
(<)" $(START-GROUP) "$(>)" "$(LIBRARIES)" $(FINDLIBS-ST-PFX) -l$ 
(FINDLIBS-ST) $(FINDLIBS-SA-PFX) -l$(FINDLIBS-SA) $(END-GROUP) $ 
(OPTIONS) $(USER_OPTIONS)
}

with an C executable target like this:

exe Utst_element
   :
     $(framework-root)/src/utest/Utst_element.C
     apub
     elem
     elements
     fmwk
     parser
     /sierra/user_subroutines//usersublib
     /sierra/utility//utility
   : <tag>@runtest-tag
   ;

the expanded sources passed into this $(>) link action variable is  
this (severely truncated):

Utst_element.o libparser.a libelem.a libutility.a libfmwk.a  
libelements.a libusersublib.a libapub.a libsolver-control.a libmath.a  
libgeometry.a libcholla.a libgeom.a libcubit.a libfrio.a  
libtransfer.a libacme.a libmmod.a libsearch.a libelemint.a libewed.a  
libetet.a libetri.a libehex.a libequa.a libepub.a libebar.a libepyr.a  
librbal.a libzoltan.a libparmetis.a libmetis.a libzoltan_dd.a  
libzoltan_comm.a libzoltan_mem.a libfmwk.a libioinit.a libiotr.a  
libiohb.a libioex.a libnemesis.a libexodus.a libnetcdf.a libioel.a  
libparser.a libxml.a libfrii.a libioss.a libelem.a  
libgeometry_toolkit.a libshards.a libutility.a

with the object always preceding the libraries.  Note that all this  
is in the $(>) link action variable.

>> In our case, it seems that our objects always precede any libraries
>> when linking with C, but when linking with Fortran, we find the
>> libraries precede the objects and, hence, we get linker errors.
>>
>> Back to make1list().  It seems like this is the place where the list
>> of sources and targets for an action are turned into a list for $(<)
>> and $(>).  Does anyone know (1) if bjam intentionally sorts objects
>> before libraries for $(>) and, if it does as it seems to, (2)  
>> where is
>> to code in bjam that does this?
>
> The order of the targets ought to be controlled by Boost.Build in
> gcc.link for example.

I'm sure there's more going on than I know, but it seems to me that  
any sources in the exe rule are expanded (as above) by including the  
sources in those dependencies.

These are the sources from the exe rule above.

     $(framework-root)/src/utest/Utst_element.C
     apub
     elem
     elements
     fmwk
     parser
     /sierra/user_subroutines//usersublib
     /sierra/utility//utility

All these sources (and the sources in these dependencies) get lumped  
into the $(>) variable that is passed into the link action.

I guess what I'm wondering is why are all the exe (and dependent)  
sources (object and libraries) lumped into $(>)?  Perhaps the follow- 
on question is: given that the objects and libraries in the exe rule  
sources are all in $(>), can we apply a stable sort to $(>) so that  
the objects precede the libraries while retaining the original  
relative ordering.  This will help us on systems where we don't have  
a multi-pass linker nor options like start / end group.

Does that make any sense?

-- Noel