Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#10568 closed bug (fixed)

Regression from 7.8.4, loading GLUT into GHCI fails on the Mac

Reported by: George Owned by: darchon
Priority: normal Milestone: 7.10.3
Component: Runtime System (Linker) Version: 7.10.2-rc1
Keywords: Cc: George, trommler
Operating System: MacOS X Architecture: x86_64 (amd64)
Type of failure: GHCi crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D1115
Wiki Page:

Description (last modified by hvr)

$ ghci -V
The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150612

$ ghci -package GLUT
GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/  :? for help
<command line>: can't load .so/.DLL for: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found: _glutBitmap8By13
  Referenced from: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib
  Expected in: flat namespace
 in /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib)

This may be related to the fix for #10322 or the underlying problem reported there. The GLUT people are aware of this. They believe it is platform scpecific, a regression from 7.8.4 and probably a ghc issue. See https://github.com/haskell-opengl/GLUT/issues/19

Change History (49)

comment:1 Changed 4 years ago by George

Description: modified (diff)
Summary: Loading GLUT into GHCI fails on the Mac, probably a regressionRegression from 7.8.4, loading GLUT into GHCI fails on the Mac

comment:2 Changed 4 years ago by trommler

Cc: trommler added

comment:3 Changed 4 years ago by trommler

Status: newinfoneeded

Can you try with HEAD and/or the tip of the 7.10 branch, please.

comment:4 Changed 4 years ago by trommler

Hmm, this issue is different. In #10322 we are linking temporary shared libraries. Here the problem is that the shared library for package GLUT cannot be loaded because of a missing symbol.

Which shared library defines the missing _glutBitmap8By13 ?

Last edited 4 years ago by trommler (previous) (diff)

comment:5 Changed 4 years ago by rwbarton

Right, it's not #10322, but rather #10458.

comment:6 in reply to:  3 Changed 4 years ago by George

Replying to trommler:

Can you try with HEAD and/or the tip of the 7.10 branch, please.

Sorry I can't although what is reported is close to the tip of the branch, i.e. 7.10.1.20150612

comment:7 in reply to:  5 Changed 4 years ago by George

Replying to rwbarton:

Right, it's not #10322, but rather #10458.

Sorry I don't understand how it can be #10458, can you explain? The error I reported

 <command line>: can't load .so/.DLL for: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found: _glutBitmap8By13

 Referenced from: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib
    Expected in: flat namespace

 in /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib)

seeems quite different than the one in #10458:

Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0...
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
/usr/bin/ld: dist/build/etamoo/etamoo-tmp/src/cbits/crypt.o: relocation R_X86_64_PC32 against undefined symbol `crypt' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

In addition #10458 does not mention regression and it is on Linux. This bug is a regression from 7.8.4 and happens on the Mac but not on Linux. From https://github.com/haskell-opengl/GLUT/issues/19:

I checked it under GHC 7.8.4 and ghci -package GLUT works fine (loads the package and shows the prompt).

...

OK, so this seems to be unrelated to TH and to the specific Mac OS X version. Do you have GHC 7.8.3 or 7.8.4 on your Mac to check if this is a GHC 7.10 regression? In the meantime I'll try to get 7.10 running on a Mac, but this might take some time, normally I develop on Windows + Linux only, so some help would be appreciated.

...

The consensus seems to be that this is a GHC 7.8.4 => 7.10.1 regression

Last edited 4 years ago by bgamari (previous) (diff)

comment:8 in reply to:  4 Changed 4 years ago by George

Replying to trommler:

Hmm, this issue is different. In #10322 we are linking temporary shared libraries. Here the problem is that the shared library for package GLUT cannot be loaded because of a missing symbol.

Which shared library defines the missing _glutBitmap8By13 ?

Not sure if this helps but from https://github.com/haskell-opengl/GLUT/issues/19:

tried loading the OSX's GLUT.framework manually: $ ghci -framework GLUT -package GLUT but it produces the same error message.

ghci -framework GLUT -package GLUT
GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/  :? for help
<command line>: can't load .so/.DLL for: /Library/Haskell/ghc-7.10.1.20150612-x86_64  /lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found:  _glutBitmap8By13
Referenced from: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib
 Expected in: flat namespace
in /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib)

To be sure I checked the OSX's GLUT.framework, it does contain the _glutBitmap8By13 symbol.

Last edited 4 years ago by bgamari (previous) (diff)

comment:9 Changed 4 years ago by rwbarton

Sorry, you're right. These error messages are entirely too long :( (Though I don't see anyone claiming on the GLUT thread that it actually works on Linux; but I tested and it does work for me.)

Seems to be a new issue, and may even be cabal's fault since it does the final link itself.

comment:10 in reply to:  4 ; Changed 4 years ago by trommler

Replying to trommler:

Hmm, this issue is different. In #10322 we are linking temporary shared libraries. Here the problem is that the shared library for package GLUT cannot be loaded because of a missing symbol.

Which shared library defines the missing _glutBitmap8By13 ?

On my Linux box glutBitmap8By13 is defined in libglut.so. Could you check if _glutBitmap8By13 is defined in the GLUT framework on Mac OS. Perhaps another Framework defines that symbol and thus needs to be linked too. In Mach-O symbols are not reexported by default (we discussed that in #10322). This is different from ELF.

comment:11 in reply to:  10 Changed 4 years ago by Rydgel

Replying to trommler:

On my Linux box glutBitmap8By13 is defined in libglut.so. Could you check if _glutBitmap8By13 is defined in the GLUT framework on Mac OS. Perhaps another Framework defines that symbol and thus needs to be linked too. In Mach-O symbols are not reexported by default (we discussed that in #10322). This is different from ELF.

It is defined by the GLUT Framework, see:

nm -gU /System/Library/Frameworks/GLUT.framework/Versions/A/GLUT
000000003e01b756 T ___glutGetFCB
000000003e01b7b4 T ___glutSetFCB
000000003e089ea0 S __gle_gc
000000003e02a388 T _gleCreateGC
000000003e027318 T _gleExtrusion
000000003e0271ef T _gleGetJoinStyle
000000003e02733c T _gleGetNumSlices
000000003e0280b2 T _gleHelicoid
000000003e027d1d T _gleLathe
000000003e027656 T _glePolyCone
000000003e02764a T _glePolyCylinder
000000003e0280d4 T _gleScrew
000000003e0271c7 T _gleSetJoinStyle
000000003e027348 T _gleSetNumSlices
000000003e0277d9 T _gleSpiral
000000003e027216 T _gleSuperExtrusion
000000003e02a449 T _gleTextureMode
000000003e0280c3 T _gleToroid
000000003e0276fc T _gleTwistExtrusion
000000003e01751d T _glutAddMenuEntry
000000003e017675 T _glutAddSubMenu
000000003e017816 T _glutAttachMenu
000000003e054480 S _glutBitmap8By13
000000003e056820 S _glutBitmap9By15
000000003e01eb85 T _glutBitmapCharacter
...

comment:12 Changed 4 years ago by trommler

That is strange the symbol is there. Is it possible that libHSGLUT...dylib is not linked against the framework? Could you check?

comment:13 Changed 4 years ago by Rydgel

Disclaimer: I'm not a pro on "linking" subjects but I did use otool (not sure if it's the way to do it properly on os x):

otool -L .cabal-sandbox/lib/x86_64-osx-ghc-7.10.1/GLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh/libHSGLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh-ghc7.10.1.dylib
.cabal-sandbox/lib/x86_64-osx-ghc-7.10.1/GLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh/libHSGLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh-ghc7.10.1.dylib:

@rpath/libHSGLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHScontainers-0.5.6.2-47ajk3tbda43DFWyeF3oHQ-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSOpenGL-2.12.0.1-EpjHCLjhm8PK9gj1WiMLLT-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHStext-1.2.0.4-IINWRW1LxFGIctooOLjJAI-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSbytestring-0.10.6.0-6vj5EoliHgNHISHCVCb069-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSdeepseq-1.4.1.1-FpR4obOZALU1lutWnrBldi-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSStateVar-1.1.0.0-FY7FZJIuVXGGZZi7Rs1xyW-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSstm-2.4.4-877J9sNBpfS5cK4JeYiRK0-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSarray-0.5.1.0-FaHmcBFfuRM8kmZLEY8D5S-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSObjectName-1.1.0.0-Fs9LwEoYTY29YOLwQayVnG-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSGLURaw-1.5.0.1-9IfVeAwyYToLvYIDA0QjxP-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSOpenGLRaw-2.5.0.0-GkhI7NuLynWIs968DbpvQs-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHStransformers-0.4.2.0-ALYlebOVzVI4kxbFX5SGhm-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSbase-4.8.0.0-I5BErHzyOm07EBNpKBEeUv-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

I don't see any reference to GLUT framework though I don't think it is the issue. Let me explain: I checked a similar project with an OpenGL lib that use the Mac OS X OpenGL Framework. He does not show up inside the libHSOpenGLRaw...dylib too, but GHCI is working fine and the bindings work.


I also tried something else: instead of using GLUT as a library for a project, I cloned the project itself and tried to load it up on GHCI. Building seems fine but the result of loading the lib in the repl is the same though the error is slightly different:

cabal repl

Resolving dependencies...
Configuring GLUT-2.7.0.1...
Preprocessing library GLUT-2.7.0.1...
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.1 for x86_64-apple-darwin):
	Loading temp shared object failed: dlopen(/var/folders/gb/2s37knjd0kjg9w40npfwkh0c0000gn/T/ghc92017_0/libghc92017_1.dylib, 5): Symbol not found: _glutBitmap8By13
  Referenced from: /var/folders/gb/2s37knjd0kjg9w40npfwkh0c0000gn/T/ghc92017_0/libghc92017_1.dylib
  Expected in: flat namespace
 in /var/folders/gb/2s37knjd0kjg9w40npfwkh0c0000gn/T/ghc92017_0/libghc92017_1.dylib

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

comment:14 Changed 4 years ago by George

Version: 7.10.17.10.2-rc1

comment:15 Changed 4 years ago by rwbarton

The other issue Rydgel mentions really is #10458, and I can reproduce it on Linux (though the particular offending symbol is different).

I don't understand why that otool output doesn't mention the GLUT framework (or why it lists libHSGLUT itself) or why libHSOpenGLRaw apparently works without its otool output mentioning the OpenGL framework.

Maybe it would help to see the final link command when building the GLUT package though? (cabal build -v)

Last edited 4 years ago by rwbarton (previous) (diff)

comment:16 in reply to:  15 Changed 4 years ago by Rydgel

Replying to rwbarton:

Maybe it would help to see the final link command when building the GLUT package though? (cabal build -v)

Here we go

https://gist.githubusercontent.com/Rydgel/8ad7cb3b50fd98909900/raw/b727b43d00f89d23b425e1458ebc647006c0e2b7/gistfile1.txt

comment:17 Changed 4 years ago by rwbarton

Thanks. Hmm, there is no -framework option at all there, so that's definitely incorrect, no? Maybe Cabal linking against OS X frameworks broke when support for relocatable sandboxes was added?

comment:18 Changed 4 years ago by rwbarton

I'm very puzzled. I can see exactly where in the source Cabal is supposed to add -framework foo options to the link step of ghc, and yet it's not doing so.

Rydgel, what version of Cabal are you using? Would you be able to test with older versions of Cabal and/or GHC to see if they have different behavior (either in terms of being able to load GLUT into ghci, or in terms of the Cabal link command including -framework GLUT)?

comment:19 Changed 4 years ago by Rydgel

This is my current version of cabal

cabal --version
cabal-install version 1.22.6.0
using version 1.22.4.0 of the Cabal library 

This is the full build and the error with GHC 7.10.1 && cabal 1.22.0 https://gist.githubusercontent.com/Rydgel/96ba8626d1e18274502d/raw/0ff07b54915c4283294fa3c7f0e0e308f8ed810b/gistfile1.txt

I installed GHC 7.8.4 && cabal 1.22.0 Here is the full build of the lib https://gist.githubusercontent.com/Rydgel/3d2c1b0555338b210df3/raw/4975551dd5699120130b0505be0d84f20c70a780/gistfile1.txt

Now I tried with GHC 7.8.4 && cabal 1.20 Here is the full build of the lib: https://gist.githubusercontent.com/Rydgel/bf6dc245b410e90828ff/raw/b28d952a2824ed69abe079a853d739d314298a39/gistfile1.txt

So far every configuration failed to load the GLUT project in the cabal repl when building it in a sandbox.


Now this is maybe a related problem with the package not configured to use it with way. So I did some new tests with installing the GLUT package outside a sandbox and try load it with ghci -package GLUT (which was the steps reported first in this page). So far after install (I totally nuked ~/.cabal and ~/.ghc for each steps):

GHC 7.8.4 - Cabal 1.20

ghci -package GLUT
GHCi, version 7.8.4: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package OpenGLRaw-2.5.1.0 ... linking ... done.
Loading package GLURaw-1.5.0.1 ... linking ... done.
Loading package ObjectName-1.1.0.0 ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package stm-2.4.4 ... linking ... done.
Loading package StateVar-1.1.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package binary-0.7.1.0 ... linking ... done.
Loading package text-1.2.1.1 ... linking ... done.
Loading package OpenGL-2.12.0.1 ... linking ... done.
Loading package GLUT-2.7.0.1 ... linking ... done.
Prelude> 

GHC 7.8.4 && Cabal 1.22.0.0

ghci -package GLUT
GHCi, version 7.8.4: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package OpenGLRaw-2.5.1.0 ... linking ... done.
Loading package GLURaw-1.5.0.1 ... linking ... done.
Loading package ObjectName-1.1.0.0 ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package stm-2.4.4 ... linking ... done.
Loading package StateVar-1.1.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package binary-0.7.1.0 ... linking ... done.
Loading package text-1.2.1.1 ... linking ... done.
Loading package OpenGL-2.12.0.1 ... linking ... done.
Loading package GLUT-2.7.0.1 ... linking ... done.
Prelude>

GLUT-2.7.0.1.log

GHC 7.10.1 && Cabal 1.22.0.0

ghci -package GLUT
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
<command line>: can't load .so/.DLL for: /Users/rydgel/.cabal/lib/x86_64-osx-ghc-7.10.1/GLUT_J0mPc7fsMRk1qun4O7kCoA/libHSGLUT-2.7.0.1-Go4T8lnmeY31g3GsnJ9sQu-ghc7.10.1.dylib (dlopen(/Users/rydgel/.cabal/lib/x86_64-osx-ghc-7.10.1/GLUT_J0mPc7fsMRk1qun4O7kCoA/libHSGLUT-2.7.0.1-Go4T8lnmeY31g3GsnJ9sQu-ghc7.10.1.dylib, 5): Symbol not found: _glutBitmap8By13
  Referenced from: /Users/rydgel/.cabal/lib/x86_64-osx-ghc-7.10.1/GLUT_J0mPc7fsMRk1qun4O7kCoA/libHSGLUT-2.7.0.1-Go4T8lnmeY31g3GsnJ9sQu-ghc7.10.1.dylib
  Expected in: flat namespace
 in /Users/rydgel/.cabal/lib/x86_64-osx-ghc-7.10.1/GLUT_J0mPc7fsMRk1qun4O7kCoA/libHSGLUT-2.7.0.1-Go4T8lnmeY31g3GsnJ9sQu-ghc7.10.1.dylib)

GLUT-2.7.0.1.log

I provided the complete logs of the installs too. In all cases above otool didn't showed a link to GLUT framework (for the lib itself). So this tool is maybe useless in our case or the link is done elsewhere.

comment:20 Changed 4 years ago by trommler

I think linking libHSGLUT...dylib without framework GLUT ist just plain wrong. cbits/HsGLUT.c refers to symbols in the GLUT framework so we must link against framework GLUT.

The reason it works with older ghci is that shared libraries were loaded (dlopened) with global scope (see #8935) and another package might have loaded GLUT before.

In conclusion I agree with @rwbarton that we need to fix Cabal so it runs the final link with the appropriate -framework options.

comment:21 Changed 4 years ago by darchon

Note that the following doesn't work:

ghc-7.10.1, cabal-1.22

cabal install GLUT --ghc-options="-framework GLUT" -v --reinstall --jobs=1

GHCi

~$ ghci -package GLUT
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
<command line>: can't load .so/.DLL for: /Users/baaijcpr/.cabal/lib/x86_64-osx-ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1-6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib (dlopen(/Users/baaijcpr/.cabal/lib/x86_64-osx-ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1-6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib, 5): Symbol not found: _glutBitmap8By13
  Referenced from: /Users/baaijcpr/.cabal/lib/x86_64-osx-ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1-6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib
  Expected in: flat namespace
 in /Users/baaijcpr/.cabal/lib/x86_64-osx-ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1-6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib)

But, the following:

cabal install GLUT --ghc-options="-optl-Wl,-framework,GLUT" -v --reinstall --jobs=1

does work:

~$ ghci -package GLUT
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
Prelude> 

Also note:

~$ otool -L /Users/baaijcpr/.cabal/lib/x86_64-osx-ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1-6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib
/Users/baaijcpr/.cabal/lib/x86_64-osx-ghc-7.10.1/GLUT_6oGfBpdyNXm6GXGpRB4gPs/libHSGLUT-2.7.0.1-6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib:
	@rpath/libHSGLUT-2.7.0.1-6oGfBpdyNXm6GXGpRB4gPs-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/GLUT.framework/Versions/A/GLUT (compatibility version 1.0.0, current version 1.0.0)
	@rpath/libHScontainers-0.5.6.2-47ajk3tbda43DFWyeF3oHQ-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSOpenGL-2.12.0.1-9zpp6vKdJq97sstSpFWLwQ-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHStext-1.2.0.3-FuxPCidOMu81GRnNfjdINK-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSbytestring-0.10.6.0-6vj5EoliHgNHISHCVCb069-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSdeepseq-1.4.1.1-FpR4obOZALU1lutWnrBldi-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSStateVar-1.1.0.0-FY7FZJIuVXGGZZi7Rs1xyW-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSstm-2.4.4-877J9sNBpfS5cK4JeYiRK0-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSarray-0.5.1.0-FaHmcBFfuRM8kmZLEY8D5S-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSObjectName-1.1.0.0-Fs9LwEoYTY29YOLwQayVnG-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSGLURaw-1.5.0.1-HqAsclS2A7s8JRekdgFMHg-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSOpenGLRaw-2.5.1.0-IAXjbJksiwTBy6GOuSpVcg-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHStransformers-0.4.2.0-ALYlebOVzVI4kxbFX5SGhm-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSbase-4.8.0.0-I5BErHzyOm07EBNpKBEeUv-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

So my question is, does the -framework flag in GHC work at all?!

comment:22 Changed 4 years ago by rwbarton

darchon, can you add -v to the ghc-options of those two cabal install commands and provide the verbose output of cabal and of ghc?

comment:24 Changed 4 years ago by rwbarton

And what about the output with --ghc-options="-framework GLUT -v"? How does ghc invoke the linker (gcc)?

comment:25 Changed 4 years ago by Rydgel

comment:26 Changed 4 years ago by rwbarton

That's just the command to build one of the individual object files. The command I'm looking for follows *** Linker: and should contain -o dist/build/libHSGLUT-2.5.1.1-ghc7.8.4.so and is very long. (Er, with that filename adjusted to match the actual version of GLUT and ghc you are building of course.)

(Thanks for all your help by the way!)

Last edited 4 years ago by rwbarton (previous) (diff)

comment:28 Changed 4 years ago by rwbarton

OK thanks. I made a little progress in understanding what's going on here.

The -framework option does work when building an executable. See the handling of framework_opts in DriverPipeline.linkBinary'. However building a shared library is done by SysTools.linkDynLib. This function uses ldInputs dflags, which is initially set by ghc's -lfoo flag, to link against ordinary shared libraries, but it does no processing of framework options. So, that would seem to be a bug in ghc.

I still don't understand why Cabal doesn't actually pass ghc -framework GLUT automatically when GLUT.cabal contains frameworks: GLUT. There's code that clearly intends to do so, see https://github.com/ghc/packages-Cabal/blob/master/Cabal/Distribution/Simple/Program/GHC.hs#L348.

I think the reason this all used to work in 7.8 is that Cabal records the fact that the GLUT package needs the GLUT framework in the package registration, and ghci checks this and loads the GLUT framework before loading the GLUT package. However since #8935 that no longer makes the framework visible to the package.

comment:29 Changed 4 years ago by Rydgel

I really think we might have 2 bugs here, 1 in GHC and 1 in Cabal. Can this Cabal bug be related to our problems? https://github.com/haskell/cabal/issues/2689

comment:30 in reply to:  3 Changed 4 years ago by George

Replying to trommler:

Can you try with HEAD and/or the tip of the 7.10 branch, please.

I just built 7.10.2 rc2 which just came out today:

 ghc -V
The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150630
cabal install -j3 GLUT

The problem is still here:

ghci -package GLUT
GHCi, version 7.10.1.20150630: http://www.haskell.org/ghc/  :? for help
<command line>: can't load .so/.DLL for: /Users/gcolpitts/Library/Haskell/ghc-7.10.1.20150630-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-2JXXB99wAF71Fd1Kg3RhIm-ghc7.10.1.20150630.dylib (dlopen(/Users/gcolpitts/Library/Haskell/ghc-7.10.1.20150630-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-2JXXB99wAF71Fd1Kg3RhIm-ghc7.10.1.20150630.dylib, 5): Symbol not found: _glutBitmap8By13
  Referenced from: /Users/gcolpitts/Library/Haskell/ghc-7.10.1.20150630-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-2JXXB99wAF71Fd1Kg3RhIm-ghc7.10.1.20150630.dylib
  Expected in: flat namespace
 in /Users/gcolpitts/Library/Haskell/ghc-7.10.1.20150630-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-2JXXB99wAF71Fd1Kg3RhIm-ghc7.10.1.20150630.dylib)
Last edited 4 years ago by bgamari (previous) (diff)

comment:31 Changed 4 years ago by George

Status: infoneedednew

comment:32 in reply to:  29 Changed 4 years ago by rwbarton

Replying to Rydgel:

Can this Cabal bug be related to our problems? https://github.com/haskell/cabal/issues/2689

Might be, depending on the root cause (is frameworks: OpenAL somehow getting lost, or does Cabal simply not pass the appropriate option to the C preprocessor).

comment:33 Changed 4 years ago by bgamari

Milestone: 7.10.27.10.3

Kicking this off to 7.10.3

comment:34 Changed 4 years ago by hvr

Description: modified (diff)

improve markup in ticket description for readability

comment:35 Changed 4 years ago by MtnViewMark

When building GLUT for HP, should we be adding the following to the cabal install step? Will this fix the issue for the pre-built libs that HP provides?

    --ghc-options="-optl-Wl,-framework,GLUT"

comment:36 in reply to:  35 Changed 4 years ago by darchon

Replying to MtnViewMark:

When building GLUT for HP, should we be adding the following to the cabal install step? Will this fix the issue for the pre-built libs that HP provides?

    --ghc-options="-optl-Wl,-framework,GLUT"

I think so yes. With those options, the GLUT Haskell library is properly linked against the GLUT framework lib.

comment:37 Changed 4 years ago by MtnViewMark

I've added code to HP to build GLUT this way on OS X, and it works. Next release will have it.

comment:38 Changed 4 years ago by George

It's great that Mark has a fix but I'm still not clear on this issue. Are there bugs to be fixed in ghc and/or cabal or was the problem that GLUT was not being built properly? If the former can somebody describe the bugs or are we still investigating this issue?

comment:39 Changed 4 years ago by darchon

For me, the two bugs seem pretty clear:

  • GHC bug: When linking a dynamic library, GHC does not pass the -framework flags to the system linker.
  • Cabal bug: The -framework flags that should be passed to GHC somehow get lost.

comment:40 Changed 4 years ago by bgamari

darchon, aren't these both symptoms of the same Cabal bug? Namely that -framework isn't passed to GHC. It would be great if someone could track down why this is the case.

While I don't believe ​https://github.com/haskell/cabal/issues/2689 is terribly related to the current issue, it would be great if someone could have a look at (or, even better, test) https://github.com/haskell/cabal/pull/2739, which fixes #2689.

comment:41 in reply to:  40 ; Changed 4 years ago by darchon

Replying to bgamari:

darchon, aren't these both symptoms of the same Cabal bug? Namely that -framework isn't passed to GHC. It would be great if someone could track down why this is the case.

I would find that hard to believe... because, as seen in comment:21 and comment:27, passing the --ghc-options="-framework GLUT" options to Cabal still doesn't make GHC pass the -framework flag to the system linker. I would find it extremely hard to believe that Cabal: 1. Parses the content of --ghc-options and 2. then actively deletes/filters the -framework part.

comment:42 in reply to:  41 Changed 4 years ago by bgamari

Replying to darchon:

Replying to bgamari:

darchon, aren't these both symptoms of the same Cabal bug? Namely that -framework isn't passed to GHC. It would be great if someone could track down why this is the case.

I would find that hard to believe... because, as seen in comment:21 and comment:27, passing the --ghc-options="-framework GLUT" options to Cabal still doesn't make GHC pass the -framework flag to the system linker.

Ahh, I had forgotten about this result. Yes, this does sound suspicious. Thanks!

I believe the relevant portion of GHC is DriverPipeline.linkBinary. The framework logic there looks correct but it would be nice if someone with access to OS X could add some traces so we could figure out where things are going awry.

comment:43 Changed 4 years ago by darchon

Differential Rev(s): Phab:D1115
Owner: set to darchon

I've fixed the GHC part in https://phabricator.haskell.org/D1115. The Cabal part remains broken. I think once my patch is merged this issue should be closed, and a new one should be opened on the Cabal bug-tracker.

comment:45 Changed 4 years ago by Ben Gamari <ben@…>

In dd7e1880/ghc:

Add framework flags when linking a dynamic library

This fixes the GHC side of trac #10568. So `cabal install
--ghc-options="-framework GLUT" GLUT` creates a correctly linked
GLUT.dylib. We still need to explictly pass `--ghc-options="-framework
GLUT"` because the Cabal side #10568 is not fixed.

Update: the Cabal side of #10568 is fixed by
[Cabal#2747](https://github.com/haskell/cabal/pull/2747)

Test Plan: validate

Reviewers: austin, rwbarton, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D1115

GHC Trac Issues: #10568

comment:46 Changed 4 years ago by bgamari

Resolution: fixed
Status: newclosed

comment:47 Changed 4 years ago by bgamari

Status: closedmerge

It might be good to have this in 7.10.3 if it comes to fruition.

comment:48 Changed 4 years ago by simonmar

Component: CompilerRuntime System (Linker)

comment:49 Changed 4 years ago by bgamari

Status: mergeclosed

Has been merged to ghc-7.10.

Last edited 4 years ago by bgamari (previous) (diff)
Note: See TracTickets for help on using tickets.