STR #2965: msys mingw build probs - Fast Light Toolkit (FLTK)

STR #2965

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	3 - Moderate, e.g. unable to compile the software
Scope:	2 - Specific to an operating system
Subsystem:	Config Files
Summary:	msys mingw build probs
Version:	1.3.2
Created By:	rainbowsally
Assigned To:	AlbrechtS
Fix Version:	1.3-current (SVN: v9923)
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

No files

Trouble Report Comments:

#1	rainbowsally 03:21 May 21, 2013

fltk is not building properly with mingw/msys and gcc v. 4.6.2. The most common error message is that <name> is already defined as another type of symbol. Here's what I did to fix it. - means remove + means add [if no + or - means it's just context in the file] fltk-rs-1.3.2/config.h -#undef HAVE_STRTOLL -#ifndef HAVE_STRTOLL -# define strtoll(nptr,endptr,base) strtol((nptr), (endptr), (base)) -#endif /* !HAVE_STRTOLL */ fltk-rs-1.3.2/fluid/factory.cxx +// -rs +#define HAVE_STRCASECMP 1 + #include "Fl_Widget_Type.h" extern Fl_Pixmap *pixmap[]; fltk-rs-1.3.2/src/flstring.h # if defined(WIN32) && !defined(__CYGWIN__) -# define strcasecmp(s,t) _stricmp((s), (t)) -# define strncasecmp(s,t,n) _strnicmp((s), (t), (n)) +// # define strcasecmp(s,t) _stricmp((s), (t)) +// # define strncasecmp(s,t,n) _strnicmp((s), (t), (n)) Obviously these can be addressed with an #if directive but I have not done that since I only have need one build and I might break something else if I guess at the right treatment.

#2	AlbrechtS 05:27 May 22, 2013

FLTK 1.3.2 builds for me w/o problems with MinGW/msys and gcc 4.6.2. There must be something wrong with your MinGW installation. Please try to upgrade, maybe you need a newer w32api package. Please try this: $ mingw-get update $ mingw-get upgrade w32api upgrade: w32api-3.17-2-mingw32-dev.tar.lzma mingw-get.exe: *** INFO *** package w32api-3.17-2-mingw32-dev.tar.lzma is up to date The first command loads the new package list only and does no harm at all. The second line would download and install a new w32api package, if necessary. You can see that I have the /current/ version 3.17-2 installed. Anyway: I fixed part one of your problem in current svn (r 9923) by just removing the configure tests and definition of strtoll, since this is not used anywhere in FLTK. The second part regarding strcasecmp() and strncasecmp() should NOT be a problem with current MinGW installations. Please try again with a fresh svn checkout. If you can't use svn to get the current version, try to apply this patch instead: http://www.fltk.org/newsgroups.php?gfltk.commit+v:10448 Then please run these commands: make distclean autoconf -f make ... and report if the problem persists.

#3	greg.ercolano 10:17 May 22, 2013

Hi RS, good to see you back. Hmm, can't replicate with 1.3.x svn, perhaps it's already been addressed. Can you check with 1.3.x svn current? I just installed mingw with the 4.6.2 compiler, used svn to checkout a clean 1.3.x current, and it built with no errors; build log: http://seriss.com/people/erco/tmp/fltk-1.3.x-build-with-mingw-g++-4-6-2.html

#4	greg.ercolano 10:21 May 22, 2013

Oh, missed that Albrecht already jumped on this. Seems he got 1.3.2 to build OK as well, so perhaps it is a compiler issue. Apparently me and Albrecht both used 32bit builds.. RS, are you using 32bit or 64bit mingw? (Perhaps it matters..)

#5	rainbowsally 09:50 May 23, 2013

Hi Greg and Albrecht. I got the latest stable fltk 3.2, and I am using msys. The compile was 32 bits. Everything was updated using mingw-get. Might even have a newer version than you folks and see if I could compile in windows. I just wanted to see what's up with recent developments, and so if nobody else is having probs it's no big deal but if you do get more bug reports, we have a trail of beans to follow. Good to see you're still around too, Greg. I wish QT broke stuff down like FLTK does so you can mess with the innards. But I'm back in the fight with QT again. Seems we are always heading the opposite direction. ;-) Also, 2.0 never should have been mothballed. Just my opinion. If anyone wants to see why, FTL is based on it. http://rainbowsally.net/tkf/ftl/ftl-2011-09-23-a.tar.xz (I think that's the latest.) Thanks! TTYL.

#6	greg.ercolano 11:52 May 23, 2013

Re: 2.0 mothball, it lives again in 3.x which is a merge of 2 and 1. I don't know much about it, but that's the direction of development. Have you looked at 3.x? It should have the best of 1 and 2 is my understanding..

#7	rainbowsally 14:05 May 24, 2013

Hi Greg. I know that's been the goal for some time, but I see tangents, new additions and some really great features are missing from 3.x. Yeah, I've tried it. For starters, the color chooser in 2.0 was better. And had options. The themes didn't quite work in 2.x but I got them working in FTL. KDE3, Windows XP, and some funky stuff. I had problems with the alpha mixing and didn't ever finish that. The problem was that everything always got lighter -- same as in 3.x. You can see it in the GTK sliders. BTW, the sliders have a very NICE appearance, but still limited, which could be modified with 'themes'. When I got opensuse 11.4, the subpixel rendering quit working, which I was doing by drawing on a pixmap at 2X size and then copying to the widgets. It was very nice, but apparently the current XRender in my system 'optimized' out the mixing or there's some default set that I don't know how to undo. But having subpixel rendering would also be exceptionally cool in 3.x. Not just fonts. I'm talking about lines and especially circles, which end up looking beautiful when they are copied from 2X to 1X scale... when it works. ;-) And alpha shading (which still works in my FTL) like for the checkers game, is really just required by this stage in the game. The mask is a png image with alpha, not a bitmap. (Last time I checked it was still a bitmap mask). More can be done with alpha-rendered image files. Even up/down buttons could be accomplished with pixmaps split into 9 equal squares, only the corners don't "stretch". And then we get any kind of slider ornament or button we want -- though the colorizing then becomes a problem (again) due to the way colors mix in all of the fltk genre, including my FTL. Still, if anyone wants to and if it compiles for you, the FTL test files should be a real eye opener. It's mostly 2.x code. And so I can see LOTS of things 3.x is missing still. FLTK is a fast light toolkit, and it's good for that, but even the panels in 2.0 were nicer. Easier to GROK. And converting fluid from 2.0 to 3.x shouldn't even have been very hard, but it appears the backward compatibility notion has overridden common sense or maybe it's just that none of the developers were able to get 2.x working... which IS VERY LIKELY THE CASE! Until Ben took it over and got it working again. And once working... it still beats the pants off of 3.x in my opinion, though Ben still left a few bugs... which are mostly worked out in my FTL... linux only tho. It's great to be talking with you again. I've missed some of our discussions and your fltk (1.x) demos are still the bomb. Matt buttons was one of my favorites, but all of them were extremely interesting. If anyone else is looking in, they should check them out. 1.x stuff probably still runs in 3.x I think if someone were to take the above critique seriously, fltk could become very exciting again. Not because it has layered graphics animation effect or 3d stuff (which it doesn't) but because it is fast and it is light.

#8	ianmacarthur 16:14 Mar 11, 2014

Is this one still open, or should we close it? FWIW, mingw works ok for me, too... Oh, and "Hi!" to rainbowsally.

#9	ianmacarthur 13:20 Sep 04, 2014

Fixed in Subversion repository. Hi RS: I think this was fixed circe r9923; please shout out if it is still broken.