Does anyone know how to link fltk in a windows 64bit environment

370 views
Skip to first unread message

roger tunnicliffe

unread,
Oct 18, 2022, 12:53:15 AM10/18/22
to fltk.general
I can get this to work in VisualStudio (only Debug NOT release) by copying the fltk solution and removing everything then adding in my program but I cannot get it to link via the command line.
My batch file does a call to 
C:\"Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat"

and my link options are those I have copied from VisualStudio 
..\_LINK\link /OUT:%1.EXE /NOLOGO /LIBPATH:"C:\USERS\ROGER\_DEV1\FLTK-1.3.8\LIB" FLTKD.LIB COMCTL32.LIB C:\USERS\ROGER\_DEV1\SOURCE\LANGUAGEONE\LIB\LANGUAGEONE.LIB LZ32.LIB WS2_32.LIB KERNEL32.LIB USER32.LIB GDI32.LIB WINSPOOL.LIB COMDLG32.LIB ADVAPI32.LIB SHELL32.LIB OLE32.LIB OLEAUT32.LIB UUID.LIB ODBC32.LIB ODBCCP32.LIB /NODEFAULTLIB:LIBCD /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /MACHINE:X64 fV3.04.OBJ V3.04.obj

I then get a squillion "unresolved external symbol" errors (which is what I also get in VisualStudio if I try and swap to Release rather than Debug.

Anyone able help ??
Cheers
Roger
P.S. Why is everything in Linux straight forward and easy and everything in windows is so difficult you'd just rather not do it !!

Greg Ercolano

unread,
Oct 18, 2022, 1:46:14 AM10/18/22
to fltkg...@googlegroups.com


On 10/17/22 21:53, roger tunnicliffe wrote:
I can get this to work in VisualStudio (only Debug NOT release) by copying the fltk solution and removing everything then adding in my program but I cannot get it to link via the command line.
My batch file does a call to 
C:\"Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat"

    It's important to be sure you use the same compile and link options
    that FLTK uses to build its own demos as you use to build your app.

    I personally use a Makefile on windows for both 32bit and 64bit, and when
    starting out, make sure I use all the same arguments for CL (the compiler)
    and LINK (link) that FLTK uses to build successful test programs, and then
    be sure to #include/link that same version of FLTK (and not against some
    other build of FLTK)

    You can find all those flags in the build logs for e.g. the "hello" test demo.

    Or, you can try to do everything within VS.
    This is always a painful process for me personally, as I really hate the VS IDE
    when it comes to configuring the compiler/linker; it's a freakin mess and a
    GUI is a horrible way to do this, since settings are scattered all over the place
    and move around from release to release of VS, but here it is lol:
    https://www.youtube.com/watch?v=wByIWVxJ6xU

    Perhaps most important in this is showing how to track down the location
    of the logs (which themselves are buried) so that you can find all those
    compiler flags. I purposefully did not edit out the friggin PITA this process is,
    as it's a crime to make it look easy, it's definitely not, lol.


and my link options are those I have copied from VisualStudio 
..\_LINK\link /OUT:%1.EXE /NOLOGO /LIBPATH:"C:\USERS\ROGER\_DEV1\FLTK-1.3.8\LIB" FLTKD.LIB COMCTL32.LIB C:\USERS\ROGER\_DEV1\SOURCE\LANGUAGEONE\LIB\LANGUAGEONE.LIB LZ32.LIB WS2_32.LIB KERNEL32.LIB USER32.LIB GDI32.LIB WINSPOOL.LIB COMDLG32.LIB ADVAPI32.LIB SHELL32.LIB OLE32.LIB OLEAUT32.LIB UUID.LIB ODBC32.LIB ODBCCP32.LIB /NODEFAULTLIB:LIBCD /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /MACHINE:X64 fV3.04.OBJ V3.04.obj

    I'm guessing no one is going to pick through all that, as each build of FLTK can be
    different depending on the cmake settings, install directories, etc.

    Just go for the FLTK build logs for one of the demo programs; test/hello
    should be the easiest. Just rebuild that one project and look at the logs.

    The compile flags are just as important as the link ones; a small missing flag
    on the compile flags will make the link not work. Flags like /MT are important.

    Once you get things working, you can then begin trimming away compiler/link
    flags you either don't like or think aren't needed after researching them.

roger tunnicliffe

unread,
Oct 18, 2022, 1:58:58 AM10/18/22
to fltk.general
Thanks Greg, I'll see if I can chip away at it.
Cheers
Roger
P.S. I can certainly agree with you on VisualStudio. Your use a simple "Hello World" program and get what seems like 10,000 lines of output. 

Ian MacArthur

unread,
Oct 18, 2022, 5:17:20 AM10/18/22
to fltk.general
On Tuesday, 18 October 2022 at 06:58:58 UTC+1 roger wrote:
 
Thanks Greg, I'll see if I can chip away at it.
Cheers
Roger
P.S. I can certainly agree with you on VisualStudio. Your use a simple "Hello World" program and get what seems like 10,000 lines of output. 

If you find VS (or IDE's in general) to be more of an obstacle than a help, then you probably just want to install MSYS2/mingw64 and use fltk from the command line in a "bash" shell, just like you typically would on Linux.
I find this generally quicker and easier than arguing with VS about how to build my code...
And the mingw tools can be used to build 32-bit and 64-bit code too, of course.
 
Message has been deleted

roger tunnicliffe

unread,
Oct 18, 2022, 4:09:46 PM10/18/22
to fltk.general
Another post disappeared..mmmmm.. I'll try again.
I did get this working Greg and you were right. I took the code from CL.command.1.tlog and link.command.1.tlog. I have no idea what the options are but hey, if they work they work.
I thought maybe the people involved with fltk might be interested in using the results for documentation so I have included the files that have worked for me.
Cheers
Roger.
Oh, and Ian. I'll take a look a look at MSYS2 but sadly I've put in a lot of effort into VisualStudio with my own project.
I really couldn't find any other debugger for windows that works. But on Linux DDD as a front end for GDB and your away. so simple.

mmm... seems I can't attach a ".bat" so here is the contents:-

call C:\"Program Files (x86)\Microsoft Visual Studio"\2019\Community\VC\Auxiliary\Build\vcvars64.bat
C:\"Program Files (x86)\Microsoft Visual Studio"\2019\Community\VC\Tools\MSVC\14.29.30133\bin\Hostx86\x64\cl /c %1.cxx @_staticComp
..\_LINK\link /OUT:%1.exe %1.obj %2.obj @_staticLink

_staticComp
_staticLink

Ian MacArthur

unread,
Oct 19, 2022, 4:16:18 AM10/19/22
to fltk.general
On Tuesday, 18 October 2022 at 21:09:46 UTC+1 roger wrote:
 
Oh, and Ian. I'll take a look a look at MSYS2 but sadly I've put in a lot of effort into VisualStudio with my own project.
I really couldn't find any other debugger for windows that works. But on Linux DDD as a front end for GDB and your away. so simple.

That's essentially the point of the MSYS/mingw toolchain - it *is* gcc and the related tooling, so you just debug with gdb and DDD and so on "as normal" and never have to  deal with the vagaries of the VS IDE at all...
Also it provides a "sh" compatible command line, of course, which is nice. 
(I know Greg would rather have C-shell than bash, but it takes all sorts...)

 

Mo_Al_

unread,
Oct 19, 2022, 7:51:42 AM10/19/22
to fltk.general
I think vcpkg deserves a mention. It's a C/C++ package manager by Microsoft. It contains an FLTK package (currently at version 1.3.8).
The process of installing it is quite simple (assuming you're running on cmd or powershell):
```
.\vcpkg\bootstrap-vcpkg.bat
.\vcpkg\vcpkg integrate install # this allows using vcpkg with visual studio
.\vcpkg\vcpkg install fltk:x64-windows
```
You won't need to modify any visual studio options: 

roger tunnicliffe

unread,
Oct 19, 2022, 4:29:41 PM10/19/22
to fltk.general
That would'nt  assemble MASM code though would it ?? I especially split my project into NASM(Linux) and (MASM)Windows because (and I hate to say this) VisualStudio's debugger handles langaugeONE better.
 I will however have a look at MSYS2 soon because I keep hearing about it.
Thanks for the heads up
cheers
Roger

Mo_Al_

unread,
Oct 20, 2022, 5:52:49 AM10/20/22
to fltk.general
vcpkg is just a package manager, you can still add your options to visual studio for your projects.

Greg Ercolano

unread,
Oct 22, 2022, 3:20:35 AM10/22/22
to fltkg...@googlegroups.com

On 10/18/22 13:09, roger tunnicliffe wrote:

On Tuesday, 18 October 2022 at 06:58:58 UTC+1 roger wrote:

    It's important to be sure you use the same compile and link options
    that FLTK uses to build its own demos as you use to build your app.

    I personally use a Makefile on windows for both 32bit and 64bit, and when
    starting out, make sure I use all the same arguments for CL (the compiler)
    and LINK (link) that FLTK uses to build successful test programs, and then
    be sure to #include/link that same version of FLTK (and not against some
    other build of FLTK)

    You can find all those flags in the build logs for e.g. the "hello" test demo.

Thanks Greg, I'll see if I can chip away at it.
 
I did get this working Greg and you were right. I took the code from CL.command.1.tlog
and link.command.1.tlog. I have no idea what the options are but hey, if they work they work.

    You can run "CL /HELP" and get the big list of all the compiler flags to get
    a short description of what they do, or a google search should get you
    the microsoft docs for the compiler flags that has more full description
    of the flags.

    Once you have a working Makefile, you can trim down the flags you don't
    think you need, to make simpler build lines. It's a good thing to reduce the
    flags down to only what you need, so you can see what's important.


I thought maybe the people involved with fltk might be interested in
using the results for documentation so I have included the files that have worked for me.

    The flags and paths are going to differ for each version of VS, build option
    (release vs debug vs 32bit vs 64bit, architecure variations, etc), so I don't
    think pasting these commands will help people build their own projects.
    This is why the compiler/link flags are never documented.

    We use to include static prebuilt VS project files in the FLTK distributions,
    but due to all the VS variations, that became unmaintainable; too many
    separate manually maintained project files for each VS version.

    Whenever a new file was added to FLTK, all those files had to be adjusted
    for each VS version.

    Which is why we use cmake now, which creates VS project files/Makefiles
    specific to each user's environment, as well as supporting other tool chain
    and compiler environments for not only Windows, but all the different platforms.

Reply all
Reply to author
Forward
0 new messages