Opened 15 months ago

Last modified 5 months ago

#8721 new bug

Testsuite not reporting errors for DYN way on OS X

Reported by: darchon Owned by:
Priority: normal Milestone:
Component: Test Suite Version: 7.6.3
Keywords: dynamic linking Cc:
Operating System: MacOS X Architecture: Unknown/Multiple
Type of failure: Other Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

Using GHC 7.6.3, on OS X 10.8.5, for the program: main = putStrLn "Hello World", compiling with ghc --make -dynamic Main.hs, I get:

~/Documents/devel/test$ ./Main 
dyld: Library not loaded: /usr/local/lib/ghc-7.6.3/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.dylib
  Referenced from: /Users/christiaan/Documents/devel/test/./Main
  Reason: image not found
Trace/BPT trap: 5

The reason for this is that:

  • I installed GHC in: /opt/ghc/7.6.3 instead of the default /usr/local.
  • GHC-bundled libraries get an OS X install_name with a prefix of /usr/local/ instead of /opt/ghc/7.6.3/, meaning that the runtime linker will be looking in the wrong place.

So, I wondered why this bug never showed in the testsuite and decided to test:

/opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ make WAY=dyn TEST=10queens
…
=====> 10queens(dyn) 1834 of 3403 [0, 0, 0]
cd ./programs/10queens && '/opt/ghc/7.6.3/src/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts  -fno-ghci-history --make -o 10queens Main -O -dynamic   >10queens.comp.stderr 2>&1
cd ./programs/10queens && ./10queens    </dev/null >10queens.run.stdout 2>10queens.run.stderr

OVERALL SUMMARY for test run started at Fri Jan 31 09:42:45 CET 2014
    3403 total tests, which gave rise to
   13561 test cases, of which
       0 caused framework failures
   13560 were skipped

       1 expected passes
       0 had missing libraries
       0 expected failures
       0 unexpected passes
       0 unexpected failures

However, when I run the 10queens program myself:

/opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ tests/programs/10queens/10queens 
dyld: Library not loaded: /usr/local/lib/ghc-7.6.3.20130421/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.20130421.dylib
  Referenced from: /opt/ghc/7.6.3/src/ghc/testsuite/tests/programs/10queens/10queens
  Reason: image not found
Trace/BPT trap: 5

I get a similar error as the one reported above.

Due to commit f7be53ac9dac85b83e7fe5ecede01b98a572ba48, these errors will no longer show in GHC 7.8. However, I feel that the testsuite is now giving a false sense of security in terms of dynamic linking. Obviously dynamic linking was broken in 7.6, but the testsuite did not catch it!

Sadly, this behaviour can now only be verified in the 7.6 branch, and not in 7.8 or HEAD.
Hopefully somebody more knowledgeable of the testsuite can comment why dynamic linking worked when an executable was run "within" the testsuite, whilst being broken when run normally.

Change History (3)

comment:1 Changed 15 months ago by darchon

I guess I can answer my own question, the testsuite sets up a correct DYLD_LIBRARY_PATH.
Indeed:

/opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ export DYLD_LIBRARY_PATH=/opt/ghc/7.6.3/src/ghc/libraries/base/dist-install/build/:/opt/ghc/7.6.3/src/ghc/libraries/integer-gmp/dist-install/build/:/opt/ghc/7.6.3/src/ghc/libraries/ghc-prim/dist-install/build/:/opt/ghc/7.6.3/src/ghc/rts/dist/build/; tests/programs/10queens/10queens 
724

runs the executable without problems.

Of course, DYLD_LIBRARY_PATH was never set for executables that ran "outside" of the testsuite.
So in a way, the testsuite and an installed GHC were "misaligned".
Seeing how as of 7.8 the testsuite and an installed GHC are "aligned", I guess the status of this ticket should be turned to either solved or wontfix?

comment:2 Changed 6 months ago by thomie

Due to commit f7be53ac9dac85b83e7fe5ecede01b98a572ba48, these errors will no longer show in GHC 7.8.

darchon:

  • Does that mean we can refrain from setting DYLD_LIBRARY_PATH, and the tests will still work?
  • And if, after doing so, there ever was a regression with respect to that commit, it would then actually get caught?

comment:3 Changed 5 months ago by darchon

No, it does not mean that we can refrain from setting DYLD_LIBRARY_PATH. in f7be53ac9dac85b83e7fe5ecede01b98a572ba48, the rpaths are made relative to the final install location. During testing, the libraries are still in their build locations, so we still need DYLD_LIBRARY_PATH to find the libraries.

Note: See TracTickets for help on using tickets.