RE: [fltk.general] Xcode 7. fltk-1.3.3. Undefined symbols and clang error. [General Use]

[MacArthur, Ian (Leonardo, UK)]

> I get these errors:

> Undefined symbols for architecture x86_64:
> "Fl::run()", referenced from:
> _main in main.o
> "Fl_Box::Fl_Box(int, int, int, int, char const*)", referenced from:
> _main in main.o
> "Fl_Widget::~Fl_Widget()", referenced from:
> Fl_Box::~Fl_Box() in main.o
> "Fl_Window::show()", referenced from:
> _main in main.o
> "Fl_Window::Fl_Window(int, int, char const*)", referenced from:
> _main in main.o
> "Fl_Window::~Fl_Window()", referenced from:
> _main in main.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)

You need to show us the configuration that you used to compile / link this code... Were you doing this inside of Xcode, or at the command line?

I'm inferring, from your wording, that you are in the Xcode IDE when this occurs?


> If I do not run the code inside the main function the program does not
> complain, so I assume it is finding the included libraries correctly.

I don't think so. It doesn't look to have resolved any of the fltk symbols at link time, so I’d infer that you have not linked your code against the fltk lib.

> I have searched around and from what I have read it seems I am compiling
> using gcc instead of g++.

Well, you should be using the C++ compiler personality rather than the C compiler personality for this, that's true, but I do not think that's the crux of the problem here.


> I am not sure where that should happen
> exactly. Is that in Xcode?

If you are building this as an Xcode project, then the project settings (I don’t know which in Xcode 7...) would do this.
If you are compiling at the command line, then...


> Is that when I run "make" and "make install"
> commands? Does anybody has a clue as to what should I do to fix this
> issue? Any help is welcome, this is all quite confusing to me.

It very much looks as if your code has (probably) compiled correctly, but during the linker phase you have not told the tools that they need to incorporate the fltk libs into the build.

Probably you need to add (at least) libfltk.a to the linker command line, possible others.



If you built the fltk libs with the configure script (it seems that you did) then a "fltk-config" script ought to have been generated as part of that process.

So, from a shell, in the fltk build dir, try:

fltk-config --ldstaticflags

And see what libraries it suggests you use.

Also, note that if you are only building a single-file project, then at the command line all you need to do is:

fltk-config --compile my_file.cxx

And it will sort all that stuff out for you.




Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Irving]

Hello, Ian. Thanks for your reply.

You need to show us the configuration that you used to compile / link this code... Were you doing this inside of Xcode, or at the command line?  

I'm inferring, from your wording, that you are in the Xcode IDE when this occurs?  

 

Sorry about the misunderstanding. 

I am using Xcode 7 to compile the program on El Capitan 10.11.6. Before that, I used the command line to build the library by going into the fltk-1.3.3 folder and prompting ./configure, then make, and then make install. 

Not entirely sure which configuration to show. There are a lot of things in Xcode that I really don't understand. But basically, in Xcode, those settings are adjusted in Header Search Paths and Library Search Paths

> If I do not run the code inside the main function the program does not
> complain, so I assume it is finding the included libraries correctly.

I don't think so. It doesn't look to have resolved any of the fltk symbols at link time, so I’d infer that you have not linked your code against the fltk lib. 

 

 

> I am not sure where that should happen

> exactly. Is that in Xcode? 

 

If you are building this as an Xcode project, then the project settings (I don’t know which in Xcode 7...) would do this.
If you are compiling at the command line, then...

Ok, I added libfltk.a to Link With Binary Libraries, the setting which is on the Build Phases tab of my project. The errors (so far) are gone except for the last one, which is this one:

ld: library not found for -lfltk

clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any idea what is this about and why? Is it the same issue you mention when you say:

It very much looks as if your code has (probably) compiled correctly, but during the linker phase you have not told the tools that they need to incorporate the fltk libs into the build.

 

Probably you need to add (at least) libfltk.a to the linker command line, possible others.

There are indeed other files, which I have added in case I need for other projects. They seem to work fine, except for the error I mentioned.

If you built the fltk libs with the configure script (it seems that you did) then a "fltk-config" script ought to have been generated as part of that process.

So, from a shell, in the fltk build dir, try:

   fltk-config --ldstaticflags

And see what libraries it suggests you use. 

This is returned when I run --ldstaticflags: 

/usr/local/lib/libfltk.a -lpthread -framework Cocoa

What should I do with these though? I am not sure what link against static FLTK library means. Either way I added the Cocoa framework in the meantime.

 

Also, note that if you are only building a single-file project, then at the command line all you need to do is:

    fltk-config --compile my_file.cxx

And it will sort all that stuff out for you.

This seems to work fine for a single file. Not sure how would it work if I use another file, which I would have to do when adding the std_lib_facilities.h for some other projects. This is the entry:

Macintosh:ch2_3 irvingangulo$ fltk-config --compile main.cpp

g++ -I/usr/local/include -I/usr/local/include/FL/images -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -o 'main' 'main.cpp' /usr/local/lib/libfltk.a -lpthread -framework Cocoa

Creating 'main.app' bundle for desktop...

It does seem to use the same things it returned when I ran --ldstaticflags. What does -lpthread means/does?

Sorry if it is all to messy, will try to improve as I keep asking.

Thanks a lot!

Irving.

[Ian MacArthur]

On Mon Sep 12 2016 23:28:34, Irving wrote:
>
>
> Ok, I added libfltk.a to Link With Binary Libraries, the setting which is on the Build Phases tab of my project. The errors (so far) are gone except for the last one, which is this one:
>
> ld: library not found for -lfltk
>
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>
>
>
> Any idea what is this about and why?

OK, that form “-lfltk” is linker shorthand for “find the most appropriate libfltk and link against it”.

The linker will then search all of the linker paths it has been given on invocation (using the format -L”/path/to/some/libs” and note the capital “L” there, that makes a difference!) then it will search through a set of “built-in” paths that are configured into the linker.

It looks first for dynamic libs (libfltk.dylib on OSX) then for static libs (libfltk.a) though I always prefer to use fltk statically linked myself!

So anyway, what that error message means is that the compiler looked in the paths it knows about, for a file called either libfltk.dylib or libfltk.a and did not find anything it liked.

I’d speculate that the linker paths (-L”/something...") are set wrong in your case.

However, I’d advocate for static linking the fltk lib anyway, so it might be better just to find out exactly where libfltk.a is on your system (and linking statically against the version in the fltk build that you did id a perfectly valid option in this case.)

So instead, put the full path, like /full/path/to/build/libs/libfltk.a on the link command and that should be resolved and then resolve all your missed symbols.



Anyway, I see now Greg’s posted some tips too, so hopefully what we’ve said will make some sort of sense isn’t too confusing (and Greg and I haven’t contradicted each other too badly!)

What’s your programming background? These questions perhaps hint that you are just finding your feet with this stuff? If your background is with scripting or interpreted languages, then the whole compiler/linker business can certainly be confusing and seem unnecessarily complex until you get to grips with it!
It does pay off if you stick with it though!

[Irving]

Hello Ian, 

Thanks again for your replies.

Yes, my background is mostly on scripting and interpreted languages. Some openFrameworks (C++), JavaScript, SuperCollider, and Max/Msp. Mostly they work out of the box, and the whole compiler/linker thing is abstracted. The whole thing is very confusing to me. Are there any good sources you could suggest to learn a bit more on the subject?

I believe what you and Greg have said goes along the same lines, but it is really all very confusing to me. Especially dealing with Xcode's environment, that has all that stuff in it. I think in the meantime I will keep either using fltk in the command line or using one of the templates for Xcode that comes with FLTK. I would love though to be able to figure the whole thing out and understand what is going on, it really eludes me.

Thanks again!

Irving.

[Greg Ercolano]

On 09/13/16 08:16, Irving wrote:
> I believe what you and Greg have said goes along the same lines, but it is really all very confusing to me. Especially dealing with Xcode's environment, that has all that stuff in it. I think in the meantime I will keep either using fltk in the command line or using one of the templates for Xcode that comes with FLTK. I would love though to be able to figure the whole thing out and understand what is going on, it really eludes me.

If you're new to C++, you might want to look into some tutorials on using C++ in Xcode.

In general, compiled programs go through these steps to turn your code into an executable
(the IDE often hides this whole concept from you):

Your foo.h file ___\ compiler ____\ foo.o ____\ linker ____\ foo
+ / (g++, clang) / (object file) / (ld) / (executable)
Your foo.cxx file

So basically the compiler turns your code into a object file, and the linker joins
that object file with the system libraries (C library, C++ library, etc)

That's fine when you're writing your own program that is more or less self contained;
the compiler knows how to find its default libraries (C/C++ libs)

But when you want your program to make use of /other/ libraries, like FLTK, then you
need to tell the compiler (1) where to find the library's .h files that your program will be #include'ing,
and (2) where to find the library files which contain the library's executable data (many .o (object) files
packaged up into a .a file)

So then the above becomes:

Your foo.h file ______\ compiler ____\ foo.o _____\ linker ____\ foo
+ / / (g++, clang) / (object file) / / (ld) / (executable)
Your foo.cxx file / /
/ /
fltk headers fltk libs
(FL/Fl.H, FL/Fl_Window.H..) (fltk.a, fltk_images.a, etc)

Really the FLTK library is just like your app; it has .h and .cxx files. The .cxx files are already
compiled into .o files, and all its .o files are packaged up into a "library", or .a file, so that the
linker just needs to link it into your app.

Hope that helps.

[Duncan Gibson]

Irving wrote:
> Yes, my background is mostly on scripting and interpreted languages.
> Some openFrameworks (C++), JavaScript, SuperCollider, and Max/Msp.
> Mostly they work out of the box, and the whole compiler/linker thing
> is abstracted. The whole thing is very confusing to me. Are there any
> good sources you could suggest to learn a bit more on the subject?

If your priority is learning FLTK to create a GUI, you might want
to look at: http://pyfltk.sourceforge.net/ although I've never used
it and can't vouch for how complete it is. And you might have just
as much fun setting up a suitable Python environment as using Xcode.

I have used https://www.jetbrains.com/pycharm/ on MacOS for some
non-GUI work, but it took some time to set up the Python environment

If you are trying to learn C++ then you might be better off with
a simpler, non-GUI approach to start with (Accelerated C++, Koenig?).
The event driven programming needed for a GUI or a real-time system
complicates the number of ways that control flows through the program.

D.

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

[Manolo]

To work with FLTK and Xcode, it is possible to use the attached small Xcode project as follows :

1) put the compressed, attached  file in the ....... fltk-1.3.3/ide/Xcode4 directory,
and decompress it (just double click will do it).
At this point FLTK.xcodeproj and FLTKproject.xcodeproj both sit in the same directory

2) build FLTK using Xcode:  open FLTK.xcodeproj, select Fluid, the first of the long list
of targets of this project, and build.

3) open FLTKproject.xcodeproj and build and/or run.
The resulting FLTK application will be found in fltk-1.3.3/ide/Xcode4/build/Debug under the name FLTKapp
and is self-contained.

It is possible to replace main.cxx by another source file, and to add more files to build a bigger FLTK-based app
using FLTKproject.xcodeproj.

[MacArthur, Ian (Leonardo, UK)]

Good tips there.


Also, if the OP is interested in leveraging fltk-config (which they indicated they may be) then there's a HowTo for that here:

http://www.fltk.org/articles.php?L599


Which describes how to use fltk-config in a Makefile to build a multi-file project in a reasonably portable cross-platform fashion.

[Manolo]

On Wednesday, 14 September 2016 11:29:33 UTC+2, Manolo wrote:

To work with FLTK and Xcode, it is possible to use the attached small Xcode project as follows :

.......

It is possible to replace main.cxx by another source file, and to add more files to build a bigger FLTK-based app
using FLTKproject.xcodeproj.

One piece is missing from the previous post, the main.cxx source file, attached here,
and to be put in the same directory as FLTKproject.xcodeproj.

[Duncan Gibson]

I wrote:

> If your priority is learning FLTK to create a GUI, you might want
> to look at: http://pyfltk.sourceforge.net/ although I've never used
> it and can't vouch for how complete it is. And you might have just
> as much fun setting up a suitable Python environment as using Xcode.

Maybe I should have checked my dusty memory before suggesting pyfltk
because you would still need to install FLTK from source in order to
be able to call it from Python via SWIG. So pyFLTK is probably not
going to save you from learning about compiling C++ on MaxOS...

Sorry

[Greg Ercolano]

On 09/14/16 06:19, Duncan Gibson wrote:
> I wrote:
>
>> If your priority is learning FLTK to create a GUI, you might want
>> to look at: http://pyfltk.sourceforge.net/ although I've never used
>> it and can't vouch for how complete it is. And you might have just
>> as much fun setting up a suitable Python environment as using Xcode.
>
> Maybe I should have checked my dusty memory before suggesting pyfltk
> because you would still need to install FLTK from source in order to
> be able to call it from Python via SWIG. So pyFLTK is probably not
> going to save you from learning about compiling C++ on MaxOS...

I think he built FLTK ok, he was just having trouble linking
in his app.

To someone who prefers writing scripts, getting Python + FLTK
might really be worth it, because then you could sail along
writing apps in a language you're already familiar with.

And probably someone can package up pyFLTK in a way that you
don't have to build it, just install the python FLTK module
that would come with precompiled dyld's.

Although I'm a long time C/C++ programmer, I do very much
like working in python, and it's definitely great to be
able to open up GUIs from scripting languages.

[Irving]

Thanks for your reply, Duncan. 

I am trying to follow Stroustrup's PPP2. It is really the reason why I am trying to get FLTK. Other than that, FLTK library is completely alien to me, I will have to go on to see what Dr. S. comes up with.

Why would you choose Accelerated C++ over PPP2? The question is out of topic, I am just trying to get a sense of the book. I considered as well C++ Primer, but in the end I liked the focus on learning the basics of programming rather than the basics of the language, and also cause Dr. S.

[Irving]

Hello, Manolo. 

Thanks for writing.

On Wednesday, September 14, 2016 at 5:29:33 AM UTC-4, Manolo wrote:

To work with FLTK and Xcode, it is possible to use the attached small Xcode project as follows :

1) put the compressed, attached  file in the ....... fltk-1.3.3/ide/Xcode4 directory,
and decompress it (just double click will do it).
At this point FLTK.xcodeproj and FLTKproject.xcodeproj both sit in the same directory

 

2) build FLTK using Xcode:  open FLTK.xcodeproj, select Fluid, the first of the long list
of targets of this project, and build.

Did 1 and 2. Test projects in Xcode 4 build and run well. 

 

3) open FLTKproject.xcodeproj and build and/or run.
The resulting FLTK application will be found in fltk-1.3.3/ide/Xcode4/build/Debug under the name FLTKapp
and is self-contained.

FLTKproject.xcodeproject does not build. I am attaching the pictures of both my Xcode 4 root and from FLTKproject's result so you get sense of what is going on. Basically, I see no main.cxx at the root level, and none of the fltk frameworks are found...

It is possible to replace main.cxx by another source file, and to add more files to build a bigger FLTK-based app
using FLTKproject.xcodeproj.

Should I add the file? how about the frameworks? What is the correct way of linking to those?

Thanks a lot!

[Irving]

Thanks, Ian. I will look slowly at it and try to make sense out if it. I will let you know if any questions arise.

It does seem simpler at the moment to use the command line, and probably a better foundation for understanding how other things (e.g. IDEs) work. 

[Irving]

lol

Great! and I realize I did not attach the pictures. I think I sent you a messy message. I am attaching here the picture of the error now. Sorry about the huge pic not sure if making it just large will work fine. Please also see on the next pic that none of the frameworks are found.

 

[Irving]

Well, I am really trying to follow Stroustrup's directions on the book, not sure where he is going from there. I need more programming chops before I can make decent use of the GUIs on my own. Hopefully the next steps in the book aren't as painful.

Again, thanks a lot for your comments, they are very helpful!

[Duncan Gibson]

Irving wrote:

> I am trying to follow Stroustrup's PPP2. It is really the reason why
> I am trying to get FLTK. Other than that, FLTK library is completely
> alien to me, I will have to go on to see what Dr. S. comes up with.
>
> Why would you choose Accelerated C++ over PPP2? The question is out
> of topic, I am just trying to get a sense of the book. I considered
> as well C++ Primer, but in the end I liked the focus on learning the
> basics of programming rather than the basics of the language, and
> also cause Dr. S.

I started with C back in 1983, and C++ more than 20 years ago, and
haven't kept up with the latest books that introduce C/C++ so I don't
know the details of Stroustrup's PPP2.

Many programming language books concentrate on the syntax/features of
the language rather than on the use of the language and this can be a
big stumbling block for people who are not already programmers and
proficient in another language. And many C++ books start by teaching
the low-level details of C and then try to bolt on the C++ part with
no real explanation of the object oriented programming concepts.

Koenig's Accelerated C++ takes a slightly different approach and sets
out to solve some simple programming problems in a top-down fashion,
addressing the problem first and how the language can help. It's not
huge on the object oriented programming part, IIRC, but it's been a
long time since I read it.

Robert C. Martin's Designing Object Oriented C++ Applications using
the Booch method is probably better for that, but it's a bit dated
since Booch has been replaced by UML. His ten(?) principles for OO
design turn a lot of basic programming ideas on their heads and are
likely to confuse new programmers completely but well worth a read.

If you are happy with Stroustrup then I wouldn't go out of my way
to buy Koenig's book, but it might be interesting if you can borrow
it from a colleague or the library.

[Manolo]

Using the small Xcode project - continued

I forgot I use a non standard Xcode setting. To fix that, please do:
- open "Preferences…" in the Xcode menu
- select "Locations", the rightmost item in the top panel of the preferences window
- click "Advanced…"
- select "Legacy"
- close the preferences window
- build again FLTK.xcodeproj. You should now find
.....fltk-1.3.3/ide/Xcode4/build/Debug/fltk*.framework
- build again FLTKproject.xcodeproj

With its default settings, Xcode puts all its output somewhere in $HOME/Library/Developer/Xcode/,
and $HOME/Library/ is by default a hidden folder. That is why I preferred to change this setting.

[MacArthur, Ian (Leonardo, UK)]

> I am trying to follow Stroustrup's PPP2. It is really the reason why I
> am trying to get FLTK. Other than that, FLTK library is completely alien
> to me, I will have to go on to see what Dr. S. comes up with.

OK - though I'd caution that Dr.S.'s use of fltk is somewhat, um, shall we say "idiosyncratic" in this book?

In particular, there are several things he does in his GUI wrapper framework that are rather contrary to what would be considered "normal" fltk usage.

It's been a while since I looked in detail, but if you are using the code samples from the website, you should probably be aware that the GUI framework has a "feature" (perhaps one might even say a bug) that makes it unreliable on a fast, multi-core OSX machine (pretty much any current OSX machine falls into that category!)

In his Simple_window::wait_for_button() method, where he wants to hold a window open (ignoring the window close button) then, instead of doing the "normal" fltk thing of catching and ignoring the window default callback (which is described in the fltk docs) instead he just spins in a loop calling redraw().

This may well have worked on older, slower, machines, but on modern machines it seems to be prone to some sort of deadlock.
It's a poor implementation choice, so do not be tempted to do the same in your own code, and if you get into difficulties running his examples, be aware that it might not be your fault!

Have fun, and I hope the learning experience goes well!

[Irving]

But, will this setting also change the rest of my projects? I ask because I have other projects running in Xcode that I wouldn't want to be affected by a change in the preferences.

Thank you! 

[Irving]

On Friday, September 16, 2016 at 5:32:26 AM UTC-4, MacArthur, Ian (Leonardo, UK) wrote:

> I am trying to follow Stroustrup's PPP2. It is really the reason why I
> am trying to get FLTK. Other than that, FLTK library is completely alien
> to me, I will have to go on to see what Dr. S. comes up with.


OK - though I'd caution that Dr.S.'s use of fltk is somewhat, um, shall we say "idiosyncratic" in this book?

In particular, there are several things he does in his GUI wrapper framework that are rather contrary to what would be considered "normal" fltk usage.

It's been a while since I looked in detail, but if you are using the code samples from the website, you should probably be aware that the GUI framework has a "feature" (perhaps one might even say a bug) that makes it unreliable on a fast, multi-core OSX machine (pretty much any current OSX machine falls into that category!)

In his Simple_window::wait_for_button() method, where he wants to hold a window open (ignoring the window close button) then, instead of doing the "normal" fltk thing of catching and ignoring the window default callback (which is described in the fltk docs) instead he just spins in a loop calling redraw().

This may well have worked on older, slower, machines, but on modern machines it seems to be prone to some sort of deadlock.
It's a poor implementation choice, so do not be tempted to do the same in your own code, and if you get into difficulties running his examples, be aware that it might not be your fault!

Have fun, and I hope the learning experience goes well!

Ok, I will keep an aye on that example. Hopefully not too many go crazy, they might be hard to spot.

Thanks, Ian! 

[Irving]

Actually, I solved it for the FLTKproject.xcodeproject by adding the frameworks manually.

-I went to FLTKproject settings, and on the Targets selected the FLTKapp.  

-Under general, I get the 'Embedded Binaries' option (which I don't get in my own project for some reason), and there added the frameworks with the option 'Create Groups' and 'Copy items in needed', it wouldn't work otherwise. 

-I then deleted the references to the frameworks that were there before (they showed in red).

The issue though is that now everything is at root level, but it builds well, it is good enough for me. 

On Thursday, September 15, 2016 at 3:34:24 AM UTC-4, Manolo wrote:

[Duncan Gibson]

I wrote:
> > Maybe I should have checked my dusty memory before suggesting pyfltk
> > because you would still need to install FLTK from source in order to
> > be able to call it from Python via SWIG. So pyFLTK is probably not
> > going to save you from learning about compiling C++ on MaxOS...

Greg replied:

> And probably someone can package up pyFLTK in a way that you
> don't have to build it, just install the python FLTK module
> that would come with precompiled dyld's.

Summary: (1) FLTK and Xcode, (2) pyfltk, (3) Stroustrup's PPP2

I've been studying for a BEng with the Open University in the UK for
the past few years, which is one reason I haven't been so active here.
I've had to use Windows to run the software supplied with the course,
and made the mistake of updating the slow laptop to Windows 10 which
means it would be completely unusable when it was updating itself and
there isn't anything the user can do about it. With just the project
report left to go, I bought myself a Macbook, but as a consumer and
not a programmer. The project report was submitted last week so...

Bearing in mind that I'm a complete MacOS programming noob...

I downloaded Xcode this weekend, and fltk-1.3.3 and the fltk-1.3 svn.
It took some fiddling around, because the README.OSX.txt assumes that
you know what you are doing :-) but by copying configure.sh from 1.3.3
into fltk-1.3 svn, and adding an empty abi_version.h I was able to
build fltk-1.3 svn from the command line, but I didn't install it.
I wasn't able to build 1.3.3 but didn't spend any time on it yet.

I found an interesting blog post by Hiltmon[*] about converting Linux
makefile projects to Xcode and was able to set up a non-FLTK project
that would compile and run via makefile and Xcode. While I could get
an FLTK project to build and run via Makefile, I got loads of errors
when running in Xcode. And there are also hundreds of documentation
warnings. I presume this is because I'm mixing build systems. I will
be trying again over the next few evenings, time permitting.

I was expecting Xcode to be much more intuitive and user friendly
but I struggled with the context sensitive preference panels to
find where to set shared include/library paths, etc.

One of Hiltmon's blog posts reminded me about Homebrew, and then I
saw that I could have installed FLTK via Homebrew, but I haven't
tried it yet. Does anyone have any experience of using it? Is it
likely to solve the potential mismatch build problem?

I installed Python via Anaconda because I needed numpy to process
the results for my report, and numpy would need to be built from
scratch otherwise, and I have little knowledge of Mac programming.
Unfortunately pyfltk isn't available via Anaconda :-(

Finally, I found http://www.stroustrup.com/programming_ch12.pdf
which is the chapter of Stroustrup's PPP2 dealing with graphics.
Section 12.4 "Using a GUI library" would suggest that GUI layer
is used to abstract details of the actual toolkit being used:

"The GUI toolkit that we are using (indirectly for now) is called
FLTK (Fast Light Tool Kit, pronounced “full tick”) from www.fltk.org.
Our code is portable wherever FLTK is used (Windows, Unix, Mac, Linux,
etc.). Our interface classes can also be re-implemented using other
toolkits, so code using them is potentially even more portable."

Therefore it's probably not surprising that his abstraction layer
doesn't quite follow the standard fltk idioms.

D.

[*]
http://hiltmon.com/blog/2015/08/01/simple-c-plus-plus-from-makefiles-to-xcode-builds/

[MacArthur, Ian (Leonardo, UK)]

> I downloaded Xcode this weekend, and fltk-1.3.3 and the fltk-1.3 svn.
> It took some fiddling around, because the README.OSX.txt assumes that
> you know what you are doing :-) but by copying configure.sh from 1.3.3
> into fltk-1.3 svn, and adding an empty abi_version.h I was able to
> build fltk-1.3 svn from the command line, but I didn't install it.
> I wasn't able to build 1.3.3 but didn't spend any time on it yet.

When you do the Xcode installation, there are (IIRC!) checkboxes for adding in "posix subsystems" or something - you need to get that stuff too, as it makes later steps easier!
I assume you did, though.

> I was expecting Xcode to be much more intuitive and user friendly
> but I struggled with the context sensitive preference panels to
> find where to set shared include/library paths, etc.

Yes, I never got to grips with the Xcode way.
Makefiles (and sometimes Cmake) and Sublime2 seems to work well enough for my needs on OSX!


FWIW, once you have Xcode and its "posix extras" installed, much of what you need is actually on the OSX machine.

Unfortunately, Apple seem to have chosen to puts all sorts of useful bits in odd "non-standard" places, so some searching (using "locate" or otherwise) for the bits you need, then dicking about with PATH variables, is often necessary to get stuff working as you'd expect at the shell.

Once that's done (how? not as easy as it should be!) then the autoconf stuff Just Works for a stock svn checkout and everything builds fine.
By default though, the autoconf stuff is *not* in the shell PATH (in my experience at any rate) and that is a Bad Thing.

> One of Hiltmon's blog posts reminded me about Homebrew, and then I
> saw that I could have installed FLTK via Homebrew, but I haven't
> tried it yet. Does anyone have any experience of using it? Is it
> likely to solve the potential mismatch build problem?

I had Homebrew on one of my machines, but this was a while ago (years) and ended up getting into a mess, because it clashed badly with some stuff I had to add "manually" and the whole thing ended very badly... I don't use it any more, though others seem to like it, and by all accounts it has got better along the way too.

I never used it to get fltk though.

> Finally, I found http://www.stroustrup.com/programming_ch12.pdf
> which is the chapter of Stroustrup's PPP2 dealing with graphics.
> Section 12.4 "Using a GUI library" would suggest that GUI layer
> is used to abstract details of the actual toolkit being used:
>
> "The GUI toolkit that we are using (indirectly for now) is called
> FLTK (Fast Light Tool Kit, pronounced “full tick”) from www.fltk.org.
> Our code is portable wherever FLTK is used (Windows, Unix, Mac,
> Linux,
> etc.). Our interface classes can also be re-implemented using other
> toolkits, so code using them is potentially even more portable."
>
> Therefore it's probably not surprising that his abstraction layer
> doesn't quite follow the standard fltk idioms.

It wasn't his abstraction layer I was concerned about, however. Rather, his implementation of that abstraction (his GUI framework) which is the "raw" fltk code, is somewhat at odds with what we might consider idiomatic fltk usage...

[Duncan Gibson]

I wrote:
> > I downloaded Xcode this weekend, and fltk-1.3.3 and the fltk-1.3
> > svn. It took some fiddling around, because the README.OSX.txt
> > assumes that you know what you are doing :-) but by copying
> > configure.sh from 1.3.3 into fltk-1.3 svn, and adding an empty
> > abi_version.h I was able to build fltk-1.3 svn from the command
> > line, but I didn't install it. I wasn't able to build 1.3.3 but
> > didn't spend any time on it yet.

Ian replied:

> When you do the Xcode installation, there are (IIRC!) checkboxes for
> adding in "posix subsystems" or something - you need to get that
> stuff too, as it makes later steps easier! I assume you did, though.

No, I didn't see, or must have missed, any additional posix options,
so the problems described below might relate to that...

I'm on MacOS 10.11.6, and downloaded Xcode ?.? last week.

If I start Xcode and open .../fltk-1.3.3/ide/Xcode4/FLTK.xcodeproj
and follow the instructions in README.OSX.txt then Demo won't build.
In fl_line_style.cxx > [M] Fl_Graphics_Driver::line_style(...)
static enum CGLineCap Cap[4] =...
Elaborated type refers to a typedef

If instead I open the latest fltk-1.3.x from svn (11951?) I can get
Demo to build, but then Run Demo says:
My Macbook Pro cannot run Demo
My Macbook Pro runs MacOS 10.11.6 which is lower than Demo's
minimum deployment target. Change your project's minimum
deployment target or upgrade My Macbook Pro's version of MacOS.

When I downgrade the deployment target to 10.6 then Demo runs,
but each demo fails with a message similar to the following:

LSOpenURLsWithRole() failed with error -10825 for the file
/Users/duncan/Library/Developer/Xcode/DerivedData/.../Build/Products/Debug/cursor.app

As I was only curious about FLTK on Mac and using Xcode, I can't
be bothered to fight with the system to get it to work. And as
Xcode in its current configuration doesn't appear to offer class
navigation and refactoring support, then I might as well use vi
and make, which I know works.

I'm really surprised to have such a negative experience with Xcode.
Apple are famous for their user friendly and intuitive interfaces
and I'm really disappointed that Xcode doesn't fall in that category.
This is probably unfair, and it would probably make more sense if
I learned something about the MacOS ecosystem, but I'm not going
to spend any more time on Xcode.

[Manolo]

On Wednesday, 21 September 2016 09:33:56 UTC+2, duncan wrote:

I'm on MacOS 10.11.6, and downloaded Xcode ?.? last week.

If I start Xcode and open .../fltk-1.3.3/ide/Xcode4/FLTK.xcodeproj
and follow the instructions in README.OSX.txt then Demo won't build.
In fl_line_style.cxx > [M] Fl_Graphics_Driver::line_style(...)
  static enum CGLineCap Cap[4] =...
  Elaborated type refers to a typedef

This problem appeared in Mac OS 10.11 (or 10?), after FLTK 1.3.3 was released.
It is fixed in the svn repository and will be fixed in FLTK 1.3.4.

If instead I open the latest fltk-1.3.x from svn (11951?) I can get
Demo to build, but then Run Demo says:
  My Macbook Pro cannot run Demo
  My Macbook Pro runs MacOS 10.11.6 which is lower than Demo's
  minimum deployment target. Change your project's minimum
  deployment target or upgrade My Macbook Pro's version of MacOS.

I would argue this is a bug in Xcode 8 which requires
by default Mac OS 10.12 (not out yet) when running on 10.11.
This makes no sense.
I will change the default minimum target in the Xcode project for FLTK.
 

When I downgrade the deployment target to 10.6 then Demo runs,
but each demo fails with a message similar to the following:

  LSOpenURLsWithRole() failed with error -10825 for the file
  /Users/duncan/Library/Developer/Xcode/DerivedData/.../Build/Products/Debug/cursor.app

I cannot reproduce this problem.
 

As I was only curious about FLTK on Mac and using Xcode, I can't
be bothered to fight with the system to get it to work. And as
Xcode in its current configuration doesn't appear to offer class
navigation and refactoring support, then I might as well use vi
and make, which I know works.

I'm really surprised to have such a negative experience with Xcode.
Apple are famous for their user friendly and intuitive interfaces
and I'm really disappointed that Xcode doesn't fall in that category.
This is probably unfair, and it would probably make more sense if
I learned something about the MacOS ecosystem, but I'm not going
to spend any more time on Xcode.

D.

Xcode is a huge beast with a steep learning curve.
The first encounters with it feel like a boxing fight.
At some point, it improves.