can't build/install on OSX mojave

[cartazio]

two different issues I think 1) missing include on mac (assumes brew'd fltk has non existent header ..) 2) -fbundled unbuildable on mojave + cli tools

1) i get the following verbose errors with -j1 -v3 on cabal v2-install fltkhs (i'm using cabal 2.4 btw)

==Compiling C bindings==
*** Compiling Fl_Simple_TerminalC.cpp...
In file included from Fl_Simple_TerminalC.cpp:1:
./Fl_Simple_TerminalC.h:8:10: fatal error: 'FL/Fl_Simple_Terminal.H' file not found
#include "FL/Fl_Simple_Terminal.H"
         ^~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make[1]: *** [Fl_Simple_TerminalC.o] Error 1
make: *** [src] Error 2
creating /Users/carter/.cabal/bin
Symlinking fltkhs-buttons
Symlinking fltkhs-fluidtohs
packages definitely up to date:
packages previously probably up to date:

i looked in the applicable brew directory and i dont see it there ..

ls /usr/local/Cellar/fltk/1.3.4-2/include/FL/FL_Simple_
/usr/local/Cellar/fltk/1.3.4-2/include/FL/Fl_Simple_Counter.H  /usr/local/Cellar/fltk/1.3.4-2/include/FL/Fl_Single_Window.H

2) likewise, when i tried building with -fBUndled

i get a HUGE wall of errors

starting with

Compiling Fl_cocoa.mm...
Fl_cocoa.mm:133:47: warning: multi-character character constant [-Wmultichar]
  kTSMDocumentEnabledInputSourcesPropertyTag = 'enis' //  from Carbon/TextServices.h
                                               ^~~~~~
In file included from /usr/include/os/object.h:101:0,
                 from /usr/include/dispatch/dispatch.h:48,
                 from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:20,
                 from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:17,
                 from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:60,
                 from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:19,
                 from /System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:23,
                 from ../FL/mac.H:40,
                 from ../FL/platform.H:41,
                 from Fl_cocoa.mm:39:
/usr/include/objc/NSObject.h:22:4: error: 'instancetype' does not name a type; did you mean '___runetype'?
 - (instancetype)self;
    ^~~~~~~~~~~~
    ___runetype
/usr/include/objc/NSObject.h:36:4: error: 'instancetype' does not name a type; did you mean '___runetype'?
 - (instancetype)retain OBJC_ARC_UNAVAILABLE;
    ^~~~~~~~~~~~
    ___runetype
/usr/include/objc/NSObject.h:38:4: error: 'instancetype' does not name a type; did you mean '___runetype'?
 - (instancetype)autorelease OBJC_ARC_UNAVAILABLE;
    ^~~~~~~~~~~~
    ___runetype
/usr/include/objc/NSObject.h:63:4: error: 'instancetype' does not name a type; did you mean '___runetype'?
 - (instancetype)init
    ^~~~~~~~~~~~
    ___runetype
/usr/include/objc/NSObject.h:69:4: error: 'instancetype' does not name a type; did you mean '___runetype'?
 + (instancetype)new OBJC_SWIFT_UNAVAILABLE("use object initializers instead");
    ^~~~~~~~~~~~
    ___runetype
/usr/include/objc/NSObject.h:70:4: error: 'instancetype' does not name a type; did you mean '___runetype'?
 + (instancetype)allocWithZone:(struct _NSZone *)zone OBJC_SWIFT_UNAVAILABLE("use object initializers instead");
    ^~~~~~~~~~~~
    ___runetype
/usr/include/objc/NSObject.h:71:4: error: 'instancetype' does not name a type; did you mean '___runetype'?
 + (instancetype)alloc OBJC_SWIFT_UNAVAILABLE("use object initializers instead");
    ^~~~~~~~~~~~
    ___runetype
In file included from /usr/include/time.h:67:0,
                 from /usr/include/pthread.h:60,
                 from Fl_cocoa.mm:34:

then theres thousands of lines of other line noise errors

please let me know how i can help ..

[deech]

I tried it with stack on Mojave. I'll install a cabal environment tomorrow and try to reproduce.

Thanks for the report!

[sboosali]

@cartazio fltkhs #includes <Fl_Example> while FLTK seems to install its headers under a subdirectory (at <FL/Fl_Example>).

Can they be located by symlinking the headers and/or adding the .../FL/ subdirectory to an include path?

[sboosali]

For (2), iirc, I've had ObjC errors when gcc either was or was not aliased to OSX's clang, or by a command-line option like -ObjC not being passed. (but take it with a grain of salt, don't want to waste your time on like a red herring).

On Sun, Nov 4, 2018, 15:06 deech <notifications@github.com wrote:

I tried it with stack on Mojave. I'll install a cabal environment tomorrow and try to reproduce.

Thanks for the report!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/90#issuecomment-435717180, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMX9Y_CXB5TlUSAYVbHzWsTN7dkdMks5ur3LZgaJpZM4YNdFi .

[cartazio]

@deech i dont see FL_Examples in my includes path

ls /usr/local/Cellar/fltk/1.3.4-2/include/FL

doesn't have it.

where / what versions of FLTK are you at / how have you installed yours?

[cartazio]

@sboosali interesting ... so if my GCC in path points to a real gcc rather than clang, the current setup for bundled FLTKHS will freak out? frustratingly, i did set my CC to point to /usr/bin/clang ... what else need I set? CXX?

[cartazio]

SUCCESS:

i make it past the .mm error if i not only set CC to /user/bin/clang but also CXX to /usr/bin/clang++

[cartazio]

so the current state of affairs

1) i can't seem to do the install successfully for the system/ brew shared lib flavor (i get the error about not finding FL/Fl_Simple_Terminal.H not being found ... which isn't in the include directory for FLTK that i have anyways ... I checked!)

2) successfully have the -fbundled build flavor installed (with v2-install new build style cabal no less!)

[cartazio]

so it seems like a handy suggestion on OSX for folks with -fembed build failures is to make sure CC and CXX both point to the applicable / apple clang/clang++

that still doesn't track down the issue with the not embedded install :(

[deech]

Awesome that the gcc issue is resolved. Thanks @sboosali! I'll add it to the docs.

The issue you're having with the brew version of FLTK is to be expected. The new fltkhs release tracks the unofficial (but generally stable) version 1.4 version so package managers are unlikely to have it. I have instructions on building it yourself locally in the Hackage docs.

[sboosali]

@cartazio that's great, and good to know about the correct clang++ being required too.

(sorry for the delay, but I should have clarified that by Fl_Example.h, I meant it as an example of the format, i.e. #include <FL/Fl_<File>.h).

On Mon, Nov 5, 2018, 10:09 deech <notifications@github.com wrote:

Awesome that the gcc is resolved. Thanks @sboosali https://github.com/sboosali! I'll add it to the docs.

The issue you're having with the brew version of FLTK is to be expected. The new fltkhs release tracks the unofficial (but generally stable) [1.4] ( http://hackage.haskell.org/package/fltkhs-0.6.0.0/docs/Graphics-UI-FLTK-LowLevel-FLTKHS.html#g:5) version so package managers are unlikely to have it. I have instructions on building it yourself locally in the Hackage docs http://hackage.haskell.org/package/fltkhs-0.6.0.0/docs/Graphics-UI-FLTK-LowLevel-FLTKHS.html#g:12 .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/90#issuecomment-435975683, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMYrm3_JYSf-M06lXAB6Ql4VHoCc1ks5usH7agaJpZM4YNdFi .

[pennychase]

I'm unable build fltkhs, either with the bundled version or the using my own fltk-1.4. With the bundled version it fails to find the fltk-1.4 dynamic library: g++ -L. -dynamiclib -lc -o libfltk.1.4.dylib ... clang: error: no such file or directory: 'Haskell/Courses/typeclasses/Courses/Timepieces/fltkhs-hello-world/.stack-work/install/x86_64-osx/lts-12.26/8.4.4/lib/fltk-bundled/lib/libfltk.1.4.dylib' make[1]: [libfltk.1.4.dylib] Error 1 make: [all] Error 1

When I build it using my own fltk-1.4, it fails to link libfltkc-dyn.dylib: Linking libfltkc-dyn.dylib... clang: error: unknown argument: '-install_name,../c-lib/libfltkc-dyn.dylib' make[1]: [libfltkc-dyn.dylib] Error 1 make: *** [src] Error 2

This is on MacOS 10.5.4 with clang-1001.0.46.4

[pennychase]

I was finally able to build fltkhs using Apple's clang and clang++. The error occurs when linking to build libfltkc-dyn.dylib: clang: error: unknown argument: '-install_name,../c-lib/libfltkc-dyn.dylib'

The problem is c-src/Makefile.in:

ifeq ($(shell uname) , Darwin)
    SHARED_EXT=dylib
    SONAME_FLAGS=-dynamiclib,-install_name

clang doesn't like the comma between dynamiclib and -install_name. Once I removed it, I was able to build fltkhs. I didn't want to put in a pull request because I'm sure what would happen when using real gcc/g++ instead of clang/clang++ (which might require a different test in the Makefile logic).

[mtolly]

I had the same problem as the above comment. However I'm confused because there already isn't a comma in that location in Makefile.in:

ifeq ($(shell uname) , Darwin)
    SHARED_EXT=dylib
    SONAME_FLAGS=-dynamiclib -install_name

I think the issue is that it is missing a -Wl, like the non-Mac version has:

ifeq ($(shell uname) , Darwin)
    SHARED_EXT=dylib
    SONAME_FLAGS=-dynamiclib -Wl,-install_name

This works for me to build. However I should note that loading FLTK in GHCi has never worked for me on Mac (before or after making this edit), because I get:

GHCi, version 8.6.4: http://www.haskell.org/ghc/  :? for help
<command line>: user specified .o/.so/.DLL could not be loaded (dlopen(libfltkc.dylib, 5): image not found)
Whilst trying to load:  (dynamic) fltkc
Additional directories searched:   /usr/local/lib

Does the -Wl, addition look correct?