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>:
> 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>> 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>>:
>
> 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>>> 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>>>:
>
> 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>
> 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
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Apr 26 2018 - 10:30:03 PDT
