Static POCO Libraries for Windows

[kadleth]

Not only for Linux. I am particularly interested in the static POCO libraries for XP64, I specificaly care for the threading libraries which is why I am here in 1st place. Haven't checked if is practical to have static versions of POCO threads (e.g. OpenMP & Intel TBB require be DLL exclusive to work well). Have many other things to do to check that so I'll trust you that.

[alex]

Yes, it is practical. In fact, the libraries do come with static build configurations on windows. As for 64-bit windows, everything should work (I know it does on 64-bit Linux)- some people have inquired about it, but I'm not sure whether anyone is actually using it.

[kadleth]

But is POCO threads, as in XP64, truly taking full advantage of 64b functionality? Is it a 32b library? Is is a mere 64b wrap to 32b fucntionality? Or part 32b library & part 64b library?

[alex]

But is POCO threads, as in XP64, truly taking full advantage of 64b functionality? Is it a 32b library? Is is a mere 64b wrap to 32b fucntionality? Or part 32b library & part 64b library?

How does one "take advantage" of 64-bit functionality other than compiling code for a 64-bit platform?

POCO is portable and we steer very clear of asm, _Interlocked* and similar low-level facilities - if those are ever introduced, it will be in a very careful manner. As for threads - I may be missing something important, but I can not find anything 64-bit specific in windows threading API documentation, so I'm probably not the best person to answer that question. Since you apparently have some detailed knowledge of 64-bit threading advantages on x64 Windows operating systems and all the source code is freely available, maybe you could let us know whether POCO is utilizing those advantages and, if not, file a SF tracker feature request or (even better) a patch.

[normanAtMdaDotCa]

We have used static POCO libraries on our XP 32-bit machines, because
the dynamic libraries were preventing the registration of the application
dll of our COM project (missing msJava.dll ???). Anyway, using static
POCO worked around the problem. Does this ring any bells for anyone?
Are there any potential problems for using POCO static versus POCO dynamic?

(We were able to use the dynamic POCO to build the application to run
on our own machines. It was only during the registration phase of the
installation script that this problem occurred).

Thanks.