Hi All,
We encountered cpptraj compilation error when we removed FFTW-related
pbsa codes under AmberTools/src/pbsa/ and in configure2, and some
related test cases. The weird thing is the error occurred even we didn't
touch any code outside pbsa. These errors are as follows, seems missing
proper FFTW header file path. I didn't find any pbsa-variable in
configure2 that could cause this. Could anybody look into this please?
The compilation was on gnu 4.4/5.0 with cuda 7.5. Thanks!
In file included from Analysis_FFT.cpp:4:
PubFFT.h:5:20: error: fftw3.h: No such file or directory
In file included from Corr.h:4,
from Action_VelocityAutoCorr.cpp:7:
PubFFT.h:5:20: error: fftw3.h: No such file or directory
In file included from Corr.h:4,
from Analysis_IRED.cpp:4:
PubFFT.h:5:20: error: fftw3.h: No such file or directory
In file included from Analysis_FFT.cpp:4:
PubFFT.h:27: error: ISO C++ forbids declaration of 'fftw_complex' with
no type
PubFFT.h:27: error: expected ';' before '*' token
PubFFT.h:28: error: 'fftw_plan' does not name a type
PubFFT.h:29: error: 'fftw_plan' does not name a type
Best,
Ruxi
On 3/18/17 15:13, Ray Luo wrote:
> Jason and All,
>
> I think we can boot FFTW out if this is needed for the license scheme
> to work. It's not used in sander or not used often in PBSA since we
> have both multigrid and ICCG solvers for the periodic boundary.
>
> All the best,
>
> Ray
> --
> Ray Luo, Ph.D.
> Professor of Structural Biology/Biochemistry/Biophysics,
> Chemical Physics, Biomedical Engineering, and Chemical Engineering
> Department of Molecular Biology and Biochemistry
> University of California, Irvine, CA 92697-3900
>
>
> On Sat, Mar 18, 2017 at 1:25 PM, Jason Swails<jason.swails.gmail.com> wrote:
>> On Sat, Mar 18, 2017 at 2:49 PM, David Case<david.case.rutgers.edu> wrote:
>>
>>> On Fri, Mar 17, 2017, Jason Swails wrote:
>>>
>>>> So the issue here is that by licensing libsander as LGPL, we violate the
>>>> terms of PBSA's GPL license.
>>> I'd like to ask Jason to help us out of this mess, if he is willing. In
>>> the
>>> statement just above, one could replace "PBSA" with "fftw", and illustrate
>>> a
>>> similar problem. (In fact, fftw is really at the root of most of our
>>> problems, since we can modify the PBSA license.)
>>>
>>> High-level view: we could change the licenses of anything we have written.
>>> But we also need to be able to create create a GPL code that is allowed
>>> to link to fftw libraries, and at the same time have a sander API and
>>> libsander that non-GPL codes can link to. So it seems like "sander" and
>>> "libsander" have to have different licenses.
>>>
>> I had forgotten about fftw. Fortunately, PBSA can be built *without*
>> fftw. But as long as it includes fftw, the whole thing would need to abide
>> by the GPL.
>>
>>
>>> Questions:
>>>
>>> 1. Is there a technical reason why libpbsa and libfftw3 need to be
>>> included
>>> into the Makefile target for libsander? (Stated another way: how hard
>>> would it be to eliminate these?) I think the sander API does not
>>> expose
>>> either pbsa or rism functionality, yet the symbols for pbsa and fftw
>>> are
>>> included in libsander, and I'm wondering if that can be changed.
>>>
>> The technical reason was ease of implementation. What might be easiest is
>> to make it so PBSA's periodic functionality is turned off both when -nofftw
>> is set *and* when that file is being built for the sander API. In that
>> case, we can omit fftw from sander and release the whole thing as L-GPL
>> (assuming we license PBSA under both the L-GPL [sans fftw] and the GPL [for
>> versions that include fftw]). I'm not sure how straightforward this is.
>>
>> PBSA could also probably be eliminated from libsander altogether, although
>> that would probably require some amount of code changes to ifdef-out the
>> hooks into sander.
>>
>> The last idea is that MKL is API-compatible with fftw, so we could also
>> permit MKL users to abide by the L-GPL (does PBSA link to MKL's FFT if MKL
>> is specified?)
>>
>>
>>> 2. Can we separate things in order to be able to make a license
>>> distinction: libsander (and its corresponding source code) could be
>>> LGPL,
>>> whereas the sander (as a whole) would be GPL? Alternative: go back
>>> to the old days, where we had separate sander.RISM (would be GPL) and
>>> and sander (would be LGPL) builds.
>>>
>> Yes, we can do that.
>>
>>
>>> We don't necessarily need to get this done for the AmberTools17 release,
>>> but
>>> should be trying in good faith to make any required changes. Weaning
>>> ourselves from fftw might be a long-term goal, but would be far from easy.
>>>
>> It *would* be nice to boot FFTW from sander from a licensing perspective.
>>
>> Ray -- are the periodic options even available from sander? If not, that
>> makes things easy -- just remove that part from sander altogether and fftw
>> never enters the picture (assuming we can also get rid of from the sander
>> API).
>>
>> Thanks,
>> Jason
>>
>> --
>> Jason M. Swails
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 22 2017 - 01:00:02 PDT
