Re: [jamboost] Re: stage rule on windows problem

From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2004-11-30 11:00:06

Hi Volodya,

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?

TIA,

Pedro

----- Original Message ----- 
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <jamboost_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:
>>
>> http://sourceforge.net/mailarchive/forum.php?thread_id=2793609&forum_id=340
>>93
>>
>> 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 
> special
> processing for gcc toolset, when a specific property <global-segment> is
> specified?
>
> Could you take a look at the attached code? If defined two shared 
> libraries:
>
> 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 
> and
> then relays to gcc.link.dll.
>
> Is this sufficient? Anything else I can help with?
>
> - Volodya
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>