Many thanks for the quick response. I think I am OK for the runtime as I
am using the msvc compiler from the platform SDK. Depends.exe only picks
up MSVCP90.dll and MSVCR90.dll and KERNEL32.dll.
What is unusual in this package is that boost.python is being linked
into the pyd file by adding all the .cpp files in distutils. It seems
the link error can be suppressed by defining either:
BOOST_THREAD_BUILD_DLL or BOOST_THREAD_BUILD_LIB
...but which one is better, or does it make no difference?
We have already defined BOOST_ALL_NO_LIB to disable auto-linking.
I guess I am really wondering what on earth is behind the tss issue and
whether there is a simple test case to see if we are doing it right.
Would something like a little function which creates and destroys
threads show a memory leak if the tss is not right?
Thanks,
Jon
On 20/02/2012 23:42, Niall Douglas wrote:
Generally when I see that missing symbol it means mismatched C
runtimes. Usually in my experience it's safe to declare that symbol
as weak to make the link error go away while handling if it's present
correctly.
Niall
On 20 Feb 2012 at 20:02, Jon Wright wrote:
Hello,
I have been trying to build pyopencl and pycuda on windows using the
subset of boost in those packages on windows 64 bit. The problem is a
link error due to missing tss_cleanup_implemented. The codes seem to run
without problem if the link error is suppressed:
http://thread.gmane.org/gmane.comp.python.cuda/2516
Does anyone know what the tss issue is about and whether it is likely to
cause a problem? Any advice would be welcome.
Many thanks,
Jon
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
