On 16/12/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Pete Robbins wrote:
> On 16/12/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Under revision r487731 I added some code to Logger.cpp to check the
>> length of log messages to avoid buffer overruns, in particular when
>> logging big XML documents or SDOs. I also changed the buffer allocated
>> on the stack from 4096 to 256 chars as most log messages are smaller
>> than that, and bigger buffers are now allocated from the heap instead.
>>
>> I had to write this differently on Linux and Windows (vsnprintf on Linux
>> and a combination of vnsprintf and _vscprintf on Windows). Could
>> somebody try to compile and test this Mac-OS X as well? To test it, run
>> any scenario that flows big XML docs (PythonWeatherForecast is a good
>> one) with TUSCANY_SCACPP_LOGGING=2, and make sure that the log does not
>> contain garbage and that the entire XML docs returned by the Web Service
>> are logged .
>
>
> I'll test it out on Mac but I'm having trouble building the REST
> extension.
> The tuscany_sca_rest_reference and tuscany_sca_rest_service both link
> with
> tuscany_sca_rest_interface. This causes duplicate definitions of the
> symbol
> tuscany_sca_extension_initialize... which sort of makes sense. We may
> need
> to split the tuscany_sca_interface library up into the part that is the
> extension and ... the rest if the other libs need to link against this. I
> take it this is not a problem on Linux?
>
Does it mean that if you dynamically load DLLs A and B for example,
which both link to C, then C is getting loaded twice? Is this specific
to what we do with our extensions or a more general problem on the Mac?
Unless we are accidentally statically linking this shouldn't be a problem.
I think that there's also a related problem on Windows, when we
dynamically load an extension DLL A linked to another extension DLL C,
we need to have the directory containing DLL C on the Windows PATH
(ironically we don't need A), and it's really confusing and not convenient.
Yes it's a pain... but it's the same on Linux.
I think we need to look at our three Linux, Mac-OS, WIndows platforms
and try to find a consistent scheme that works well on all of them.
--
Jean-Sebastien
Not sure what the problem is as I haven't really looked into it but...
I think the problem is the external symbols we have for our extension
entry point.
library A exports symbol x
library B exports symbol x but also links with A
The symbol "x" is the same name for all our extensions so I assume
there is a clash. There is probably a linker option that will ignore
the duplicate symbol. I'm assuming that the linux build works?? (my
linux system is in repair mode at the moment!).
I'll check I'm not statically linking but I'm using the same automake as linux.
Cheers,
--
Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
