Octave build jobs failing due to indirect library dependencies

[Mike Miller]

Hi,

For about a year now (first failing build [1]), the GNU Octave Hydra
build jobs have been continuously failing. I believe this is may be due
to a bug in GraphicsMagick, or some quirk of the Nix / Hydra build
environment that I don't understand, can someone help shed some light on
this or point me in the right direction?

The build fails with the following linker error:

    /nix/store/...-binutils-2.23.1/bin/ld: cannot find -ltiff
    /nix/store/...-binutils-2.23.1/bin/ld: cannot find -llzma
    /nix/store/...-binutils-2.23.1/bin/ld: cannot find -ljpeg
    collect2: error: ld returned 1 exit status

GNU Octave does not depend on or link with these shared libraries
directly. I believe they are included indirectly via GraphicsMagick. And
these closures do seem to be present in the build environment.

The linker command line includes the following arguments (in this
relative order, many others elided):

    -ltiff
    /nix/store/...-libtiff-4.0.3/lib/libtiff.so
    -llzma
    -ljpeg
    /nix/store/...-libjpeg-turbo-1.3.1/lib/libjpeg.so
    /nix/store/...-xz-5.0.7/lib/liblzma.so

I think it's safe to say the linker error occurs because the command
line is notably missing arguments of the form:

    -L/nix/store/...-libtiff-4.0.3/lib
    -L/nix/store/...-libjpeg-turbo-1.3.1/lib
    -L/nix/store/...-xz-5.0.7/lib

This looks to me like a bug in the GraphicsMagick libtool dependency
listing. Can someone help confirm this or give me a hint how to pursue
this lead? Where can I fetch a copy of the GraphicsMagick closure to
inspect its declared library dependencies?

On a related note, why is Hydra building Octave against GraphicsMagick
1.3.18, when browing the Hydra web interface shows 1.3.26 as the current
version?

OTOH, Octave's tarball job *does* succeed. The relevant difference
appears to be the build environment itself, which does include more
dependencies. Somehow the -L options listed above *are* present in the
tarball job log file (for example [2]). They seem to be picked up
accidentally in the FLIBS variable by the AC_F77_LIBRARY_LDFLAGS macro.
I can only guess that -L options are being added to the build
environment automatically for dependencies with a lib directory.

I'd rather see this fixed so that linking with the actual direct
dependencies works the way it's supposed to rather than accidentally.

Thanks for any help,

[1]: https://hydra.nixos.org/build/35345448
[2]: https://hydra.nixos.org/build/58776721

-- 
mike

signature.asc
Description: PGP signature