Glad to hear that James.
And, yes, I agree that we should take the threading discussion offline...
-greg
On Tue, Apr 14, 2015 at 4:49 PM, James Davidson <j.david...@vernalis.com>
wrote:
> Thanks Greg
>
>
>
> I have now tried using boost 1.56 (the cmake configuration once BOOST_ROOT
> is set is a little different vs. 1.55…). Either way I can’t seem to build
> with threadsafe/multithreaded support – but perhaps we should draw a line
> under it for now / follow-up ‘off-line’(?).
>
>
>
> The good news is that (with the thread settings OFF) the changes you
> checked-in (rev5616) have indeed sorted the MolHash piece, and all tests
> pass – thanks!
>
>
>
> Kind regards
>
>
>
> James
>
>
>
> *From:* Greg Landrum [mailto:greg.land...@gmail.com]
> *Sent:* 14 April 2015 05:35
> *To:* James Davidson
> *Cc:* rdkit-discuss@lists.sourceforge.net
> *Subject:* Re: [Rdkit-discuss] Problem building recent revisions on
> Windows
>
>
>
> Hi James
>
>
>
> Thanks for your patience here. I will invest the time in trying to get
> automated builds happening on this Windows side so that this stops
> happening.
>
>
>
> I just pushed some changes that should clear up the MolHash-related build
> problems. I had forgotten that that bit of code still needed to be tested
> on Windows. I haven't tested building the cartridge on Windows (I'm not set
> up to do that), but the python wrappers definitely do build for me now with
> both RDK_BUILD_THREADSAFE_SSS and RDK_TEST_MULTITHREADED set to ON. I don't
> think it should make a difference, but just in case: I am doing this using
> boost 1.56.
>
>
>
> Best,
>
> -greg
>
>
>
>
>
>
>
>
>
> On Mon, Apr 13, 2015 at 11:30 AM, James Davidson <j.david...@vernalis.com>
> wrote:
>
> Here’s an update:
>
>
>
> Tried building rev5211, but saw similar linking errors (to do with Boost
> threading libraries). The most recent build that I have successfully
> managed without the errors is rev5016.
>
>
>
> It occurred to me that a couple of my cmake options relate to threading
> (RDK_BUILD_THREADSAFE=ON; RDK_TEST_MULTITHREADED=ON) – and perhaps other
> people (Greg, Paolo) with successful Windows builds had these set OFF
> (default)(?). Indeed, if I set both of these to OFF, I can successfully
> build rev5211, and all of the tests pass.
>
> So this is good – but I still don’t understand what has changed (in
> relation to Boost threading) that means that later versions don’t build…
>
>
>
> Threading aside, I was now feeling pretty confident that I would be ok to
> build the latest revision (rev5611). Unfortunately this was not the case –
> I initially hit a problem with MolHash.cpp, which I thought was down to
> MSVC being stupid about snprintf() (line 265). After a little
> stack-overflowing, I thought changing this to _snprintf() would solve the
> problem – which it appears to (at least MolHash.cpp now compiles), but then
> I get a couple of further errors down-stream (probably related to the
> change I made?):
>
>
>
>
>
> Error 1 error LNK2019: unresolved external symbol "class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> > __cdecl RDKit::Descriptors::calcMolFormula(class
> RDKit::ROMol const &,bool,bool)" (?calcMolFormula@Descriptors@RDKit@
> @YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@
> @AEBVROMol@2@_N1@Z) referenced in function "void __cdecl
> RDKit::MolHash::generateMoleculeHashSet(class RDKit::ROMol const &,struct
> RDKit::MolHash::HashSet &,class std::vector<unsigned int,class
> std::allocator<unsigned int> > const *,class std::vector<unsigned int,class
> std::allocator<unsigned int> > const *)" (?generateMoleculeHashSet@MolHash
> @RDKit@@YAXAEBVROMol@2@AEAUHashSet@12@PEBV?$vector@IV?$allocator@I@std@
> @@std@@2@Z)
> C:\RDKit\build\Code\GraphMol\MolHash\Wrap\MolHash.lib(MolHash.obj)
> rdMolHash
>
>
>
> Error 2 error LNK1120: 1 unresolved externals
> C:\RDKit\build\rdkit\Chem\Release\rdMolHash.pyd rdMolHash
>
>
>
>
>
> So I guess it would still be good to understand the threading issue (or at
> least for someone else to be able to reproduce it); and perhaps the
> observed MolHash issue is an easier one to sort(?)
>
>
>
> Kind regards
>
>
>
> James
>
>
> ______________________________________________________________________
> PLEASE READ: This email is confidential and may be privileged. It is
> intended for the named addressee(s) only and access to it by anyone else is
> unauthorised. If you are not an addressee, any disclosure or copying of the
> contents of this email or any action taken (or not taken) in reliance on it
> is unauthorised and may be unlawful. If you have received this email in
> error, please notify the sender or postmas...@vernalis.com. Email is not
> a secure method of communication and the Company cannot accept
> responsibility for the accuracy or completeness of this message or any
> attachment(s). Please check this email for virus infection for which the
> Company accepts no responsibility. If verification of this email is sought
> then please request a hard copy. Unless otherwise stated, any views or
> opinions presented are solely those of the author and do not represent
> those of the Company.
>
> The Vernalis Group of Companies
> 100 Berkshire Place
> Wharfedale Road
> Winnersh, Berkshire
> RG41 5RD, England
> Tel: +44 (0)118 938 0000
>
> To access trading company registration and address details, please go to
> the Vernalis website at www.vernalis.com and click on the "Company
> address and registration details" link at the bottom of the page..
> ______________________________________________________________________
>
>
>
> ______________________________________________________________________
> PLEASE READ: This email is confidential and may be privileged. It is
> intended for the named addressee(s) only and access to it by anyone else is
> unauthorised. If you are not an addressee, any disclosure or copying of the
> contents of this email or any action taken (or not taken) in reliance on it
> is unauthorised and may be unlawful. If you have received this email in
> error, please notify the sender or postmas...@vernalis.com. Email is not
> a secure method of communication and the Company cannot accept
> responsibility for the accuracy or completeness of this message or any
> attachment(s). Please check this email for virus infection for which the
> Company accepts no responsibility. If verification of this email is sought
> then please request a hard copy. Unless otherwise stated, any views or
> opinions presented are solely those of the author and do not represent
> those of the Company.
>
> The Vernalis Group of Companies
> 100 Berkshire Place
> Wharfedale Road
> Winnersh, Berkshire
> RG41 5RD, England
> Tel: +44 (0)118 938 0000
>
> To access trading company registration and address details, please go to
> the Vernalis website at www.vernalis.com and click on the "Company
> address and registration details" link at the bottom of the page..
> ______________________________________________________________________
>
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
