Hi again,
As I mentioned before, clang++ doesn't seem to compile memembed correctly
with the default flags. Now, if you *really really really* want to try it
with memembed on, you can first set your boost library link as you did
before, and turn off the error reporting during the compilation of memembed
(this is, to delete the -Werror flag in AmberTools/src/packmol_memgen/
packmol_memgen/lib/memembed/Makefile). As far as I can tell, it should work
and "skip" the error with ga.hpp you reported before, but the orientation
optimization process can be really slow. This is not supported of course,
but might bring you some ease of mind. I will consider this for patches, so
thanks for bringing up the topic.
Cheers,
2018-04-27 8:37 GMT+02:00 Gustaf Olsson <gustaf.olsson.lnu.se>:
> Hello again Hai and David
>
> So, this is going to be an interesting piece of mail again
> *insert-smile-here*. It turned out that poorly configured input was the
> culprit in the sqm related issue in the parallell version of amber. Now,
> this is where it gets strange, when antechamber failed on sqm it did report
> the “to_be_dispatched” sqm version as being unable to execute HOWEVER:
>
> which sqm
> /SOFTWARE/amber18/bin/sqm
> echo $AMBERHOME
> SOFTWARE/amber18
>
> Of course $AMBERHOME is set, this is why I reacted. Something seemed off
> and something is strange, when sqm works the correct version runs though
> when it failed the incorrect version was reported as being the issue.
>
> Lets ignore this since it does not seem to be an issue. Using clang and
> mpich, I have serial and parallell compiled AmberTools18 without errors,
> warnings sure though no larger errors or problems. Now, the BOOST issue is
> the only lingering problem. Having read up on packmol-memgen it does seem
> fantastically interesting and sounds like a fantastic addition. Yes, I can
> still execute the binary and this is just me not being able to let got of
> errors. I actually had a dream involving "lboost_tread” error last night,
> its that bad.
>
> So, like any normal person I got up early and got started with using
> MacPorts and the GNU set of compilers building amber18. The installation
> using gcc7 and mpich worked, both serial and parallell installations ran
> without major errors though both reported the missing BOOST libraries. So I
> went ahead and installed boost from MacPorts and this was worse than the
> HomeBrew alternative since this install did not even include the
> boost_thread header file. Also notice that this installation does NOT
> include
> libboost_thread.a/libboost_thread.dylib but rather
> libboost_thread-mt.dylib (sadly no libboost_thread-mt.a). So the statement
> I read that BOOST for mac only ships with the "-mt.*” files seems correct
> and this needs to be considered in a potential fix.
>
> This is roughly what happened:
>
> sudo port select --set gcc mp-gcc7
> sudo port select --set mpi mpich-gcc7-fortran
> sudo port install boost
> ./configure -macAccelerate gnu
> …
> ...
> Warning: Could not link to boost. Ensure boost-thread, boost-system and
> boost headers are installed.
> Warning: Failed command:
> g++ -fPIC -lboost_thread -lboost_system -o testp testp.cpp
> Warning: Check boost.compile.err for error details.
> Warning: Memembed functionality in packmol_memgen not available.
> …
> …
> port info boost
> boost .1.66.0_3 (devel)
>
> port contents boost
> /opt/local/lib/libboost_thread-mt.dylib
> /opt/local/lib/libboost_system-mt.a
> /opt/local/lib/libboost_system-mt.dylib
>
>
> So obviously, symlinking the library file did nothing since there is no
> header file for boost_thread.
>
> This leaves me with two viable options, install boost from source and see
> what happens (although if the statement that mac version ships only with
> -mt files this will still need tinkering to work) or contact the “port”
> maintainers and see if I need to tweak the install in some manner to get
> the missing header file and then try changing the symlinks as tried with
> Homebrew.
>
> Thank you for all feedback and you interest, I’ll keep trying and well se
> what happens.
>
> // Gustaf
>
>
>
>
> On 26 Apr 2018, at 19:21, Stephan Schott <schottve.hhu.de<mailto:schott
> ve.hhu.de>> wrote:
>
> Seems like memembed doesn't compile correctly with clang++. I'll keep this
> into consideration for possible patches. Again, this means that you can
> still use packmol-memgen, if you are interested, just without the automated
> orientation into membranes.
>
> Regarding your parallel compilation, you should give us more info regarding
> what mpi compiler you used. Also, if your binaries are in the
> "to_be_dispatched" folder and not just in bin, I would suspect your
> installation went wrong somewhere. Did the installation finish
> successfully?
>
> Cheers,
>
> 2018-04-26 11:43 GMT+02:00 Gustaf Olsson <gustaf.olsson.lnu.se<mailto:g
> ustaf.olsson.lnu.se>>:
>
> I ignored BOOST and compiled serial version, seems to have been working
> fine for all purposes investigated yesterday.
>
> Compiled the parallell version today and running antechamber received an
> error in the lines of:
>
> ../to-be-dispatched/bin/sqm -O -i sqm.in -o sum.out
> Could not be executed..
>
> Sadly I did not save the exact error so this is just a rough guess. I am
> recompiling the serial version now and I’ll try to recreate the issue later
> on.
>
> // Gustaf
>
> On 26 Apr 2018, at 10:59, Stephan Schott <schottve.hhu.de<mailto:schott
> ve.hhu.de><mailto:schott
> ve.hhu.de<mailto:ve.hhu.de>>> wrote:
>
> Hi Gustaf,
> You can find the boost.compile.err file under AmberTools/src/ . Could you
> tell me what version of boost you have in your machine? The -mt libraries
> are a way of distinguishing the multi-threaded variants of the libs, but
> afaik this should be included in the main library after boost 1.5 or so. As
> Hai mentioned, all the functionalities of Amber will work with the
> exception of the automated protein orientation in membranes done by
> memembed in packmol-memgen. This means that you can still use the workflow
> but by providing a preoriented structure (with OPM for example). Thanks for
> testing though, is very valuable info.
>
>
> 2018-04-26 9:32 GMT+02:00 Gustaf Olsson <gustaf.olsson.lnu.se<mailto:g
> ustaf.olsson.lnu.se><mailto:g
> ustaf.olsson.lnu.se<mailto:ustaf.olsson.lnu.se>>>:
>
> Hi Stephan (David and Hai as well).
>
> Could you send me or attach the content of boost.compile.err?
>
> I probably could if I knew where to find it though I sort of solved the
> issue instead.
>
> do you need to use packmol_memgen? If not, you can skip that warning and
> go ahead "make install"
>
> To be honest, I have not even read the info on packmol_memgen so I can’t
> answer that question. This is more of an OCD related problem at this point.
>
>
>
> Below you’ll find the output from ./configure. It now finds and tests
> boost successfully.
>
> Testing the clang++ compiler with boost:
> clang++ -fPIC -lboost_thread -lboost_system -o testp testp.cpp
> OK
>
> Anyway, the initial issue seems to have been filenames. The mac-boost
> libraries seems to ship with "libboost_thread-mt.a" and
> "libboost_thread-mt.dylib” instead of the sought after "libboost_thread.a"
> and “libboost_thread.dylib”, this means that a simple symbolic link
> addition to usr/local/lib/ solved the issue with configuration.
>
> I am not a programmer of any sort so apologies for my possibly crude
> assumptions and horrible example though it seems that this could be solved
> by including some sort of IF check along the lines of:
>
> if os=OSX && homebrew=TRUE
> $boost_threads_prefix=libboost_thread-mt
> else
> $boost_threads_prefix=libboost_thread
>
> I realise that this would have to be more complex of course. It also seems
> that OS X does not set BOOST_ROOT and BOOST_LIBDIR even with brew boost
> installed and as I don’t know if these are called during config/install I
> don’t know if this would be a part of the fix. Basically, make sure BOOST
> can be found and cover both libboost_thread and libboost_thread-mt.
>
> Unfortunately, even if the tests passed "make install" failed
>
> clang: warning: libstdc++ is deprecated; move to libc++ with a minimum
> deployment target of OS X 10.9 [-Wdeprecated]
>
> src/ga.hpp:45:15: error: private field 'w' is not used
> [-Werror,-Wunused-private-field]
> unsigned int w, x, y, z, c;
> ^
> 1 error generated.
> make[4]: *** [src/ga.o] Error 1
> make[3]: *** [install.memembed] Error 2
>
> cp: packmol_memgen/lib/memembed/bin/memembed: No such file or directory
> make[2]: *** [packmol-memgen] Error 1
> make[1]: *** [serial] Error 2
> make: *** [install] Error 2
>
> The warning is obviously an indication that there is a library conflict
> between Mac and Brew, I am sure that either sorting out the priorities or
> adding more symlinks can solve this as well though I have spend the time I
> had allocated for today on this issue. It is still kind of strange, I am
> assuming that the binary was not built and hence cannot be copied though I
> have no other error indication that something failed.
>
> I’ll keep looking for a working solution to these issues and if I manage
> to sort it out I’ll post something here! Meanwhile, if someone else figures
> out how to get this working, please do share!
>
> // Gustaf
>
>
> On 25 Apr 2018, at 16:53, Stephan Schott <schottve.hhu.de<mailto:schott
> ve.hhu.de><mailto:schott
> ve.hhu.de<mailto:ve.hhu.de>><mailto:schott
> ve.hhu.de<mailto:ve.hhu.de><mailto:ve.hhu.de>>> wrote:
>
> Hi,
> Could you send me or attach the content of boost.compile.err? Maybe we can
> get a hint of what is going on from there.
>
> 2018-04-25 14:53 GMT+02:00 David A Case <david.case.rutgers.edu<mailto:
> david.case.rutgers.edu><mailto:
> david.case.rutgers.edu<mailto:david.case.rutgers.edu>><mailto:
> david.case.rutgers.edu<mailto:david.case.rutgers.edu><mailto:
> david.case.rutgers.edu>>>:
>
> On Wed, Apr 25, 2018, Gustaf Olsson wrote:
>
> So I switched from MacPorts to Homebrew when switching computers. This
> meant going from GNU compilers to using CLANG which worked without a
> hitch on AmberTools17, though this time I’m getting an error.
>
> ./configure -macAccelerate gnu
>
> Testing the clang++ compiler with boost:
> clang++ -fPIC -lboost_thread -lboost_system -o testp testp.cpp
>
> Warning: Could not link to boost. Ensure boost-thread, boost-system and
> boost headers are installed.
>
> Wow: homebrew seems weird to me. It looks like it is following Apple's
> strange (to me) policy of having gcc (in spite of its name)
> point to the clang compiler and not to the GNU compiler. If things work
> without a hitch for you, that is great. But most users, and
> certainly those using macports, should follow this rule:
>
> if the "gcc" in your PATH is really clang, you should use the
> clang option for configure, not the gnu option.
>
> Concerning packmol_memgen: as far as I can tell, for now, this option
> only works for Linux. I'm sure some smart Mac user can figure out how
> to get the boost libraries either by compiling from source, or from
> macports. If someone provides detailed instructions, we'll create an
> update patch. We apologize for the inconvenience.
>
> ...dac
>
>
>
>
> --
> Stephan Schott Verdugo
> Biochemist
>
> Heinrich-Heine-Universitaet Duesseldorf
> Institut fuer Pharm. und Med. Chemie
> Universitaetsstr. 1
> 40225 Duesseldorf
> Germany
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org<mailto:AMBER.ambermd.org><mailto:AMBER.ambermd.org
> ><mailto:AMBER.ambermd.org>
> http://lists.ambermd.org/mailman/listinfo/amber
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org<mailto:AMBER.ambermd.org>
> http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
>
> --
> Stephan Schott V.
> Bioquímico / Licenciado en Bioquímica
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org<mailto:AMBER.ambermd.org>
> http://lists.ambermd.org/mailman/listinfo/amber
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
>
> --
> Stephan Schott Verdugo
> Biochemist
>
> Heinrich-Heine-Universitaet Duesseldorf
> Institut fuer Pharm. und Med. Chemie
> Universitaetsstr. 1
> 40225 Duesseldorf
> Germany
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org<mailto:AMBER.ambermd.org>
> http://lists.ambermd.org/mailman/listinfo/amber
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
Stephan Schott Verdugo
Biochemist
Heinrich-Heine-Universitaet Duesseldorf
Institut fuer Pharm. und Med. Chemie
Universitaetsstr. 1
40225 Duesseldorf
Germany
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Apr 27 2018 - 04:30:03 PDT
