| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3232
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: | None |
Summary: | fl_dnd_win32 compilation error |
Version: | 1.3-current |
Created By: | markjolesen |
Assigned To: | AlbrechtS |
Fix Version: | None |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#1 | markjolesen 23:41 Jun 04, 2015 |
| Compiling fl_dnd.cxx... In file included from fl_dnd.cxx:20:0: fl_dnd_win32.cxx: In static member function ‘static int Fl::dnd()’: fl_dnd_win32.cxx:528:27: error: invalid new-expression of abstract class type ‘FLDropSource’ FLDropSource *fds = new FLDropSource; ^ fl_dnd_win32.cxx:313:7: note: because the following virtual functions are pure within ‘FLDropSource’: class FLDropSource : public IDropSource ^ In file included from /usr/include/w32api/urlmon.h:288:0, from /usr/include/w32api/objbase.h:163, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/wtypes.h:12, from /usr/include/w32api/winscard.h:10, from /usr/include/w32api/windows.h:97, from ../FL/win32.H:28, from ../FL/x.H:41, from fl_dnd_win32.cxx:24, from fl_dnd.cxx:20: /usr/include/w32api/oleidl.h:4059:39: note: virtual HRESULT IDropSource::GiveFeedback(DWORD) virtual HRESULT STDMETHODCALLTYPE GiveFeedback( ^ ../makeinclude:149: recipe for target 'fl_dnd.o' failed make[1]: *** [fl_dnd.o] Error 1 Makefile:24: recipe for target 'all' failed make: *** [all] Error 1
oleidl.h defines function parameter as DWORD 4059 virtual HRESULT STDMETHODCALLTYPE GiveFeedback( 4060 DWORD dwEffect) = 0;
fl_dnd_win32.cxx defines function parameter as ulong 337 STDMETHODIMP GiveFeedback( ulong ) { return DRAGDROP_S_USEDEFAULTCURSORS; }
Apparently, they are different sizes. So, the function signature is different (not overriden).
cygwin enviornment windows 7 64-bit $ uname -a CYGWIN_NT-6.1 bella 2.0.3(0.287/5/3) 2015-06-03 13:57 x86_64 Cygwin ./configure make
I changed the ulong to DWORD. It compiled but am now running into linker issues (probably missing a DLL in LIBS).
$ make === making src === Compiling fl_dnd.cxx... (NO PROBLEM AFTER CHANGE TO DWORD) /usr/bin/ar cr ../lib/libfltk.a ... === making fluid === Linking fluid.exe... (SEPARATE ISSUE - missing lib?) ../lib/libfltk.a(fl_dnd.o):fl_dnd.cxx:(.rdata$.refptr.IID_IDropTarget[.refptr.II D_IDropTarget]+0x0): undefined reference to `IID_IDropTarget' ../lib/libfltk.a(fl_dnd.o):fl_dnd.cxx:(.rdata$.refptr.IID_IDataObject[.refptr.II D_IDataObject]+0x0): undefined reference to `IID_IDataObject' ../lib/libfltk.a(fl_dnd.o):fl_dnd.cxx:(.rdata$.refptr.IID_IDropSource[.refptr.II D_IDropSource]+0x0): undefined reference to `IID_IDropSource' ../lib/libfltk.a(fl_dnd.o):fl_dnd.cxx:(.rdata$.refptr.IID_IUnknown[.refptr.IID_I Unknown]+0x0): undefined reference to `IID_IUnknown' collect2: error: ld returned 1 exit status Makefile:50: recipe for target 'fluid.exe' failed make[1]: *** [fluid.exe] Error 1 Makefile:24: recipe for target 'all' failed make: *** [all] Error 1 | |
|
#2 | markjolesen 05:28 Jun 06, 2015 |
| $ uname -a MINGW32_NT-6.1 BELLA 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys
Compilation of FLTK 1.3.x under mingw/msys went without a hitch. Gave up for now compiling in cygwin. Shoot me an e-mail if you have any questions or need testing. | |
|
#3 | AlbrechtS 10:19 Jun 06, 2015 |
| Thanks for the report, and sorry for the late and short reply. I'm working on another patch right now, so this needs to be short.
There are several issues with building under Cygwin, but there are also several ways to succeed, depending on what you want to achieve. If you want to build native Windows programs you're fine with MinGW. We (the FLTK team) always recommend MinGW.
The only good reason to build FLTK under Cygwin is if you need Cygwin's POSIX environment (cygwin1.dll), but then your programs depend on Cygwin.
With the latest (2.0) 64-bit Cygwin you run into the issue you reported if you try to build Windows (GDI) apps, and I don't have a solution for this. If you configure with --enable-x11 FLTK should build well, but then you also need an X server (Cygwin provides one).
That said, I think that your proposed patch is correct, but the linker issues are odd. Maybe a name mangling problem, because you are building with 64-bit Cygwin (2.x). Note that the build succeeds on my test system with 32-bit Cygwin (1.7).
I'll probably commit your patch, but the linker problem can't be resolved for now, unless someone digs into it. Sorry.
And finally: if you want Cygwin only as a development platform you can still use the provided MinGW cross compilers, and I tested cross-compiling 32-bit and 64-bit apps - both worked. But that's another story. | |
|
#4 | markjolesen 17:35 Jun 06, 2015 |
| uuid.lib is supposed to get linked in. However, after making the change, it does not solve the issue either. So, I am not sure what the problem is. I haven't tried compiling cygwin with x11 or mingw 64-bit. However, mingw 32-bit does indeed work. | |
|
#5 | AlbrechtS 10:17 Jul 17, 2015 |
| svn r10795 fixes the data type issue (DWORD) which makes the compiler happy, but the linker error remains.
I believe that this /might/ be a Cygwin problem, because there are no problems with Cygwin 1.7 (32-bit), but I'm not sure about this.
This problem should be reported to the Cygwin folks after further testing and reducing it to a small test case.
I'm sorry, I can't do this now or in the near future. | |
|
#6 | AlbrechtS 11:06 Jan 09, 2019 |
| The data type part has been fixed, the linker part can't be resolved by FLTK.
I don't know if a more recent version of Cygwin resolves the linker because I don't have a current Cygwin version available. There are several other build systems that were mentioned in this STR, hence I'm closing this STR now "w/Resolution" because the data type has been fixed.
If this issue is still pertinent with FLTK 1.4 please file a new bug report for FLTK 1.4.
Closed. | |
[ Return to Bugs & Features ]
|
| |