haskell-mafia / mafia

Provides protection against cabal swindling, robbing, injuring or sabotaging people with chopsticks.
http://haskell-mafia.github.io/mafia/
BSD 3-Clause "New" or "Revised" License
135 stars 19 forks source link

Work around for OSX's broken linker. #226

Closed tmcgilchrist closed 6 years ago

tmcgilchrist commented 6 years ago

All @markhibberd's work.

Needs some testing against borked linking projects.

HuwCampbell commented 6 years ago

I have successfully built a few test suites which weren't working for me before with this.

Not everything seems to work though.

devgrok commented 6 years ago

This doesn't fix the problem when trying to build source/local package dependencies which have a huge dependency set of their own. When added to src/Mafia/Install.hs this works great. (https://github.com/ambiata/mafia/commit/adadb526866382ab22983013549bebed3e8e394a)

FYI: tested on:

macOS Sierra The Glorious Glasgow Haskell Compilation System, version 8.0.2 cabal-install version 1.24.0.2 compiled using version 1.24.2.0 of the Cabal library

Thanks Mark & Tim!

tmcgilchrist commented 6 years ago

@devgrok Grabbed that commit. Is there a particular example project where it fails as you described?

devgrok commented 6 years ago

build blizzard-submit-batch failing when building blizzard-cloud. I'd already created a symlink '~/.mafia->/m/` to try and shorten the paths.

[ 3 of 37] Compiling Blizzard.Repository.Sized ( src/Blizzard/Repository/Sized.hs, dist/dist-sandbox-a49cc23c/build/Blizzard/Repository/Sized.o )
<command line>: can't load .so/.DLL for: /m/packages/2/x86_64-apple-darwin/8.0.2/ambiata-blizzard-cloud-0.0.1-2d3164af129d0d3c6766d5b2f9c56485cc4f4598/lib/x86_64-osx-ghc-8.0.2/libHSambiata-blizzard-cloud-0.0.1-1VoPiGGVam1hXCLhYtPOH-ghc8.0.2.dylib (dlopen(/m/packages/2/x86_64-apple-darwin/8.0.2/ambiata-blizzard-cloud-0.0.1-2d3164af129d0d3c6766d5b2f9c56485cc4f4598/lib/x86_64-osx-ghc-8.0.2/libHSambiata-blizzard-cloud-0.0.1-1VoPiGGVam1hXCLhYtPOH-ghc8.0.2.dylib, 5): no suitable image found.  Did find:
    /m/packages/2/x86_64-apple-darwin/8.0.2/ambiata-blizzard-cloud-0.0.1-2d3164af129d0d3c6766d5b2f9c56485cc4f4598/lib/x86_64-osx-ghc-8.0.2/libHSambiata-blizzard-cloud-0.0.1-1VoPiGGVam1hXCLhYtPOH-ghc8.0.2.dylib: malformed mach-o: load commands size (33232) > 32768)

And here's the output of otool -l: https://gist.github.com/devgrok/6261363966352f77302245ef64592ff5

tmcgilchrist commented 6 years ago

@devgrok Can't see blizzard-submit. The only examples I had were boris and mismi but I suppose anything pulling in mismi is a candidate for failure as well. Could you confirm @HuwCampbell that this change fixes any blizzard build issues and we can merge this.

HuwCampbell commented 6 years ago

I'm still getting issues on larger projects. I think it's a step in the right direction though, as I said, some test suites are now working.

erikd commented 6 years ago

Lets merge this sucker!

HuwCampbell commented 6 years ago

I've seen this patch break a few projects, as the -dead_strip_dylibs flag conflicts with -r. I'll have to refind and example though.

erikd commented 6 years ago

Ok, so maybe not :) . I never use Mac, so this is pretty much irrelevant to me.

tmcgilchrist commented 6 years ago

Managed to break a few projects even with this fix. Investigating other options in either the linker commands or making shorter paths so it doesn't trigger this issue as quickly.

etorreborre commented 6 years ago

@tmcgilchrist Is it possible to integrate something like this: https://github.com/Simspace/ld-wrapper-macos. I've used it in conjunction with stack and solved my issues.

tmcgilchrist commented 6 years ago

Haven’t had any success with that wrapper script. Have you got a repo where that script is setup and working. I started pulling in the fix of using shorter paths that got put into cabal new-build. Hoping that along with the flags fixes the issue properly.

On Fri, 13 Jul 2018 at 8:00 pm, Eric Torreborre notifications@github.com wrote:

@tmcgilchrist https://github.com/tmcgilchrist Is it possible to integrate something like this: https://github.com/Simspace/ld-wrapper-macos. I've used it in conjunction with stack and solved my issues.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/haskell-mafia/mafia/pull/226#issuecomment-404787608, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKbubRMAipZnB2kobTrjieLGEyXW7nkks5uGG_VgaJpZM4Udf9g .

etorreborre commented 6 years ago

Unfortunately I don't have a public repo where I'm using that script. I thought I was doing something with stack in particular but no I am only using the ghc option declared in my hpack file:

when:
  - condition: os(darwin)
    ghc-options:
      - -optl-fuse-ld=ld-wrapper-macos.sh
tmcgilchrist commented 6 years ago

I have been successfully using this branch on problematic Haskell projects with no issues in OSX. The behaviour on Linux stays the same as before.

If any interested people could test this out and report back on any issues encountered with the OSX linker that would be great!

devgrok commented 6 years ago

What was working with your previous version is still working for me. I'll get Huw to check the projects he was having linker option problems with to see if that's improved.

However I'm still getting errors doing mafia test on some of our chunkier projects. even with your latest version and the hack of symlinking ~/.mafia --> /m.

Here's the cabal file and the output of otool -l of the error'ing link file. https://gist.github.com/devgrok/80ce8b8d4d415d7546a7386dc04819ab

The annoying error I get is:

Preprocessing library ambiata-hydra-daemon-0.0.1...
Preprocessing test suite 'test' for ambiata-hydra-daemon-0.0.1...
[1 of 5] Compiling Test.Hydra.Service.Scheduler ( test/Test/Hydra/Service/Scheduler.hs, dist/build/test/test-tmp/Test/Hydra/Service/Scheduler.o )

<no location info>: error:
    ghc: panic! (the 'impossible' happened)
  (GHC version 8.0.2 for x86_64-apple-darwin):
    Dynamic linker not initialised

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Is it simply because the library created for the project is being stored and treated differently for the test (or maybe intra-module dependencies). Or just that being a test, it pulls in more dependencies...?

When i get time i'll get a test proj with open-sourced libraries only.