On 2010/6/7 Andre Espaze wrote:
> On Mon, Jun 07, 2010 at 06:06:58PM +0200, Denis Barbier wrote:
>> On 2010/6/7 Andre Espaze wrote:
>> [...]
>> > $ patch -p1 < no-template-function-inline.patch
>> > $ patch -p1 < debian/patches/visu-no-template-inline.patch
>>
>> Thanks André for these detail
On Mon, Jun 07, 2010 at 06:06:58PM +0200, Denis Barbier wrote:
> On 2010/6/7 Andre Espaze wrote:
> [...]
> > $ patch -p1 < no-template-function-inline.patch
> > $ patch -p1 < debian/patches/visu-no-template-inline.patch
>
> Thanks André for these detailed explanations, but why do you apply
>
On 2010/6/7 Andre Espaze wrote:
[...]
> $ patch -p1 < no-template-function-inline.patch
> $ patch -p1 < debian/patches/visu-no-template-inline.patch
Thanks André for these detailed explanations, but why do you apply
both patches? I thought that visu-no-template-inline.patch was
superseding
Hello Denis,
On Wed, Jun 02, 2010 at 02:13:51PM +0200, Denis Barbier wrote:
> On 2010/6/2 Andre Espaze wrote:
> [...]
> > Your solution is however better because the exported symbols
> > are in control while in my case I remove every GetIDMapper function
> > inlining.
> [...]
>
> It seems that th
tags 584172 +fixed +pending
thanks
Hello,
It looks like the patches from the two of you are identical except for
the #if statements. I think upstream is more likely to accept André's
patch with the #ifs because of portability, so I'm going with that one
for now.
Let me know if you find that the
On 2010/6/2 Andre Espaze wrote:
[...]
> Your solution is however better because the exported symbols
> are in control while in my case I remove every GetIDMapper function
> inlining.
[...]
It seems that there is some disagreement between us, I believe that
the sentence above is the root cause. Yo
>
> > I have enclosed a patch tested on my machine, fell free to correct
> > it if I was wrong.
> [...]
>
> I do not understand why you added #if tests, just adding 'template' at
> the very beginning is enough. It was not explicit in my previous
> mail, but I tried to find an alternative solutio
On 2010/6/2 Andre Espaze wrote:
> Hello Denis,
>
> On Wed, Jun 02, 2010 at 10:30:15AM +0200, Denis Barbier wrote:
>> On 2010/6/2 Andre Espaze wrote:
>> > It is finally not necessary to build the module with the -g option,
>> > I have enclosed a patch that disable the GetIDMapper function inlining
>
Hello Denis,
On Wed, Jun 02, 2010 at 10:30:15AM +0200, Denis Barbier wrote:
> On 2010/6/2 Andre Espaze wrote:
> > It is finally not necessary to build the module with the -g option,
> > I have enclosed a patch that disable the GetIDMapper function inlining
> > when built with g++ and optimizations
On 2010/6/2 Andre Espaze wrote:
> It is finally not necessary to build the module with the -g option,
> I have enclosed a patch that disable the GetIDMapper function inlining
> when built with g++ and optimizations.
Hello,
I am no C++ expert, but this looks very similar to
http://www.parashift
It is finally not necessary to build the module with the -g option,
I have enclosed a patch that disable the GetIDMapper function inlining
when built with g++ and optimizations.
commit 73f793cb0076b6847fc17750a5e1511af502e06c
Author: André Espaze
Date: Tue Jun 1 16:53:53 2010 +0200
No Get
11 matches
Mail list logo
