[gmx-developers] issues with libxml detection issues with GMX_BUILD_UNITTESTS=ON

[Mark Abraham]

Hi,

On Thu, Feb 18, 2016 at 2:57 PM Dominik 'Rathann' Mierzejewski <
dominik at greysector.net> wrote:

> Hi,
>
> On Thursday, 18 February 2016 at 14:39, Mark Abraham wrote:
> > Hi,
> >
> > Yes, perhaps that call to check_library_exists can be improved, e.g. by
> > setting CMAKE_REQUIRED_LIBRARIES for the check (see
> > https://cmake.org/cmake/help/v3.0/module/CheckLibraryExists.html).
> However,
> > it is awkward to do a good job here, because libxml2 only requires zlib
> if
> > the former was configured that way, so we have a fairly large number of
> > conditions to handle in constructing our handling (shared/static, whether
> > either was found, whether libxml2 needs zlib or not, whether test
> binaries
> > need to be built, etc.).
>
> I'd suggest checking if a test binary links against the detected libxml2
> successfully.


Yes, that's what the check in question is supposed to do. It's just not
simple to set it up so that it always does the right thing. We can't just
unilaterally link zlib, because there's probably some linker that will some
day complain if it can't be found, even if it is actually unused because
the libxml2 library was configured without zlib support. It is also unclear
whether CMAKE_REQUIRED_LIBRARIES honors the previously expressed
preferences for shared vs static libs, with all linkers, etc.

I'm not sure if that cmake check does that. Also, the
> libxml2 copy that I have has a .pc file, which means you can get the
> necessary libraries to link using pkg-config.
>

Yeah, we do use that for FFTW if available, but some of the problem reports
come from BlueGene/Q machines, and we cannot base our solution on assuming
such infrastructure exists. Supercomputers tend to ship based on
prehistoric distros, which tends to be unsuitable for everybody except the
vendor.


> > Roland suggested https://gerrit.gromacs.org/#/c/5630/2 but I am not
> sure if
> > it is related.
>
> > Alternatively/also, since currently the only use for XML handling in
> master
> > branch is for test reference data, I have uploaded
> > https://gerrit.gromacs.org/#/c/5653/ to replace this use of libxml2
> with a
> > bundled copy of tinyxml2, as part of
> http://redmine.gromacs.org/issues/1908 so
> > that we get rid of such problematic external dependencies. These have
> been
> > causing grief lately for users on BG/Q machines. I suggest we keep
> libxml2
> > detection and handling present but inactive while the future of various
> > patches in Gerrit gets resolved.
>
> Please retain the option to use system copy of tinyxml. It's widely
> available in various Linux distributions and bundling leads to security
> issues and bloat. If you do start bundling tinyxml, I'll have to
> unbundle and link against system library anyway, according to Fedora
> Packaging Guidelines.
>

We can certainly plan to retain that option for tinyxml2. Are there any
other problematic areas? We've de-required Boost for the upcoming GROMACS
2016 release. We bundle Google Mock, but it only supports our testing, so
e.g. a distro user-space package does not need to bundle or require it.

Mark

Regards,
> Dominik (Fedora maintainer of GROMACS package)
> --
> Fedora http://fedoraproject.org/wiki/User:Rathann
> RPMFusion http://rpmfusion.org
> "Faith manages."
>         -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
> --
> 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/20160218/42152757/attachment-0002.html>