how to debug breakage going from one lts version to another?

[Alex Ghitza]

Hi,

Our package for dense linear algebra over the rationals

https://github.com/martinra/hlinear

builds fine under lts-5.16, but exhibits linking errors with lts-5.17.  How should I go about narrowing down the cause of the error?  I have looked at the stackage comparison page for 5.16 vs 5.17 but didn't see any obvious issues.

Best,

Alex

[Michael Snoyman]

If you provide a little more information on the errors you're seeing, you may get more helpful responses.

--
You received this message because you are subscribed to the Google Groups "Stackage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stackage+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Ghitza]

On Wednesday, May 25, 2016 at 3:47:56 PM UTC+10, Michael Snoyman wrote:

If you provide a little more information on the errors you're seeing, you may get more helpful responses.

Fair enough, although in hindsight stating the question more precisely might have done the trick.  What I meant to ask was this: how can I find out whether there was a change in linker behavior between lts-5.16 and lts-5.17?  I can't figure that out from the comparison page, but maybe I'm not looking at the right thing.

And now, some more information on the errors I was seeing.  Our project depends on a C library.  When I ran stack build in the project with lts-5.16 in stack.yaml, everything was fine.  As soon as I edited stack.yaml and replaced lts-5.16 with lts-5.17 (without making other changes), I got this error at the end of the build:

Linking .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/debug-hlinear/debug-hlinear ...
    /opt/ghitza/hlinear-all/hlinear/.stack-work/install/x86_64-linux/lts-5.17/7.10.3/lib/x86_64-linux-ghc-7.10.3/hflint-0.0.1-5w3Xjs5N6UC5sWbFNGNEZl/libHShflint-0.0.1-5w3Xjs5N6UC5sWbFNGNEZl.a(flint_define_wrappers.o): In function `nmod_inv_wrapper':
    (.text+0x12e): undefined reference to `flint_throw' 
    /opt/ghitza/hlinear-all/hlinear/.stack-work/install/x86_64-linux/lts-5.17/7.10.3/lib/x86_64-linux-ghc-7.10.3/hflint-0.0.1-5w3Xjs5N6UC5sWbFNGNEZl/libHShflint-0.0.1-5w3Xjs5N6UC5sWbFNGNEZl.a(flint_define_wrappers.o): In function `nmod_div_wrapper': 
    (.text+0x182): undefined reference to `flint_throw' 
    collect2: error: ld returned 1 exit status

My best guess is that lts-5.16 and lts-5.17 somehow used different versions of the C library (one where flint_throw exists and another one where it doesn't).  And indeed, I had the correct version of the library installed system-wide (in /usr/lib) and an older version that was lingering in some local directory (/opt/stuff/lib).  As soon as I removed the obsolete version, stack build started working correctly with both lts-5.16 and lts-5.17.

While my problem is temporarily solved, I'm still no wiser as to what caused the change of linking behavior between the two lts-5.*'s.

Best,

Alex

[Michael Snoyman]

I don't know for certain, but my guess is that it wasn't actually an issue with the LTS releases. I'm guessing when you first compiled LTS 5.16, you had the correct version of the library visible to Stack, and it linked its libraries against that. Even when you exposed the incorrect version of the library, you already had the binary artifacts pointing at an absolute path.

On the other hand, when you tried compiling with 5.17, it tried to build from scratch, and grabbed the first version of the library off the search path, which happened to be the wrong one.