Repository: spack/spack

Issue:
gettext: Problem with libxml2
I'm having trouble building gettext on some ancient SuSE11; see attached build log.  Has anyone come across this before?  `gettext/package.py` has not changed since last August.

```
libtool: link: /gpfsm/dnb53/rpfische/spack-tools/lib/spack/env/gcc/gcc -fPIC -o .libs/msgcomm msgcomm-msgcomm.o  ./.libs/libgettextsrc.so /gpfsm/dnb53/rpfische/tmp/spack-stage/spack-stage-WhGuEm/gettext-0.19.8.1/gettext-tools/gnulib-lib/.libs/libgettextlib.so -lacl /usr/lib64/libxml2.so -ldl -lz -lm -lncurses /gpfsm/dnb53/rpfische/tmp/spack-stage/spack-stage-WhGuEm/gettext-0.19.8.1/gettext-tools/intl/.libs/libintl.so -lc -fopenmp -Wl,-rpath -Wl,/gpfsm/dnb53/rpfische/spack-tools/opt/spack/linux-suse_linux11-x86_64/gcc-5.3.0/gettext-0.19.8.1-odf5uuy4jjcxpn3tcuogw7liukyqmusr/lib
./.libs/libgettextsrc.so: undefined reference to `xmlOutputBufferGetContent'
./.libs/libgettextsrc.so: undefined reference to `xmlXPathSetContextNode'
collect2: error: ld returned 1 exit status
```

[spack-build.out.txt](https://github.com/LLNL/spack/files/717680/spack-build.out.txt)




Discussion:
I encountered a similar problem recently. The problem was that something (don't know what) picked up the system's `libxml2` instead of Spack's. The solution was to build with `~libxml2`.

Your output contains the string `/usr/lib64/libxml2.so`, which probably should not be there.

Any updates concerning this? I'd rather not use the `~libxml2` workaround, if someone has discovered the root cause in the meantime... :)
So I think I got to the bottom of this, with help from the [bug-gettext mailing list](http://lists.gnu.org/archive/html/bug-gettext/2017-10/msg00012.html).

The gist is that using `--with-libxml2-prefix` is unreliable, as the configure script / linker expects the lib directory to be called `lib64` on biarch platforms. This is not the case with spack-installed `libxml2`, so the linker tries to link against the system-installed version, if available.

It's therefore easier to simply provide the include and lib paths as flags to configure. See this commit: https://github.com/dlukes/spack/commit/5caef9d0e890c4cd6a76f1bf87d7120f79c2eb0d
Oh and by the way, adding a `lib64` symlink to `lib` in Spack's `libxml2` directory also resolves the issue. Maybe it might be a good idea to make Spack add these automatically on relevant platforms -- not just for `libxml2`, but all libraries...? I'm not a packaging expert, so I can't really assess all of the ramifications, but I think a systemic solution like this is at least worth considering :) What do you think, @citibeth, @eschnett?
@dlukes would you be inclined (and have the time) to update the Spack `gettext` package in a PR?
Sure, I'd love to, it's basically just a matter of turning https://github.com/dlukes/spack/commit/5caef9d0e890c4cd6a76f1bf87d7120f79c2eb0d into a PR :)

Though as mentioned above, I'm not sure whether it's the cleanest solution -- making Spack create a `lib64` symlink to `lib` as part of the install phase of all packages would be more future-proof... It would also make it possible to use provided `configure` flags like `--with-libxml2-prefix` instead of manually passing `CPPFLAGS` and `LDFLAGS`, which feels kind of messy when a standard option is available.

Three things to consider though:

1. Should the symlink be created only if a multi-arch setup is detected? I'm inclined to think it's unnecessary to bother with that, the link should be harmless on systems where it's not needed, but maybe I'm wrong.
2. Are there other links of this type that might be needed? I confess I've no idea, my sysadmin knowledge is very haphazard.
3. This won't help existing Spack installations, people will have to create the links manually in already installed libraries, and there's probably no good way of giving them a hint they need to do so. By contrast, if the package is updated, people just need to pull the update in order for the package to start building.

Any thoughts? Should I stop worrying about `lib64`, leave that for you guys to consider whether it's worth addressing in the grander scheme of things, and just start a stopgap PR for `gettext`? :)

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/gettext/package.py b/var/spack/repos/builtin/packages/gettext/package.py
--- a/var/spack/repos/builtin/packages/gettext/package.py
+++ b/var/spack/repos/builtin/packages/gettext/package.py
@@ -84,8 +84,10 @@ def configure_args(self):
             config_args.append('--disable-curses')
 
         if '+libxml2' in spec:
-            config_args.append('--with-libxml2-prefix={0}'.format(
+            config_args.append('CPPFLAGS=-I{0}/include'.format(
                 spec['libxml2'].prefix))
+            config_args.append('LDFLAGS=-L{0} -Wl,-rpath,{0}'.format(
+                spec['libxml2'].libs.directories[0]))
         else:
             config_args.append('--with-included-libxml')
 


Test patch: