[gmx-developers] building fully static mdrun

[Christoph Junghans]

2012/7/11 Roland Schulz <roland at utk.edu>:
> On Wed, Jul 11, 2012 at 2:11 PM, Szilárd Páll <szilard.pall at cbr.su.se> wrote:
>> On Wed, Jul 11, 2012 at 7:13 PM, Roland Schulz <roland at utk.edu> wrote:
>>>
>>> Hi,
>>>
>>> I don't think it is useful besides on supercomputers. There the
>>
>>
>> That's exactly what I would intend it it to be used for.
>>>
>>> advantage is that it works better with the command launching mechanism
>>> (and that also partly only because the didn't make the extra effort to
>>> get it to work at least for dynamic linked libraries with prior known
>>> libraries (no dlopen)). And last time I checked on Cray and Bluegene
>>> one automatically gets fully static binaries without any problems.
>>
>>
>> I know of at least 1-2 Crays where it was slightly tedious to get
>> dynamically linked binaries to work. The compiler wrappers were assuming
>> that, by applying their internal mumbo-jumbo, static linking will just work,
>> while CMake intended to link dynamically.
> Yes it is tedious to get dynamic liberies to work. But on the Crays I
> have access to, the compiler wrappers give me a fully static version
> of Gromacs without any problems. The compiler wrappers automatically
> add the "-static". Of course this fails if cmake only finds a dynamic
> library and thus picks that. I usually only have that with  libxml2
> but than all I need to do is use -DGMX_XML=no. Is that what you want
> to fix? That it doesn't try to use dynamic libraries if it can't find
> a static version? If so I'm not against it, but I also don't think it
> is very important because "-DGMX_XML=no" is so easy.
Not to mention that older versions of libxml2 are broken for static
linking anyway:
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590934>
We had a check for that in autotools, but haven't converted it to cmake.

Christoph

>>
>>>
>>> What would be useful for distributing binaries is if
>>> GMX_PREFER_STATIC_LIBS would automatically gets libgomp linked
>>> statically.
>>
>>
>> No idea, -static will work if all libraries (both external and system) are
>> available in static form. Otherwise, -fopenmp seems to always pull in
>> libgomp.so.
>>
>> Are the rest of the system lib dependencies not an issue?
> The problem with libgomp is that it isn't a standard system library.
> Standard system libraries are part of the base system and thus always
> installed. But libgomp is part of gcc and not guaranteed to be
> available. The same is true for libgcc but it can be easily fixed with
> -static-libgcc. But sadly (see
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400) it doesn't
> automatically also make libgomp static. But we could work around it
> relatively easily by not setting -fopenmp for the linker but instead
> "-Wl,-static -lgomp -lrt -Wl,-Bdynamic -lpthread" if
> GMX_PREFER_STATIC_LIBS is set (of course this is gcc specific). I
> could put this in Jenkins but I think it is better to keep Jenkins
> simple and have it in cmake.
>
> Roland
>
>>
>> --
>> Sz.
>>
>>>
>>> BTW: I configured Jenkins to build automatic binaries. The Linux
>>> binaries work on all Linux distributions I have tested. Let me know if
>>> they work for you too. My idea is to have binaries for all important
>>> platforms on Jenkins so that when we have the 4.6beta, people can test
>>> it without having to compile it. I think this will get us more
>>> feedback. All binaries are with SSE2 acceleration. Currently you still
>>> need to set LD_LIBRARY_PATH if you extract it to somewhere else the
>>> /usr/local/gromacs (fixed by I7ec8707a). The Windows binary still has
>>> a weird path (fixed by Ie656d5fc).
>>>
>>> http://jenkins.gromacs.org/job/Gromacs_Nightly_Linux32_4_6/lastSuccessfulBuild/artifact/Gromacs-4.6-dev-Linux.tar.gz
>>>
>>> http://jenkins.gromacs.org/job/Gromacs_Nightly_Linux64_4_6/lastSuccessfulBuild/artifact/Gromacs-4.6-dev-Linux.tar.gz
>>>
>>> http://jenkins.gromacs.org/job/Gromacs_Nightly_Win64_4_6/lastSuccessfulBuild/artifact/Gromacs-4.6-dev-win64.exe
>>>
>>> Roland
>>>
>>> On Wed, Jul 11, 2012 at 12:40 PM, Szilárd Páll <szilard.pall at cbr.su.se>
>>> wrote:
>>> > Hi,
>>> >
>>> > In some cases it is required or advised to use a fully static linked
>>> > mdrun,
>>> > for instance on some Cray machines. There have been around some
>>> > (slightly
>>> > dirty) workarounds [1], but I think it is not desirable to have such
>>> > solutions advised to users.
>>> >
>>> > Implementing this in CMake, beside thorough testing, requires only a
>>> > couple
>>> > of lines of code (especially if enabled for mdrun only). However, first
>>> > it
>>> > would be good to know whether this is useful or not.
>>> >
>>> > Let me know if you know of for which statically linked binaries are
>>> > required
>>> > or advised!
>>> >
>>> > Cheers,
>>> > --
>>> > Szilárd
>>> > *
>>> > [1]
>>> >
>>> > http://www.hector.ac.uk/support/documentation/software/gromacs/compiling_4-6-0_phase3.php
>>>
>>>
>>>
>>> --
>>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
>>> 865-241-1537, ORNL PO BOX 2008 MS6309
>>> --
>>> gmx-developers mailing list
>>> gmx-developers at gromacs.org
>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>> Please don't post (un)subscribe requests to the list. Use the
>>> www interface or send it to gmx-developers-request at gromacs.org.
>
>
>
> --
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> 865-241-1537, ORNL PO BOX 2008 MS6309
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.



-- 
Christoph Junghans
Web: http://www.compphys.de