Re: [fltk.general] Now I know how to build FLK on Windows

[Albrecht Schlosser]

On 26.02.2015 03:27 Hannu Vuolasaho wrote:
> Hello!
>
> I just set up windows 8.1 virtual environment for me and build FLTK
> succesfully (99.9%) with Cygwin. Sudoku failed with icon.

Your configure command didn't find the windres tool. See below.

> Not all packages are necessary, most hare expediencies and my laziness
> to find the one I really need.

Note that we do not recommend using Cygwin for building FLTK under
Windows, unless you really know what you're doing (and why) and/or you
need Cygwin's POSIX functions - which makes your FLTK programs depend on
Cygwin1.dll and requires a Cygwin license if you want to write
commercial programs or redistribute you programs. Also Cygwin is not
easy to set up.

The FLTK team recommend using MinGW instead.

> I wrote some notes about it.
>
> Below are my notes and I share them someone can also compile FLTK on
> windows.
>
> Best regards,
> Hannu Vuolasaho
>
> Test environment: Fresh install of Win 8.1 64-bit and updates. Programs
> installed:
> Google chrome and cygwin. Packages listed at the end of this file.
>
> In svn lib/README.lib is in gitignore and git checkout of tree where
> FLTK is embedded doesn't have lib dir

Thanks for the hint about lib/README.lib being in .gitignore. It is also
in 'svn ignore' by accident. This is fixed now: I renamed it to 'README'.

I don't really understand what though you wrote here. Did you use svn to
download, or did you download FLTK with git (where from)? Maybe git svn?
URL?

> git add -f lib/README.lib &&git commit "Fix the tree" helps

Not necessary anymore since svn r 10591.

> x86_64 build warns a lot of int <-> pointer size Let's not go there. 32
> bits please.

That's a nasty Windows problem. We might try to fix this in the future.

As you found out, 32-bit builds work well.

> test directory fails with sudokures.o Only error and it comes with
> resource system.

See above and below (windres).

> Configuring:
>
> CC=i686-w64-mingw32-gcc CXX=i686-w64-mingw32-g++ \
> AR=i686-w64-mingw32-ar CFLAGS='-static-libgcc' \
> CXXFLAGS='-static-libstdc++ -static-libgcc' \
> LDFLAGS=-static ./configure
> ...

Cygwin requires you to configure native Windows builds as cross
compiling with the proper build tools. Please try this instead (works
well for me):

CFLAGS='-static-libgcc' \
CXXFLAGS='-static-libstdc++ -static-libgcc' \
LDLAGS='-static-libstdc++ -static-libgcc' \
./configure --host=i686-w64-mingw32

checking build system type... x86_64-unknown-cygwin
checking host system type... i686-w64-mingw32
checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i686-w64-mingw32-gcc accepts -g... yes
checking for i686-w64-mingw32-gcc option to accept ISO C89... none needed
checking for i686-w64-mingw32-g++... i686-w64-mingw32-g++
checking whether we are using the GNU C++ compiler... yes
checking whether i686-w64-mingw32-g++ accepts -g... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for nroff... /usr/bin/nroff
checking for doxygen... /usr/bin/doxygen
checking for i686-w64-mingw32-ranlib... i686-w64-mingw32-ranlib
checking for i686-w64-mingw32-ar... /usr/bin/i686-w64-mingw32-ar
checking for i686-w64-mingw32-windres... /usr/bin/i686-w64-mingw32-windres
checking how to run the C preprocessor... i686-w64-mingw32-gcc -E
...

Note: windres => /usr/bin/i686-w64-mingw32-windres

'make' runs w/o warnings and some (but not all) of the resulting
executable files are native Windows programs (can be launched from
explorer and distributed w/o Cygwin dll).

Note: Unfortunately LDFLAGS is not propagated correctly in all cases
when linking the demo programs in the test/ directory. Some of them are
linked with '-static-libstdc++ -static-libgcc' (for instance glpuzzle)
but others are not (e.g. hello). I'll take a look into it.

Meanwhile you can use a workaround and link at least most of the test
(demo) executables by using fltk-config like this:

cd test
../fltk-config --compile hello.cxx
../fltk-config --use-images --compile pixmap_browser.cxx

This builds hello.exe with the correct linker flags so the executable is
independent of the dll's.

[MacArthur, Ian (Selex ES, UK)]

> I just set up windows 8.1 virtual environment for me and build FLTK
> succesfully (99.9%) with Cygwin. Sudoku failed with icon.

I was going to say that we usually advise folks to use mingw rather than Cygwin, or the MS tools of course.
Looks like Albrecht got there first.

Cygwin is more "problematic", both to setup and use, and then in licensing terms for the Cygwin dll.

FWIW, mingw(32 and 64) build fltk 100%, right out of the box, as do the MS tools.

> x86_64 build warns a lot of int <-> pointer size Let's not go there.
> 32 bits please.

This is a consequence of the (perhaps unfortunate) choice that MS made in the move to 64-bits, where they decided to keep a "long" as 32-bits, the same as an "int".

Other hosts use a 64-bit "long".

The consequence, for fltk, is that we occasionally store transient long "user data" in a void* and of course on a 64-bit host (including 64-bit Windows) a void* is 64-bits.

So we store the 32-bit long "user data" in the 64-bit ptr, and that's OK; then later restore it from the 64-bit ptr to the 32-bit long, and the compiler complains.

Of course, on other hosts, we don't get that complaint (since the sizes match); and since the input data is restored fully (AFAIK!) even on Windows, there's no *actual* problem here.

It is noisy though!


For the future, we will probably move to using our internal fl_intptr_t for the user data, which will always be an integral type of the same size as the void* ptr and "all will be well".

But we can't do that right now, as it is ABI breaking on Windows... Maybe as part of the 1.4.x transition.

> test directory fails with sudokures.o Only error and it comes with
> resource system.

Looks like an issue with windres; the mingw one is fine though, FWIW.






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

[Albrecht Schlosser]

Sorry, I need to correct my own posting. :-(

On 26.02.2015 15:49 Albrecht Schlosser wrote:

> Cygwin requires you to configure native Windows builds as cross
> compiling with the proper build tools. Please try this instead (works
> well for me):
>
> CFLAGS='-static-libgcc' \
> CXXFLAGS='-static-libstdc++ -static-libgcc' \
> LDLAGS='-static-libstdc++ -static-libgcc' \
> ./configure --host=i686-w64-mingw32

There was a typo in the last command. I don't know where it came from,
although I used cut'n'paste (mostly).

s/LDLAGS/LDFLAGS/

Meanwhile I did some more testing, and as I assumed you only need the
'-static-*' options in LDFLAGS, hence the much shorter, but complete and
working commands are:

make distclean

LDFLAGS='-static-libstdc++ -static-libgcc' \
./configure --host=i686-w64-mingw32

make

This builds _all_ demo executables as native Windows applications so you
can launch them from explorer or a DOS shell (cmd) or whatever they call
this today in Windows (in German: Eingabeaufforderung).

Forget about this:

> Note: Unfortunately LDFLAGS is not propagated correctly in all cases
> when linking the demo programs in the test/ directory. Some of them are
> linked with '-static-libstdc++ -static-libgcc' (for instance glpuzzle)
> but others are not (e.g. hello).

This was due to the typo above, because some of the programs are linked
with a command that includes CXXFLAGS which had the appropriate flags
included.

FWIW: This would be the command to build 64-bit Windows executables, but
as it was said before, there are lots of compiler warnings:

LDFLAGS='-static-libstdc++ -static-libgcc' \
./configure --host=x86_64-w64-mingw32

Except the compiler warnings I didn't find any issues in a short test
and the Windows Task-Manager shows that the built programs are indeed
64-bit apps (it doesn't show '(32 Bit)').

[Hannu Vuolasaho]

On Thursday, February 26, 2015 at 4:49:35 PM UTC+2, Albrecht Schlosser wrote:

On 26.02.2015 03:27 Hannu Vuolasaho wrote:
> Hello!
>
> I just set up windows 8.1 virtual environment for me and build FLTK
> succesfully (99.9%) with Cygwin. Sudoku failed with icon.

Your configure command didn't find the windres tool. See below.

It seems that --host=i686....mingw  enables that. I got that fixed later.

My motivation of this post is that I have rather bigger project than normally
and it needs to be linux and windows compatible. FLTK wil be my UI library.
I wanted to document one way how to get FLTK working.

Note that we do not recommend using Cygwin for building FLTK under
Windows, unless you really know what you're doing (and why) and/or you
need Cygwin's POSIX functions - which makes your FLTK programs depend on
Cygwin1.dll and requires a Cygwin license if you want to write
commercial programs or redistribute you programs. Also Cygwin is not
easy to set up.

So far I'm developing on Linux and some compilation stuff needs Linux or cygwin.
I'll try to get rid of POSIX requirement and make that part more portable. And cygwin
is quite easy. base auto* make and mingw toolchain.

Anyway to keep constant testing, both platforms
need to be able to run the binaries.

I believe I used mingw toolchain in cygwin environment. All bineries are runnable
in another system which doesn't have cygwin.

However I'm not 100% sure about the Cygwin library if it got compiled in with -static.
At least I ran with mingw cross compiler.


BTW how do I enable real compilation commands instead of compiling foo... output?

The FLTK team recommend using MinGW instead.

 I would recomend also. And Eclipse, QT-creator and so on.

While I'm OK with command prompt, 99% of Windows developers aren't and
they want solution files.

I don't really understand what though you wrote here. Did you use svn to
download, or did you download FLTK with git (where from)? Maybe git svn?
URL?

 

I have just checkouted SVN repo to my tree as I will use it as static library.
Transferring data between machines is done through git. I'm not even using
git-svn as it can't handle that well svn submodules. So really wrong way.

And I would use stable version, but there is some good bugfix after 1.3.3
which I needed :)

And the reason to write it here was quite simple.
 I wanted to document over how I did it. And with few repeats I was able to
get the process how I descripbed.

 I tried few times with mingw installation and always ended up path problems
and depedency hell all the fun stuff you don't want to have on Windows.

But I have some idea how I would get MinGW working after I don't depend
POSIX any more.

Cygwin requires you to configure native Windows builds as cross
compiling with the proper build tools. Please try this instead (works
well for me):

CFLAGS='-static-libgcc' \
CXXFLAGS='-static-libstdc++ -static-libgcc' \
LDLAGS='-static-libstdc++ -static-libgcc' \
./configure --host=i686-w64-mingw32

We ended up same configure parameters and environment variables.
I have static in LDFLAGS also.
I

'make' runs w/o warnings and some (but not all) of the resulting
executable files are native Windows programs (can be launched from
explorer and distributed w/o Cygwin dll).

I can run every program on different computer which hasn't even seen cygwin. 

Note: Unfortunately LDFLAGS is not propagated correctly in all cases
when linking the demo programs in the test/ directory. Some of them are
linked with '-static-libstdc++ -static-libgcc' (for instance glpuzzle)

GLpuzzle included.


I thank everybody for feedback.

Best regards,
Hannu Vuolasaho

[Albrecht Schlosser]

On 26.02.2015 23:16 Hannu Vuolasaho wrote:
>
> On Thursday, February 26, 2015 at 4:49:35 PM UTC+2, Albrecht Schlosser
> wrote:
>

> On 26.02.2015 03:27 Hannu Vuolasaho wrote:
> > Hello!
> >
> > I just set up windows 8.1 virtual environment for me and build FLTK
> > succesfully (99.9%) with Cygwin. Sudoku failed with icon.
>
> Your configure command didn't find the windres tool. See below.
>

> It seems that --host=i686....mingw enables that. I got that fixed later.

Okay, fine.

> My motivation of this post is that I have rather bigger project than
> normally
> and it needs to be linux and windows compatible. FLTK wil be my UI library.
> I wanted to document one way how to get FLTK working.

Thanks for doing that. It is always good for other users to see.

> Note that we do not recommend using Cygwin for building FLTK under
> Windows, unless you really know what you're doing (and why) and/or you
> need Cygwin's POSIX functions - which makes your FLTK programs
> depend on
> Cygwin1.dll and requires a Cygwin license if you want to write
> commercial programs or redistribute you programs. Also Cygwin is not
> easy to set up.
>
>

> So far I'm developing on Linux and some compilation stuff needs Linux or
> cygwin.
> I'll try to get rid of POSIX requirement and make that part more
> portable. And cygwin
> is quite easy. base auto* make and mingw toolchain.

It *can* be easy, particularly if you have Linux/Unix experience.
However there are very often some problems that make working with Cygwin
difficult. Hence we recommend MinGW because it is easier to setup for
the occasional user (someone who needs a working environment to build
Windows programs but doesn't want to use MS IDE's).

> Anyway to keep constant testing, both platforms
> need to be able to run the binaries.
>
> I believe I used mingw toolchain in cygwin environment. All bineries are
> runnable
> in another system which doesn't have cygwin.

Yes, the way you configured it you are using the MinGW cross compilers.
However Cygwin's POSIX layer (cygwin1.dll) is not involved in this
configuration. If that is what you want then you can also use MinGW. But
if you are familiar with Cygwin it's your choice, of course.

> However I'm not 100% sure about the Cygwin library if it got compiled in
> with -static.
> At least I ran with mingw cross compiler.

You can't compile and link the Cygwin library static. The only way to
use it is to link in cygwin1.dll (and maybe more dll's) with all the
implications regarding licensing.

> BTW how do I enable real compilation commands instead of compiling
> foo... output?

You can edit makeinclude (in the FLTK root directory) and remove or
comment the '.SILENT' line.

If you are interested only in one command there's a nice trick I'm using
sometimes: if you have compiled FLTK already, delete one particular
object (.o) file and then run 'make -n'. This does not execute the
command, but it shows you the entire command(s).

> The FLTK team recommend using MinGW instead.
>
>

> I would recomend also. And Eclipse, QT-creator and so on.
>
> While I'm OK with command prompt, 99% of Windows developers aren't and
> they want solution files.

Currently we have only Xcode (Mac OS X) and Windows IDE support files.
We're making progress with CMake, and the idea is that users can
generate their IDE files with CMake (of course you need CMake then).

> I don't really understand what though you wrote here. Did you use
> svn to
> download, or did you download FLTK with git (where from)? Maybe git
> svn?
> URL?
>

> I have just checkouted SVN repo to my tree as I will use it as static
> library.
> Transferring data between machines is done through git. I'm not even using
> git-svn as it can't handle that well svn submodules. So really wrong way.

Okay, I see.

> And I would use stable version, but there is some good bugfix after 1.3.3
> which I needed :)

I hope we can release 1.3.4 in April or so, but there is no schedule yet.

> And the reason to write it here was quite simple.
> I wanted to document over how I did it. And with few repeats I was able to
> get the process how I descripbed.
>
> I tried few times with mingw installation and always ended up path
> problems
> and depedency hell all the fun stuff you don't want to have on Windows.

You found your way under Cygwin, and MinGW is absolutely the same,
except you don't need the cross compiling setup.

make distclean && LDFLAGS='-static-libstdc++ -static-libgcc' ./configure
&& make

> But I have some idea how I would get MinGW working after I don't depend
> POSIX any more.

That should be easy. Meanwhile MinGW has a good install tool.

> We ended up same configure parameters and environment variables.
> I have static in LDFLAGS also.

Okay.

> 'make' runs w/o warnings and some (but not all) of the resulting
> executable files are native Windows programs (can be launched from
> explorer and distributed w/o Cygwin dll).
>
>

> I can run every program on different computer which hasn't even seen
> cygwin.

That's good if that is what you intend. It's much more complicated if
you need the Cygwin dll and want to distribute your program to systems
that are not directly under your control.

> Note: Unfortunately LDFLAGS is not propagated correctly in all cases
> when linking the demo programs in the test/ directory. Some of them are
> linked with '-static-libstdc++ -static-libgcc' (for instance glpuzzle)
>
>

> GLpuzzle included.

Yes, here as well. The issue described above was caused by a typo on my
side. See my follow-up.

> I thank everybody for feedback.

You're welcome.

Thanks for your report.