[gmx-developers] Compilation Errors When Using GROMACS Headers/Library

Wed Jul 6 17:45:10 CEST 2016

My apologies -

Here is a link to the dump.c source file
<https://fossies.org/dox/gromacs-5.1.2/dump_8c_source.html> that I made
reference to in my first response.

Also, the documentation I referred to is the XTC Library
<http://www.gromacs.org/Developer_Zone/Programming_Guide/XTC_Library>. I
did pull the library's source code from the GitHub repository specified in
that sparse documentation and I looked through the source code a bit. But,
I didn't really know where to look for anything that would have informed me
how to use the library. From my perspective, it was much easier to just
read the list_xtc function from dump.c and figure out how it worked.

On Wed, Jul 6, 2016 at 5:36 PM, Vladislav Martin <martin.vl at husky.neu.edu>
wrote:

> Mark,
>
> Perfect! Now I feel silly - in all honesty, I never knew that "it is
> normal behaviour for installed headers intended for third-party development
> to expect to have their path prepended by the preprocessor". Now that I
> know that, it is obvious that I simply needed to specify a directory to
> search for header files, by using the -I option
> <https://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Preprocessor-Options.html#Preprocessor-Options>
> .
>
> > Do also be aware that libxdrfile is a thing.
>
> I am aware of libxdrfile, but as of yet I have yet to find enough
> documentation explaining it's use. The simple reason that I haven't used it
> is that I don't know how to use it.
>
> So, I searched for other means that have already been implemented to read
> XTC trajectory files. After looking around the GROMACS 5.1.2 source code
> for references to XTC files, I was able to find the list_xtc(const char
> *fn) function specified in the dump.c source file located at
> src/gromacs/tools/dump.c. I used the code that I found in this function
> to write the read_trajectory.c file I was compiling.
>
> Where might I find documentation that explains how I can use the
> libxdrfile library to access all of the information that is accessed by
> the list_xtc function? Also, why do you recommend this library over just
> using the GROMACS header files - does it allow for more efficient reading
> of the XTC files?
>
>
> On Wed, Jul 6, 2016 at 5:06 PM, Mark Abraham <mark.j.abraham at gmail.com>
> wrote:
>
>> Hi,
>>
>> It is normal behaviour for installed headers intended for third-party
>> development to expect to have their path prepended by the preprocessor, e.g.
>>
>> gcc -I/usr/local/gromacs/include yourfile.c
>> -L/usr/local/gromacs/lib/whatever -lgromacs
>>
>> This means that the same header file can be used the same way when
>> compiling libgromacs, so one gets some sanity for free. Otherwise, we'd
>> also have to run some kind of script at "make install" time that copied the
>> files and edited them, similar to what you have done with sed. Also, you'll
>> have a harder time testing your code against multiple versions of GROMACS
>> if you've hard-coded the path to the include files, perhaps in many places,
>> directly in your code - the -I option is very much your friend.
>>
>> Do also be aware that libxdrfile is a thing.
>>
>> Mark
>>
>> On Wed, Jul 6, 2016 at 4:53 PM Vladislav Martin <martin.vl at husky.neu.edu>
>> wrote:
>>
>>> Dear GROMACS developers,
>>>
>>> I am writing code in C utilizing the GROMACS 5.1.2 library. The purpose
>>> of the code is to read the binary data stored in GROMACS' XTC trajectory
>>> files into C data types for further analysis / manipulation of the data.
>>>
>>> *NOTE*: In case this would be important information, I followed the "Quick
>>> and Dirty Installation"
>>> <http://manual.gromacs.org/documentation/5.1.2/install-guide/index.html#quick-and-dirty-installation>
>>> instructions for GROMACS 5.1.2 and all commands were executed in the
>>> terminal successfully.
>>>
>>> Back to the C code. At the very top of my file, I include
>>> "/usr/local/gromacs/include/gromacs/fileio/xtcio.h" so that I may access
>>> the functions I need to read the XTC trajectory files. I ran into an odd
>>> error when attempting to compile my program.
>>>
>>> ""
>>> $ gcc -o read_trajectory read_trajectory.c -L
>>> /usr/local/gromacs/lib/x86_64-linux-gnu/ -lgromacs
>>> In file included from read_trajectory.c:3:0:
>>> /usr/local/gromacs/include/gromacs/fileio/xtcio.h:41:35: fatal error:
>>> gromacs/fileio/gmxfio.h: No such file or directory
>>>  #include "gromacs/fileio/gmxfio.h"
>>>                                    ^
>>> compilation terminated.
>>> ""
>>>
>>> I can fix this error by running a bash command that searches recursively
>>> through all header files in the "usr/local/gromacs/include/gromacs"
>>> directory and replaces 'gromacs/' (which only shows up in #include
>>> statements) with '/usr/local/gromacs/include/gromacs/' (or
>>> '/path/to/your/installation/gromacs/include/gromacs/'). I have included
>>> this bash command in case someone else experiences this compilation error
>>> and wants to fix it quickly:
>>>
>>> '""
>>> $ sudo find /usr/local/gromacs/include/gromacs/ -name '*.h' -type f
>>> -exec sed -i 's:gromacs/:/usr/local/gromacs/include/gromacs/:' {} \;
>>> ""
>>>
>>> Once I run this command, the program compiles successfully and I am able
>>> to run the resulting executable without any further errors.
>>>
>>> What confuses me is that this error could have been fixed when the
>>> GROMACS header files were created in the first place - I shouldn't have to
>>> fix the relative paths where the header files are supposed to look for &
>>> find the other GROMACS header files. From what I can tell (I read the #include
>>> directives
>>> <http://manual.gromacs.org/documentation/5.1.2/dev-manual/includestyle.html>),
>>> every header file is contained within the
>>> "/usr/local/gromacs/include/gromacs/" directory (or, more generally,
>>> "/path/to/your/installation/gromacs/include/gromacs/"). Within that
>>> directory there are modular directories that store related headers, like
>>> "fileio/". Knowing all of this, why does an #include statement referring to
>>> a GROMACS header file in that *same* directory say
>>> "gromacs/fileio/gmxfio.h" - which, as a relative path, would *never*
>>> point to the right directory - instead of "gmxfio.h" or "./gmxfio.h", which
>>> actually reflects this file hierarchy?
>>>
>>> In the end, my question is simple: did I miss something in the
>>> documentation that informs me on how to include GROMACS headers files
>>> properly so that I don't have to change the include statements myself?
>>> Otherwise, is this a syntax bug that will be fixed in later GROMACS
>>> versions?
>>>
>>>
>>> Many thanks,
>>>
>>> Vladislav Martin
>>> Research Assistant
>>> Center for Nanobiology and Structural Biology
>>> Email: martin.vl at husky.neu.edu
>>> --
>>> Gromacs Developers mailing list
>>>
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>>> posting!
>>>
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>
>>> * For (un)subscribe requests visit
>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>>> or send a mail to gmx-developers-request at gromacs.org.
>>
>>
>> --
>> Gromacs Developers mailing list
>>
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>> posting!
>>
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>> or send a mail to gmx-developers-request at gromacs.org.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20160706/dbf84164/attachment-0001.html>