Link against the correct stdlib, fixes #77

[cocreature]

This also includes the fix for linking against LLVM build with Clang. Excluding -Wcovered-switch-default seems pretty safe as this is only a warning and shouldn’t cause any failures when linking.

[bscarlet]

Just the small stuff I've mentioned in line. Otherwise looks good.

[cocreature]

Just the small stuff I've mentioned in line. Otherwise looks good.

Should all be fixed now.

[sebeaumont]

I'm getting test failures on OS X -- however the same works fine on linux toolchain.

seb@psi-4:llvm-general 1028> cabal test
Re-configuring with test suites enabled. If this fails, please run configure
manually.
Resolving dependencies...
Configuring llvm-general-3.8.0.0...
Warning: Instead of 'cc-options:
-I/usr/local/Cellar/llvm38/3.8.0/lib/llvm-3.8/include' use 'include-dirs:
/usr/local/Cellar/llvm38/3.8.0/lib/llvm-3.8/include'
Preprocessing library llvm-general-3.8.0.0...
Preprocessing test suite 'test' for llvm-general-3.8.0.0...
Running 1 test suites...
Test suite test: RUNNING...
Assertion failed: (Val && "isa<> used on a null pointer"), function doit, file /private/tmp/llvm3820160316-8183-11u7j5k/llvm-3.8.0.src/include/llvm/Support/Casting.h, line 95.
Test suite test: FAIL
Test suite logged to: dist/test/llvm-general-3.8.0.0-test.log
0 of 1 test suites (0 of 1 test cases) passed.

[cocreature]

@sebeaumont Is this new behavior with this patch or were you just unable to compile llvm-general before? Either way I’m afraid I can’t really help you since I don’t have a macOS machine to test this on. The way I would proceed is to insert print statements (yeah printf debugging) until I figure out which cast exactly is causing this. Then we can take a look if it makes sense that there is a null pointer there or not.

[sebeaumont]

@cocreature I think this is general (afaik it compiles fine) -- I commented here as I was thinking the patch might be a fix. I can do as you as suggest and insert relevant output -- watch this space.

[cocreature]

@sebeaumont You can also compile with -g assuming you have a new enough GHC (I think 7.10 should be enough). Then you’ll get a backtrace into haskell code. That’s even more helpful if you have an LLVM build with debug info, but even without it, it’s a lot faster than doing pure printf debugging.

[tibbe]

I also get

Assertion failed: (Val && "isa<> used on a null pointer"), function doit, file /private/tmp/llvm3820160316-8183-11u7j5k/llvm-3.8.0.src/include/llvm/Support/Casting.h, line 95.

on OS X in my own app.

[tibbe]

Managed to capture a (short) stack trace:

* thread #1: tid = 0x194565, 0x00007fff9d818f06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff9d818f06 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff8ec7b4ec libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x0000000100e5f237 ruinc`abort + 14
    frame #3: 0x0000000100e5f229 ruinc`__assert_rtn + 81
    frame #4: 0x0000000100d0f504 ruinc`LLVMSetPersonalityFn + 73
    frame #5: 0x00000001000d9169 ruinc`c62vT_info + 33 at Module.hs:319

It looks like the culprit is the call to setPersonalityFn in LLVM.General.Internal.Module. Adding some debugging I can see that that function is called with:

setPersonalityFn: 0x00007f82504068c8 Nothing

Perhaps Nothing converts to a null pointer and that's not OK to pass to the API? Changing the call to

case personality of
  Nothing -> return ()
  p@(Just _) -> setPersonalityFn f p

makes the program run without crashing.

[tibbe]

The LLVM function that is failing on the assert is in Casting.h:

template <typename To, typename From> struct isa_impl_cl<To, const From*> {
  static inline bool doit(const From *Val) {
    assert(Val && "isa<> used on a null pointer");
    return isa_impl<To, From>::doit(*Val);
  }
};

I haven't been able to figure out the whole chain of calls from LLVMSetPersonalityFn to doit.

[bscarlet]

Do you have any reason to believe this issue with LLVMSetPersonalityFn is related to this merge request? If not, please open a separate bug. In any case, please make a test case we can work against.

[cocreature]

@tibbe That error has been fixed in the llvm-3.9 branch. Should be trivial to backport this change.

[tibbe]

See #194.