Hi Mike, I added the missing dependencies [1], which made the build green again.
Cheers, Rob [1] http://git.savannah.gnu.org/cgit/hydra-recipes.git/commit/?id=3f03d7a5cec7ca5d9bcb4e02733888022f70605b On Thu, Aug 17, 2017 at 9:07 PM, Mike Miller <[email protected]> wrote: > 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 -- Rob Vermaas [email] [email protected]
