STR #3102: VS7 ".NET" build errors: 'long' followed by 'long' is illegal, etc

STR #3102

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:	Core Library
Summary:	VS7 ".NET" build errors: 'long' followed by 'long' is illegal, etc
Version:	1.3-current
Created By:	greg.ercolano
Assigned To:	AlbrechtS
Fix Version:	1.3.3 (SVN: v10419)
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	greg.ercolano 16:10 Jul 02, 2014

vs7-v1.patch
2k

Trouble Report Comments:

#1	greg.ercolano 14:51 Jul 02, 2014

Getting this error when building with VS7 ".NET": --- Build started: Project: fltk, Configuration: Debug Win32 ------ Compiling... vsnprintf.c screen_xywh.cxx ../..\FL\Fl.H(1148) : error C2632: 'long' followed by 'long' is illegal --- Looks like VS7 doesn't grok "long long", and neither does VS6. Looks like this was introduced in r10150 a month or so ago: r10150 | fabien | 2014-05-20 21:10:12 -0700 (Tue, 20 May 2014) | 1 line Will try to follow up with a workaround..

#2	greg.ercolano 16:10 Jul 02, 2014

Would like to see Fabien's input on this. Attaching vs7-v1.patch which gets FLTK to build on VS7 again. A bit of a hack was done for Fl::msleep(), but what can you do. If nothing else, this patch might help work towards a better solution. Of interest, macros that can zero in on particular VS releases: VERSION MACRO PRODUCT NAME ------- ---------------- -------------------- MSVC++ 12.0 _MSC_VER == 1800 Visual Studio 2013 MSVC++ 11.0 _MSC_VER == 1700 Visual Studio 2012 MSVC++ 10.0 _MSC_VER == 1600 Visual Studio 2010 MSVC++ 9.0 _MSC_VER == 1500 Visual Studio 2008 MSVC++ 8.0 _MSC_VER == 1400 Visual Studio 2005 MSVC++ 7.1 _MSC_VER == 1310 Visual Studio 2003 MSVC++ 7.0 _MSC_VER == 1300 Visual Studio 7 MSVC++ 6.0 _MSC_VER == 1200 Visual Studio 6 MSVC++ 5.0 _MSC_VER == 1100 Visual Studio 5

#3	greg.ercolano 00:37 Jul 03, 2014

Hmm, looks like src/Fl_sleep.obj needs to be added to the IDE files; calls to Fl::msleep() from sudoku are failing to link because it looks like the new Fl_sleep.obj isn't getting packaged into the fltk lib: --- Build started: Project: sudoku, Configuration: Release Win32 ------ Linking... sudoku.obj : error LNK2019: unresolved external symbol "public: static void __cdecl Fl::msleep(unsigned long)" ( ../../test/sudoku.exe : fatal error LNK1120: 1 unresolved externals Build log was saved at "file://z:\tmp\fltk-1.3.x-svn-vs7\ide\VisualC6\Release\sudoku\BuildLog.htm" sudoku - 2 error(s), 0 warning(s) --- Also, some errors from the fltk_imagesdll build: --- Build started: Project: fltk_imagesdll, Configuration: Release Win32 ------ Compiling... Fl_PNM_Image.cxx Fl_PNG_Image.cxx Fl_JPEG_Image.cxx fl_images_core.cxx Fl_Help_Dialog.cxx Fl_GIF_Image.cxx Fl_File_Icon2.cxx Fl_BMP_Image.cxx Linking... Creating library .\Release/fltk_imagesdll/fltk_imagesdll.lib and object .\Release/fltk_imagesdll/fltk_imagesd fltk_png.lib(pngread.obj) : error LNK2019: unresolved external symbol _inflateInit_ referenced in function _png_ fltk_png.lib(pngread.obj) : error LNK2019: unresolved external symbol _inflate referenced in function _png_read_ fltk_png.lib(pngrutil.obj) : error LNK2019: unresolved external symbol _inflate referenced in function _png_hand fltk_png.lib(pngread.obj) : error LNK2019: unresolved external symbol _inflateEnd referenced in function _png_re fltk_png.lib(png.obj) : error LNK2019: unresolved external symbol _crc32 referenced in function _png_reset_crc fltk_png.lib(png.obj) : error LNK2019: unresolved external symbol _inflateReset referenced in function _png_rese fltk_png.lib(pngrutil.obj) : error LNK2019: unresolved external symbol _inflateReset referenced in function _png .\Release/fltk_imagesdll/fltk_imagesdll.dll : fatal error LNK1120: 5 unresolved externals ---

#4	ianmacarthur 03:33 Sep 05, 2014

Greg, do you want to apply this fix? FWIW, I like int64 better than long long anyway... Also, VS6 and VS7, really? Are they not a bit... old... now?

#5	AlbrechtS 05:56 Sep 19, 2014

We have a configure check for 'long long' that sets the preprocessor macro HAVE_LONG_LONG (hopefully correct). This is done in configure, but I didn't check CMake so far. It is also set to 1 in the Xcode3 and Xcode4 projects, but not in any Windows IDE projects (as of today): [in /path/to/fltk-1.3/ide] $ find . -name config* | xargs grep HAVE_LONG_LONG ./Xcode3/config.h:#define HAVE_LONG_LONG 1 ./Xcode4/config.h:#define HAVE_LONG_LONG 1 So I think the correct way to patch the 'long long' issue would be to use HAVE_LONG_LONG to decide which way to go (long long or __int64). Note that Windows IDE projects have their own config.h files (as do the Xcode projects), so we could maybe tweak those to set HAVE_LONG_LONG in ide/VisualC2008/config.h and ide/VisualC2010/config.h, but not in VisualC6 ? OTOH, unfortunately Fl::usleep() is "exported" in FL/Fl.H, so that this won't work in user code that doesn't have access to config.h :-( Anyway, just my 2 ct, may it be useful or not. Sorry for the noise, if not. Maybe someone has a better idea, or we can use Greg's patch, as it is.

#6	AlbrechtS 04:54 Nov 27, 2014

This STR appears to be obsolete, since the Fl::*sleep() method family has been removed. Other than the general problem of using 'long long' in MS VC IDE projects of ancient versions of MS compilers that don't understand this, the entire STR is irrelevant now. Greg?

#7	AlbrechtS 16:04 Jun 20, 2015

Fixed in Subversion repository. src/Fl_sleep.cxx has been removed in svn r10419.

#8	greg.ercolano 17:23 Jun 20, 2015

If Fl::usleep() was removed, then yeah, this is STR is a moot issue. I'll check VS7 with svn current later today, and if there's problems, will open a new STR. @Ian: Yes, VS7 is old, but I still depend on it to commercial builds since I can run all my binaries it generates on everything from NT thru Win10. I also paid a fair amount of $$$ for that friggin' compiler, LOL.