[cairo] Performance issue with get_text_extents

[Dimiter "malkia" Stanev]

On 3/31/12 1:20 AM, Robert Prückl wrote:
> 2012/3/31 Dimiter 'malkia' Stanev<malkia at gmail.com>:
>>         I just cloned cairomm to see it, and there is a tag 1.10.0, try this
>> one I guess:
>>
>>         E:\p\cairomm>git tag
>> ----->    1.10.0
>>         1.8.6really
>>         1.8.6really2
>>         1.9.2
>>         RELEASE_0_3_0
>>         RELEASE_0_4_0
>>         RELEASE_0_5_0
>>         RELEASE_0_6_0
>>         ............
>>
>>         git checkout 1.10.0
>>
>>         (If you need help with git, you can either get it with TortoiseGit,
>> or cygwin). It's possible that there is tarball with the tagg-ed version.
>>
>
> Well, I tried also the tarball version cairomm 1.10.0 and the problem
> is exactly the same.
> I think it comes from cairomm itself - it looks as if
> cairomm-vc100-d-1_0.lib doesn't export that constructor.
> It is not listed in the .def file generated by gendef and dumpbin
> -exports on the library (which is generated in the build process)
> doesn't list it either.
>
> The calling function Cairo::Surface::get_device(void) is listed as
> ?get_device at Surface@Cairo@@QAE?AV?$RefPtr at VDevice@Cairo@@@2 at XZ
> correctly.
>
> The constructor is defined in the device.h file line 91 in the section
> external dependencies.
> explicit Device(cairo_device_t* cobject, bool has_reference = false);
>
> very strange... do you have any further suggestions?

I've looked to see what gendef.cc does, it seems to be coming from a 
project called mico (mico.org).

It's basically trying to "dllexport" all visible symbols.

Then again you said, you've never saw the exported constructor anywhere.

But just in case, can you try this:

DUMPBIN /LINKERMEMBER:1 whatever.obj or whatever.lib
or
DUMPBIN /LINKERMEMBER:2 whatever.obj or whatever.lib

Whether it shows up.

At worst, what might work for you is to tag the class and/or the 
constructor (not sure!!!) to be __declspec(dllexport) and try again.

maybe guarded with #ifdef _MSC_VER

I'm sorry I can't be of much help,
although at work I use C++ alot, at home I stick only with "C", or at 
least with "C++" libs that export only "C" interface.

Thanks,
Dimiter 'malkia' Stanev

>
>>
>> On 3/30/2012 4:37 PM, Robert Prückl wrote:
>>>
>>> Hi again,
>>>
>>> as so far nobody seem to have an idea about my previous post I wanted
>>> to upgrade to a more up-to-date version of the whole thing.
>>> The problem is: I cannot link cairomm 1.9.8 against cairo 1.10.2.
>>> The linker writes the following:
>>>
>>> surface.obj : error LNK2019: unresolved external symbol "public:
>>> __thiscall Cairo::Device::Device(struct _cairo_device *,bool)"
>>> (??0Device at Cairo@@QAE at PAU_cairo_device@@_N at Z) referenced in function
>>> "public: class Cairo::RefPtr<class Cairo::Device>    __thiscall
>>> Cairo::Surface::get_device(void)"
>>> (?get_device at Surface@Cairo@@QAE?AV?$RefPtr at VDevice@Cairo@@@2 at XZ)
>>>
>>> Win32\Debug\cairomm-vc100-d-1_0.dll : fatal error LNK1120: 1
>>> unresolved externals
>>>
>>> This is the only error while compiling/linking.
>>>
>>> Any ideas about this?
>>>
>>> best,
>>> R
>>> --
>>> cairo mailing list
>>> cairo at cairographics.org
>>> http://lists.cairographics.org/mailman/listinfo/cairo
>>>
>> --
>> cairo mailing list
>> cairo at cairographics.org
>> http://lists.cairographics.org/mailman/listinfo/cairo
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>