Opened 4 years ago

Closed 3 years ago

#8490 closed bug (worksforme)

OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table`

Reported by: jloos Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.6.3
Keywords: Cc: tim@…
Operating System: MacOS X Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


I'm not sure if and how far the ghc-7.6.3 support for OS X is planned, but I hit a (possible) linker error with 7.6.3.

I installed a homebrew gcc-4.8 and changed the ghc config to use it. I tried to compile the bindings-GLFW package, which was successful, and run cabal test on it, which fails with following error:

final link ... ghc:
lookupSymbol failed in relocateSection (relocate external)
dist/build/HSbindings-GLFW-3.0.3.o: unknown symbol `__objc_empty_vtable'
linking extra libraries/objects failed

After some research I discovered that this symbol (surely just the first which fails) is part of the Objective-C Runtime. The /usr/lib/libobjc.dylib exports this symbol.

In desperation I think I nearly reached the google quota with my research, further steps I tried:

Explicitly link the libobjc lib

ghci -lobjc dist/build/HSbindings-GLFW-3.0.3.o -framework Foundation -framework Cocoa -framework IOKit

With the same result as above:

GHCi, version 7.6.3:  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) dist/build/HSbindings-GLFW-3.0.3.o ... done
Loading object (dynamic) /usr/lib/libobjc.dylib ... done
Loading object (framework) IOKit ... done
Loading object (framework) Cocoa ... done
Loading object (framework) Foundation ... done
final link ... ghc:
lookupSymbol failed in relocateSection (relocate external)
dist/build/HSbindings-GLFW-3.0.3.o: unknown symbol `__objc_empty_vtable'
linking extra libraries/objects failed

I found a homebrew issue related to gcc and the Apple switch from libstdc++to libc++ in 10.9 and i tried to force linking with explicit -stdlib=libstdc++ in the cabal file (ld-options). But i guess this issue isn't related to the __objc_*** problem, just tried it in desperation.

Last week I managed to build ghc HEAD with clang bootstrapped with 7.4.6: the new linker mechanic seems to resolves this problem in a way (sadly some other packages aren't jet compatible with 7.8)

So I'm not sure if this report is okay, if not, pardon me :)

I'm aware of the problems with the current ghc-7.6.3 and the the changes OS X 10.9 brings with it (according to reddit/haskell cafe). The current suggestions is to not use the XCode-5.0.1/clang together with ghc-7.6.3. So I tried gcc from homebrew. I know that 7.8 will bring better linker capabilities, maybe there are just some flags to fix this specific problem with 7.6.3...? I didn't find it. So I thought it's better to report it.

If further informations are required, I will try to provide them as fast as possible but I will have to downgrade to 10.8 tomorrow around 6 a.m. UTC.

Attachments (1)

build.log (74.1 KB) - added by jloos 4 years ago.
binding-GLFW -v3 build log

Download all attachments as: .zip

Change History (4)

Changed 4 years ago by jloos

Attachment: build.log added

binding-GLFW -v3 build log

comment:1 Changed 4 years ago by guest

I'm having a similar problem, also on Mac OS X 10.9. Went through pretty much the same process and reached the same lack of conclusions. I've also verified that /usr/lib/libobjc.dylib does indeed contain some symbol __objc_empty_vtable as shown via nm -g, but I cannot get ghc to link to it properly.

Any ideas?

comment:2 Changed 4 years ago by blitzcode

Cc: tim@… added

comment:3 Changed 3 years ago by thomie

Resolution: worksforme
Status: newclosed

Please re-open if this issue still exists in 7.8.3. Unfortunately, there won't be another 7.6 release.

Note: See TracTickets for help on using tickets.