Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-02-21 03:29:56


On Thursday 16 February 2006 21:09, Brad Howes wrote:
> With a CVS snapshot of boost.build, I am unable to use the <file> tag
> for a lib target. Here's the target declaration:
>
> lib ACE : : <file>ACE_Wrappers/lib/libACE.dylib ;
>
> When I run bjam, this is what I get:
>
> Error: ambiguity found when searching for best transformation
> Trying to produce type 'LIB' from:
> - builtin.prebuilt
> - darwin.prebuilt
> First generator produced:
> - { ACE_Wrappers/lib/libACE.dylib.SHARED_LIB }
> Second generator produced:
> - { ACE_Wrappers/lib/libACE.dylib.SHARED_LIB }
>
> Mucking thru darwin.jam, gcc.jam, unix.jam, and generators.jam, I
> think the problem is that the generators.override calls in darwin.jam
> are not correct (and perhaps gcc.jam as well). Currently, darwin.jam
> has:
>
> generators.override builtin.lib-generator : darwin.prebuilt ;
> generators.override darwin.searched-lib-generator : searched-lib-
> generator ;
>
> If I change these to *just* this one line:
>
> generators.override darwin.prebuilt : builtin.lib-generator ;
>
> then all works just fine.

Hi Brad,
I've just comitted a modified version of darwin.jam that reads:

   generators.override darwin.prebuilt : builtin.prebuilt ;
   generators.override darwin.searched-lib-generator :
        searched-lib-generator ;

Can you check that it works for you? If anon CVS does not yet have this
change, you can always get nightly build from
http://boost.org/boost-build2/boost-build.zip (it already includes those
changes).

> Also, it appears that the link action in
> darwin.jam is invoked instead of link.dll for shared libraries, at
> least for release builds. The linker fails because the -s option
> removes relocation information (I think). The gcc.jam file has a hack
> when running on darwin which puts the '-s' flag into ST_OPTIONS,
> presumably for static linking, and the link.dll action in darwin.jam
> indeed does not use this flag. However, link.dll is not invoked for
> shared libraries - the link action is and it does use ST_OPTIONS.

This is pretty strange. Can you try with "example/libraries", and see if
link.dll or link action is used for libraries? In my testing, link.dll is
correctly used.

Could it be that you get error when linking the executable, not the library?

- Volodya


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk