On 05.02.2018 05:47 Robin Rowe wrote:
>
> Almost have eliminated build errors in CinePaint 2.0 build system. Left
> with a dozen link errors that are FLTK related. TrackMouseEvent
> unresolved and jpeg lib issues linking to FLTK. Am using TurboJPEG
> library instead of the classic libjpeg. Error messages below...
Missing _TrackMouseEvent is a well-known issue. You need to link with
comctl32.lib. ... I see you added User32.lib which may also resolve the
issue (did it?), although the FLTK advice is to use comctl32.lib. I
suggest to add comctl32.lib to your link libraries, just to be sure.
After reading further and seeing the "fluid" error I'm not sure if the
above is an error when linking CinePaint or when building fluid. The
former should be fixed by adding comctl32.lib to your CinePaint build
instructions, the latter (missing comctl32.lib when building FLTK)
should not happen.
> By the way, building from the dev prompt I get a permissions error
> trying to patch TurboJPEG. Am calling cmake from gitbash.
I don't know why you get permission errors. I experienced such strange
errors in my environment (Win10) recently, and I'm pretty sure this
happened after an upgrade (Windows Update patch installation). Maybe MS
changed their permission checks. It appears to me that directory access
is not permitted because of missing ACL's if you create your own
directories outside your user directories. But maybe I'm wrong. Anyway,
it's annoying.
Side note: when I "opened" my notebook today it was "off" and I had to
reboot. Usually I "suspend to disk", so this was surprising. I have no
idea why this had happened. Then my MinGW installation didn't work. Bash
got into a CPU-bound loop or emitted the typical "fork errors". Changing
permissions didn't help - I had to rebase the dll's. Well, after that it
worked again. Strange...
Back to your question, see below:
> 2>fltkd.lib(Fl_win32.obj) : error LNK2019: unresolved external symbol
> __imp___TrackMouseEvent@4 referenced in function "long __stdcall
> WndProc(struct HWND__ *,unsigned int,unsigned int,long)"
> (?WndProc@@YGJPAUHWND__@@IIJ@Z)
See above, use comctl32.lib
> 2>C:\Code\gitlab\Cinepaint\glasgow\build\app\Debug\cinepaint.exe : fatal
> error LNK1120: 1 unresolved externals
> 2>Done building project "cinepaint.vcxproj" -- FAILED.
> 3>fltk_imagesd.lib(Fl_JPEG_Image.obj) : error LNK2019: unresolved
> external symbol _jpeg_std_error referenced in function "public:
> __thiscall Fl_JPEG_Image::Fl_JPEG_Image(char const *)"
> (??0Fl_JPEG_Image@@QAE@PBD@Z)
> 3>fltk_imagesd.lib(Fl_JPEG_Image.obj) : error LNK2019: unresolved
> external symbol _jpeg_CreateDecompress referenced in function "public:
> __thiscall Fl_JPEG_Image::Fl_JPEG_Image(char const *)"
> (??0Fl_JPEG_Image@@QAE@PBD@Z)
[...]
> 3>fltk_imagesd.lib(Fl_JPEG_Image.obj) : error LNK2019: unresolved
> external symbol _jpeg_resync_to_restart referenced in function "void
> __cdecl jpeg_mem_src(struct jpeg_decompress_struct *,unsigned char const
> *)" (?jpeg_mem_src@@YAXPAUjpeg_decompress_struct@@PBE@Z)
> 3>C:\Code\gitlab\Cinepaint\glasgow\build\fltk\fltk-build\bin\Debug\fluid.exe
> : fatal error LNK1120: 10 unresolved externals
> 3>Done building project "fluid.vcxproj" -- FAILED.
This is harder to diagnose. Some possibilities:
(1) You must build TurboJPEG before you build FLTK (fluid).
(2) The FLTK build must find your libjpeg. If it is in a directory
unknown to the FLTK CMake scripts, then it can't find it. However, if
this was the case, the error messsage would probably be different.
(3) The library TurboJPEG is missing some symbols that are required to
build FLTK. I think this is very unlikely. See (4) instead.
(4) Your TurboJPEG build uses other compiler and/or linker commands
which may result in different name mangling of the same function names.
It's hard to know what exactly this may be, I really don't know. You can
see the mangled function names in the error messages, for instance
"jpeg_mem_src@@YAXPAUjpeg_decompress_struct@@PBE@Z", but that will
probably not be helpful.
(5) The FLTK build uses the wrong jpeg library. I suggest that you
remove all build artifacts of previous builds and try to rerun your
build in a fresh build environment. Maybe you'll get other error
messages then. Hint: I recommend to do a full cleanup from time to time
anyway to find out if the entire build succeeds.
(6) Another option would be not to build fluid at all if you don't need
it yourself _and_ if you don't build the FLTK example (test) programs.
fluid is not required to build the stock FLTK libraries. However,
there's no option to disable the build of fluid - you'd have to patch
the FLTK CMake files yourself. I don't recommend this though, since it
wouldn't fix the cause of the problem.