Opened 5 years ago

Last modified 5 years ago

#3354 new bug

binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger)

Reported by: bkomuves Owned by:
Priority: normal Milestone:
Component: Build System Version: 6.10.1
Keywords: Cc:
Operating System: MacOS X Architecture: Unknown/Multiple
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

It seems that binaries (at least those linked with the threaded runtime) built with GHC on Mac OS X 10.5 do not work on Mac OS X 10.4. The error message in my case is

dyld: lazy symbol binding failed: Symbol not found: _pthread_cond_init$UNIX2003
  Referenced from: <the executable>
  Expected in: /usr/lib/libSystem.B.dylib

I believe that the primary reasons for this is that the runtime system is linked against the 10.5 system libraries, which are not ABI compatible with the 10.4 system libraries.

Apple provides both 10.4 and 10.5 SDKs with 10.5, along with compiler and linker options for those who want to build backward-compatible binaries. I tried to pass these options to the linker, which results in the error message

Undefined symbols:
  "_strerror$UNIX2003", referenced from:
      _newThreadLocalKey in libHSrts_thr.a(OSThreads.thr_o)
      _setThreadLocalVar in libHSrts_thr.a(OSThreads.thr_o)
      _freeThreadLocalKey in libHSrts_thr.a(OSThreads.thr_o)
      _my_mmap in libHSrts_thr.a(OSMem.thr_o)
      _rtsSysErrorMsgFn in libHSrts_thr.a(RtsMessages.thr_o)
  "_fputs$UNIX2003", referenced from:
      _heapCensus in libHSrts_thr.a(ProfHeap.thr_o)
  "_read$UNIX2003", referenced from:
      ___hscore_PrelHandle_read in libHSbase-4.0.0.0.a(PrelIOUtils.o)
  "_fcntl$UNIX2003", referenced from:
      _resetNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
      _resetNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
      _setNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
      _setNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
  "_pthread_cond_init$UNIX2003", referenced from:
      _initCondition in libHSrts_thr.a(OSThreads.thr_o)
  "_open$UNIX2003", referenced from:
      ___hscore_open in libHSbase-4.0.0.0.a(PrelIOUtils.o)
  "_kill$UNIX2003", referenced from:
      _shutdownHaskellAndSignal in libHSrts_thr.a(RtsStartup.thr_o)
  "_select$UNIX2003", referenced from:
      _fdReady in libHSbase-4.0.0.0.a(inputReady.o)
  "_write$UNIX2003", referenced from:
      _ioManagerWakeup in libHSrts_thr.a(Signals.thr_o)
      _ioManagerDie in libHSrts_thr.a(Signals.thr_o)
      _generic_handler in libHSrts_thr.a(Signals.thr_o)
      ___hscore_PrelHandle_write in libHSbase-4.0.0.0.a(PrelIOUtils.o)
ld: symbol(s) not found

It would be nice if GHC on OS X shipped with two version of the runtime (and the base library?), and had compiler flags to build compatible binaries. This could be also a problem in the future, with the next OS X versions.

See also this thread: http://lists.apple.com/archives/Darwin-dev/2007/Nov/msg00109.html

Change History (5)

comment:1 Changed 5 years ago by igloo

  • Difficulty set to Unknown
  • Milestone set to _|_

A build on OS X 10.4 presumably does work though, so I don't think that this is a high priority for us. We would happily apply patches to make it work, though.

comment:2 Changed 5 years ago by chak

  • severity changed from major to minor

I have been trying to enable building a compiler on 10.5 that can produce binaries for 10.4 and 10.5. (This is what the deployment target option of ./configure is for.) It is working to some degree, but I never managed to get it to fully boostrap (ie, so that I can build a compiler on 10.5 that also runs on 10.4). It requires a quite a bit of fiddling with linker options and similar and I found it hard to debug when it doesn't work (maybe due to my limited Mac dev experience.

In any case, this is hard to do and really requires somebody with detailed knowledge of the mac os linker. (My changes were in the old build system, not sure how mangled they got in the new one.)

comment:3 Changed 5 years ago by bkomuves

I managed to build binaries on 10.5 which work on 10.4, however the solution was very hackish. In theory it is quite simple, but it needs knowledge about the ghc build system (which I don't have).

What I did was the following: I recompiled the runtime system and the base library with passing the appropriate flags to gcc and the linker. These flags are listed on thread linked above. (I think the Unix library also has to be rebuild, but my program did not depend on it; and maybe some other fundamental libraries, but not many). After this, I have to pass the same flags when building my program, and then it will work on both 10.4 and 10.5 (if I don't pass the flags, it will still work on 10.5).

The build system (this was with ghc 6.10.1, so I think that's the old build system) had in fact some infrastructure in it for doing exactly this, but it seems to be bitrotten, as it worked only for the runtime system, iirc (or maybe I made some mistakes, as I didn't build a full ghc). So I just patched manually various configure files and whatnot, very brute-force, but it worked.

comment:4 Changed 5 years ago by bkomuves

For reference, I think that the relevant flags are:

-mmacosx-version-min=10.4

for the compiler (that is, gcc), and

-syslibroot /Developer/SDKs/MacOSX10.4u.sdk/ 
-macosx_version_min 10.4 
-F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks

for the linker (that is, ld, except when gcc is the linker, too...). Some of these may be superfluous.

comment:5 Changed 5 years ago by chak

Yes, that's what I did, too. Unfortunately, when you use such a compiler to compile GHC itself, then that GHC doesn't work on 10.4. You may want to try that yourself. In other words, this approach does work to some degree, but I couldn't get it to work for all programs (i.e., not for compiling GHC itself, which means other programs probably also break if they use the right features).

Note: See TracTickets for help on using tickets.