From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2004-11-30 11:00:06
I tried out the example you sent and modified it for msvc:
feature.feature mog-linking-generator : on off ;
class mog-linking-generator : linking-generator
rule __init__ ( id composing ? : source-types + : target-types + :
requirements * )
linking-generator.__init__ $(id) $(composing) : $(source-types) :
$(target-types) : $(requirements) ;
generators.register [ new mog-linking-generator mog.msvc.link.dll : OBJ
SEARCHED_LIB STATIC_LIB IMPORT_LIB : SHARED_LIB IMPORT_LIB RSP :
<toolset>msvc <mog-linking-generator> ] ;
generators.override mog.msvc.link.dll : msvc.link.dll ;
toolset.inherit-flags mog : msvc ;
IMPORT msvc : link.dll : mog : msvc.link.dll : LOCALIZE ;
rule mog.msvc.link.dll ( targets * : sources * : properties * )
import common ;
msvc.link.dll $(targets) : $(sources) : $(properties) ;
However, when the 'msvc.link.dll' rule eventually gets called, $(.LD)
expands to an empty string.
Am I doing something wrong in the imports?
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
Sent: Tuesday, November 30, 2004 8:05 AM
Subject: Re: [jamboost] Re: stage rule on windows problem
> On Monday 29 November 2004 20:18, Rene Rivera wrote:
>> Vladimir Prus wrote:
>> > On Thursday 25 November 2004 02:27, Rene Rivera wrote:
>> >>...More specifically I mark almost everything as private in the ELF
>> >>objects and relink to get all those private symbols removed. I don't do
>> >>that in the debug so I can do symbolic debugging :-) And the regular
>> >>link tools, as you mention only strip the static symbols.
>> > Just curious, are you using the "version script" that the linker can
>> > use?
>> > I've used it in past for some special tricks, but exporting C++ symbols
>> > was pretty hard due to mangling.
>> No linker script, those things are nasty. It's very similar to what gcc
>> 3.4 currently allows for. I mark the symbols I want to keep with
>> "__attribute__ ((section (".text.dll")))" in the code. Then use the list
>> of symbols in that code section to build the list of mangled C++ names
>> plus vtables and other related items with the binutils "objdump"
>> program. And I can further use the "objcopy" program to remove the
>> non-public symbols. I posted a rather long and dense description, with
>> part of the BBv1 script for doing it at:
>> Although I've cleaned up the script somewhat since then. This bit of
>> custom build magic is why I haven't switched to BBv2. If you can show me
>> how to add such custom link steps to an existing toolset I could then
>> package this up and add to BBv2.
> Looking at the post you've mentioned, it looks like you need to invoke
> processing for gcc toolset, when a specific property <global-segment> is
> Could you take a look at the attached code? If defined two shared
> lib a : a.cpp ;
> lib b : b.cpp : <globals-segment>text ;
> The first is build with regular gcc toolset and the second is linked with
> gcc-custom-link.link.dll rule. In my example, it just prints some message
> then relays to gcc.link.dll.
> Is this sufficient? Anything else I can help with?
> - Volodya
> Yahoo! Groups Links
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