fltk using codeblocks and windows

554 views
Skip to first unread message

A.J. bonnema

unread,
Nov 22, 2014, 10:04:05 AM11/22/14
to fltkg...@googlegroups.com
Hi all,

My team mate (Stephan Versluys) found how to use fltk from code blocks
under windows, which to my surprise, it needs an older version of cmake.
I include his readme so you guys might check or even include in your
docs. I didn't find it when browsing the manual, but hey .... (don't
exactly know how to go on, but it sounds good).

Regards, Guus.


README-FLTK-WINDOWS.md

Richard Sanders

unread,
Nov 22, 2014, 2:53:26 PM11/22/14
to fltkg...@googlegroups.com
Why not just use the msys toolchain? Msys2 was problematic last time I tried it but the earlier msys works. Take a look at README.MSWindows.txt in the FLTK root directory for more info.

markj...@gmail.com

unread,
Nov 23, 2014, 7:47:17 AM11/23/14
to fltkg...@googlegroups.com
fyi: I was recently able to cross compile using mingw on Linux and then testing under wine.
FLTK compiled without a hitch (used mingw32-configure and mingw32-make). The only problem was figuring out static libraries to pull in. I had to add these ld flags to my apps makefile
    -lgdi32\
    -lcomdlg32\
    -static-libgcc\
    -static-libstdc++\
    -mwindows

I am guessing mingw on Windows itself would work similar. This was with latest mingw.

A.J. bonnema

unread,
Nov 23, 2014, 8:15:47 AM11/23/14
to fltkg...@googlegroups.com
On 23-11-14 13:47, markj...@gmail.com wrote:
> fyi: I was recently able to cross compile using mingw on Linux and
> then testing under wine.
> FLTK compiled without a hitch (used mingw32-configure and
> mingw32-make). The only problem was figuring out static libraries to
> pull in. I had to add these ld flags to my apps makefile
> -lgdi32\
> -lcomdlg32\
> -static-libgcc\
> -static-libstdc++\
> -mwindows
>
> I am guessing mingw on Windows itself would work similar. This was
> with latest mingw.
>
Thanks. I am going to use this info for my project.

Kind regards, Guus.

Michael Surette

unread,
Nov 23, 2014, 9:07:57 AM11/23/14
to fltkg...@googlegroups.com
On Sat, Nov 22, 2014 at 10:04 AM, A.J. bonnema wrote:
> Hi all,
>
> My team mate (Stephan Versluys) found how to use fltk from code blocks under
> windows, which to my surprise, it needs an older version of cmake.

I think you'll find it needs a minimum version of CMake 2.6. Any
later version should work fine, although personally I haven't used
anything past 2.8.12. 2.6 was the closest to current CMake version I
could justify when I first attacked the CMake build files. In a
project like FLTK which is targeted to as many compilers as possible,
it doesn't necessarily pay to use the latest technology.

> I include his readme so you guys might check or even include in your docs. I
> didn't find it when browsing the manual, but hey .... (don't exactly know
> how to go on, but it sounds good).

I'm glad you decided to go with the mingw compiler. The Microsoft
compiler currently has problems with FLTK dynamic builds under CMake.
As a general rule though FLTK should be statically linked.

If you have decided to use CMake as the build system for your project,
be sure to read the readme included in the FLTK tarball. Other than
the MSVC dynamic build issue FLTK and CMake work well together.
Cross-compiling with CMake works well with the mingw tools as well.
Automatic dependency resolution works in all configurations. ie if
you link in libfltk it knows what's needed by libfltk for your
platform and links in those dependencies.

If you're not going to use CMake for your project, you're better of
compiling FLTK with the normal configure/make method, even under
Windows. This gives you a working fltk-config. fltk-config provides
the compiling and linking magic.

Either way, things should work well, just don't mix CMake and
non-CMake build files on the same project. You really should
standardize on one or the other across the project.
--
Mike

A.J. bonnema

unread,
Nov 23, 2014, 9:27:25 AM11/23/14
to fltkg...@googlegroups.com
Thanks for your explanation. We are standardizing on cmake, so it should
work then.
I will have Stefan take another look at the version issue that we found
under windows.

Kind regards, Guus.

Mark Olesen

unread,
Nov 23, 2014, 9:31:33 AM11/23/14
to fltkg...@googlegroups.com
I think the mingw configure,make and g++ are named differently under Windows and Linux. So, you would have to check. After installing mingw, I am pretty sure you need to set the fstab on Windows :
file: c:/mingw/msys/1.0/etc/fstab
C:\MinGW        /mingw
needs above line
Following, when you run the bat file, you'll have access to the bin tools.

Once setup is runs pretty smooth. This is also from memory. If I missed anything, my apologies. I don't use Windows (don't even know what a codeblock is). So, hopefully, it works for you. Best of luck.



--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/wPdHz2NA2R8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

A.J. bonnema

unread,
Nov 23, 2014, 9:33:42 AM11/23/14
to fltkg...@googlegroups.com
On 23-11-14 15:31, Mark Olesen wrote:
>
> Once setup is runs pretty smooth. This is also from memory. If I
> missed anything, my apologies. I don't use Windows (don't even know
> what a codeblock is). So, hopefully, it works for you. Best of luck.
>
Thanks. Code::Blocks is an IDE that I lazily referred to as codeblocks xD.

Regards, Guus.

Albrecht Schlosser

unread,
Nov 23, 2014, 2:37:36 PM11/23/14
to fltkg...@googlegroups.com
On 22.11.2014 16:04 A.J. bonnema wrote:

> My team mate (Stephan Versluys) found how to use fltk from code blocks
> under windows, which to my surprise, it needs an older version of cmake.

Hmm, you can't say that CMake 3.0.2 (this works, according to the
attachment) is an "older version" of CMake. It's the official current
stable version, whereas 3.1.0 rc2 is a release candidate for the next
version. There may be issues with this bleeding edge version, I don't
know. If you have some error messages, it would be nice to know.

> I include his readme so you guys might check or even include in your
> docs. I didn't find it when browsing the manual, but hey .... (don't
> exactly know how to go on, but it sounds good).

I believe there is nothing particular for Code::Blocks in our
documentation. Thanks for your report and the readme. I'll try to give
you some comments about the readme and how you may proceed.


> Generate fltk makefiles
> =======================
- Start x:\cmake-3.0.2-win32-x86\bin\cmake-gui.exe
> - Set browse source to x:\fltk-1.3.3

Okay so far.

> - Set build path to x:\fltk-1.3.3\lib

This is unusual, but also not really wrong. I wouldn't recommend it
though. CMake encourages out-of-source builds, but '\lib' is an existing
source directory. So if you want to build in-source, then you would use
the root directory, i.e. x:\fltk-1.3.3 (although not recommended),
otherwise you'd want to create another directory apart from the
x:\fltk-1.3.3 tree or a separate directory within the FLTK tree, e.g.
x:\fltk-1.3.3\build. I recommend one of the latter, but which one is a
matter of personal preference. In both cases you can delete the entire
build tree w/o affecting the source files. Having the build tree outside
the FLTK tree enables you to replace or upgrade the FLTK tree easily.
BTW: this is true for Windows and Linux as well.

That said, FLTK's CMake support is not yet complete, so you may run into
issues that are not yet covered. Michael posted more info in another
message.

> Setup CodeBlocks
> ================
>
> - Set search directory for compiler to C:\Program Files (x86)\FLTK

This should be okay, but see below.

> - Set search directory for linker to C:\Program Files (x86)\FLTK and
C:\Program Files (x86)\FLTK\lib

The latter should suffice, the former is probably just overhead.

> - If creating a new fltk project remove subdirectory FL\ from includes.
>
> #include <FL\Fl.H> becomes #include <Fl.H>

Unless you have a VERY good reason to do this, never ever do this. It
will make your source code non-portable or at least non-standard. All
examples you see in the FLTK source directory, on Greg's famous cheat
page, or in any tutorial, and everything you will find working in your
Linux installation will need the 'FL/' prefix. Also note that you should
always use a forward slash for portability reasons. This will work on
all platforms including Windows. Hence the correct form is:

#include <FL/Fl.H>

I wonder how the described setup could have worked w/o some other not
mentioned settings (see below for my guess).

You should check the Code::Blocks setup again. I'm not using it
personally, but I did a few tests today with the Linux version. I
created a "FLTK projekt", and as you said it worked out of the box (in
my case: almost). The reason it didn't work for me was that I didn't
"install" FLTK but wanted to use it from its build directory (for
reasons that are OT here). So I could try and get some experience how to
set up Code::Blocks.

I guess your colleague set the search path for the compiler to

C:\Program Files (x86)\FLTK\FL

instead of

C:\Program Files (x86)\FLTK

as mentioned above. This might have been some trial-and-error effect,
but once this is fixed it should work with the 'FL/' prefix in the
include statements again.


That said: as Richard asked: "Why not just use the msys toolchain?"

This is what the FLTK devs recommend for Windows. You're using the MinGW
compiler and MinGW make anyway (included in your Code::Blocks download),
so you could also install MinGW and the MSYS development package as a
separate installation (besides Code::Blocks). This would give you an
environment similar to the Linux environment you're also using: command
line gcc/g++ compiler, together with autogen to configure the (FLTK)
build. Going further with explanations how to use it would be OT here,
but if you're interested, please take a look at README.MSWindows.txt in
the FLTK root directory. If you have more questions, feel free to ask again.

Personally I have good experiences using MinGW/MSYS (make + gcc) under
Windows and using Linux make + gcc to produce portable FLTK
applications. I'm also using CMake + make for the software I'm
developing, and on top of that I'm also using an IDE which enables me to
use a graphical debugger (gdb under the hood). I chose CodeLite as the
IDE, but Code::Blocks looks very similar.

Summary = my recommendation: fix the Code::Blocks setup, take a further
look at MinGW/MSYS (www.mingw.org), use CMake if you like for your
projects, and you should be fine. This all can be integrated pretty well
for a good development environment to generate portable FLTK applications.

One addition you didn't ask for: use a software repository (I prefer
git, FLTK uses subversion) with a central server in your network so you
can also maintain your sources cross-platform easily. In my case we are
also sharing the CodeLite project files for our development projects in
the git repository.

MacArthur, Ian (Selex ES, UK)

unread,
Nov 24, 2014, 5:12:10 AM11/24/14
to fltkg...@googlegroups.com
> > fyi: I was recently able to cross compile using mingw on Linux and
> > then testing under wine.
> > FLTK compiled without a hitch (used mingw32-configure and
> > mingw32-make). The only problem was figuring out static libraries to
> > pull in. I had to add these ld flags to my apps makefile
> > -lgdi32\
> > -lcomdlg32\
> > -static-libgcc\
> > -static-libstdc++\
> > -mwindows
> >
> > I am guessing mingw on Windows itself would work similar. This was
> > with latest mingw.
> >
> Thanks. I am going to use this info for my project.


FWIW, I use mingw with the autoconf / make tools for all my Windows work, and it Just Works.

Not a big Cmake user, I find it much harder to use than the "legacy" tools...


Selex ES 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.
********************************************************************

MacArthur, Ian (Selex ES, UK)

unread,
Nov 24, 2014, 5:18:15 AM11/24/14
to fltkg...@googlegroups.com
> I think the mingw configure,make and g++ are named differently under Windows
> and Linux. So, you would have to check.

On Windows, in an Msys shell make is called make, gcc is called gcc, g++ is called g++, configure is called configure, etc...

It "looks" just like a regular host.

Cross-compiling from linux to WinXX is like any cross-compilation environ., so in that case the cross-tools are likely to have odd names with prefixes or suffixes to denote their utility...

> After installing mingw, I am pretty
> sure you need to set the fstab on Windows :
> file: c:/mingw/msys/1.0/etc/fstab
> C:\MinGW /mingw
> needs above line
> Following, when you run the bat file, you'll have access to the bin tools.

That depends on how you install msys and mingw, if I recall correctly.
FWIW, it has always Just Worked for me, so once you have mingw and msys installed and working...


> Once setup is runs pretty smooth. This is also from memory. If I missed
> anything, my apologies. I don't use Windows (don't even know what a
> codeblock is). So, hopefully, it works for you. Best of luck.

From an Msys shell "the same" Makefile that builds my Linux build (on Linux) or my OSX build (on OSX) just works and does the Right Thing..
About 99.99% (indeed, 100% in many cases) of the code is common across all three platforms.

A.J. bonnema

unread,
Nov 24, 2014, 6:22:43 AM11/24/14
to fltkg...@googlegroups.com
On 24-11-14 11:12, MacArthur, Ian (Selex ES, UK) wrote:
> FWIW, I use mingw with the autoconf / make tools for all my Windows
> work, and it Just Works. Not a big Cmake user, I find it much harder
> to use than the "legacy" tools...
Yes, I understand and I know there are many viewpoints here. I
particularly dislike cmake (hate the uppercase usage), but my client
(the professor) is pretty attached to cmake. I will have to make do.

Kind regards, Guus Bonnema.
Reply all
Reply to author
Forward
0 new messages