RE: [fltk.general] Re: Buiding FLTK on VS2017 [General Use]

[MacArthur, Ian (Leonardo, UK)]

> On 05/01/17 17:00, Osman Zakir wrote:
> > Okay, I just found out where vcvarsall.bat is for VS2017. I just
> used it. I'll see how it goes now.
>
> How did you invoke it, with the amd64 or amd64_x86 argument?
> What was the resulting output when it opened the new DOS prompt?
> (It should announce the compiler bit configuration, IIRC)
>
> But note this for command line compiling VS, i.e. invoking
> CL and LINK directly from DOS.
>
> I'm not sure this is relevant if you're in the Visual Studio IDE.
> In that context, I believe the "Solution Platform" setting is
> what you'd be looking for.
>
> > Same problem, still. Except now it also can't find test.cxx for some
> reason.
>
> Sorry, without context, I don't know what that means.
>
> What is test.cxx, and what commands/techniques were you
> trying to compile it with; the IDE or from DOS with vcvarsall.bat
> set to one of the 64bit targets using CL and LINK?



Hmm, I'm puzzled by some aspects of all this.


From what we see in the more recent build logs posted by Osman Zakir, it *looks* like the stock IDE solution that we ship with fltk-1.3.4 is being run.

I thought that O.Z. had indicated they were using cmake to generate an IDE solution, not using the built-in IDE solution?


Note, in particular: The built-in solution we ship with fltk-1.3.4 is intended only for 32-bit builds. In my experience (VS2010 and VS2015) will offer to convert that from a 32-bit to a 64-bit solution for you; and so far, 100% of the time, the solution that conversion generates Does Not Work.
Indeed, it looks pretty much like what we see here, if I recall correctly.


So, for 64-bit builds, I *usually* just use mingw-64 at an Msys command line, which does work fine. But may have too high a barrier for entry...

However, by using cmake I have also generated 64-bit VS IDE solutions, which I have then used successfully (most recently with VS2015, not tried VS2017 yet) for fltk-1.3.4, and these have built fine from within the IDE - though the build order etc. looks slightly different to this, the outcome is Good.

And indeed, running "file" against the generated binaries reports them as "PE32+", which somewhat oddly is the correct type for 64-bit Windows binaries. So... it can work.


I'd caution against using the VS tools at the command line: I do it myself at times (though not to build the fltk libs) and I know Greg does for his products, but again the barrier to getting fltk built that way is pretty high.



As a rider; I wonder why the OP (Osman Zakir) feels the need of a 64-bit build?

On the Windows platform, there's no clear advantage to a 64-bit build unless you actually *need* to address an extended address space, which is rarely the case.

In my testing, 64-bit Windows binaries are, fairly consistently, larger and slower than the same code compiled 32-bit.

Further, the 64-bit build only runs on a small subset of all possible Windows machines (though admittedly that subset is getting to be larger now!) whereas a 32-bit build will run on "any" Windows machine.


In summary then; a 64-bit Windows build is not actually as useful as it might at first appear, at the present time. It may not be worth expending a lot of effort on, if the 32-bit build is working for you.



Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Osman Zakir]

To add to my previous message where I said that 64bit Release configuration has a problem where it can't find FLTK header files: the same thing is also happening with the 32bit Release configuration.

[Osman Zakir]

Well, my machine itself is 64bit, so I think I should try to get the 64bit configuration working.  

It'd been working fine for my user programs, but just now I stumbled into another wall.  For some reason, when I try to do a 64bit Release configuration, I keep getting error messages saying that FLTK header files can't be found.  I've set the path to the directory where I've put them in Properties > Configuration Properties > General > Additional Include Directories and I'm sure it's the correct path (C:\Program Files (x86)\fltk-1.3.4-1), but it still gives me the same error.  The 64bit Debug configuration compiles and links just fine in this regard.

Also, in the program I'm getting the errors in, there's also problem with a certain exception I'm catching in a try-catch block.  I can't see the message appear on my window.  Maybe my math for the points is wrong?  I want to show the code, but I'll also have to show the relevant .h and .cpp files that the author provided which I'm using FLTK through.  Should I show them all?

On Tuesday, May 2, 2017 at 1:53:54 PM UTC+5, MacArthur, Ian (Leonardo, UK) wrote:

[Albrecht Schlosser]

On 23.05.2017 13:37 Osman Zakir wrote:
> Well, my machine itself is 64bit, so I think I should try to get the
> 64bit configuration working.

That's not a valid (sufficient) reason by itself. As Ian pointed out,
32-bit executables under Window work sometimes better and faster than
64-bit executables. Only if you really need the extended address space
or if you need to link with 64-bit dll's you also *need* to use a 64-bit
executable.

> It'd been working fine for my user programs, but just now I stumbled
> into another wall. For some reason, when I try to do a 64bit Release
> configuration, I keep getting error messages saying that FLTK header
> files can't be found. I've set the path to the directory where I've put
> them in Properties > Configuration Properties > General > Additional
> Include Directories and I'm sure it's the correct path (C:\Program Files
> (x86)\fltk-1.3.4-1), but it still gives me the same error. The 64bit
> Debug configuration compiles and links just fine in this regard.

Without checking this, ISTR that these settings all depend on the
configuration which makes some sense if different configurations (Debug,
Release) need to link to different libraries etc.. So please check if
the correct linker path and libs are still configured in each
configuration you use.

Hint: if you configure your own projects with CMake you can do all this
in only one place and don't need to point-and-click through all these
fancy MS menus.

> Also, in the program I'm getting the errors in, there's also problem
> with a certain exception I'm catching in a try-catch block. I can't see
> the message appear on my window. Maybe my math for the points is
> wrong? I want to show the code, but I'll also have to show the relevant
> .h and .cpp files that the author provided which I'm using FLTK
> through. Should I show them all?

This is an entirely different subject. Please start another thread
(something like 'new subject' or whatever in your mail program or google
groups) to keep the context clean.

> On Tuesday, May 2, 2017 at 1:53:54 PM UTC+5, MacArthur, Ian (Leonardo,
> UK) wrote:

AND, IMPORTANT: Please don't top-post in this mailing list. We request
inline (interleaved) citations and your own text and we ask users to
trim citations to only relevant parts. See my post above. Thank you.

[MacArthur, Ian (Leonardo, UK)]

> Well, my machine itself is 64bit, so I think I should try to get the
> 64bit configuration working.

I'm not sure I really follow the logic there.
Unless you actually need the extended address space that 64-bit brings (and almost nobody does!) then the 32-bit executables are actually more "useful" since they run on "any" Windows machine, whereas the 64-bit exe can only run on a 64-bit Windows machine.
In general the 32-bit exe will be smaller, and in a lot of cases (due to its reduced memory footprint) it will also run faster, so the "benefits" of 64-bit executables under Windows are somewhat illusory.

(So far as I can tell, the main purpose of 64-bit PC's is to sell new boxes; it is far from clear that there is substantial end-user benefit at this stage.)

However, if you want to do it, here's what I did to get a 64-bit VS build the other night. Note that I have cmake installed in my path.

Firstly, I open a "developer console" from within VS. In that console, I cd to a clean fltk tarball that I have unpacked. Then:

- mkdir build-MSx64 # to create a build directory to work in.
- cd build-MSx64
- cmake -G "Visual Studio 14 2015 Win64" .. (note the ".." at the end there; that is needed!)
(I'm doing this from memory, so that generator string may be wrong! Check it.)

That should cause cmake to run and generate a solution fltk.sln in the build-MSx64 folder; open that fltk.sln from the VS IDE, and before you build it, right click on the solution, go into the configuration options and set it to release mode.
Now right clock the solution again and choose build.

For me, that Just Works and generates a valid, 64-bit release build. I've done this on a few different machines and it's been pretty consistent, so if it's not working for you... well, I do not know; something must be broken. Is there something odd or irregular about your set up?

> It'd been working fine for my user programs, but just now I stumbled
> into another wall. For some reason, when I try to do a 64bit Release
> configuration, I keep getting error messages saying that FLTK header
> files can't be found. I've set the path to the directory where I've
> put them in Properties > Configuration Properties > General >
> Additional Include Directories and I'm sure it's the correct path
> (C:\Program Files (x86)\fltk-1.3.4-1), but it still gives me the same
> error. The 64bit Debug configuration compiles and links just fine in this regard.

> Also, in the program I'm getting the errors in, there's also problem
> with a certain exception I'm catching in a try-catch block. I can't
> see the message appear on my window. Maybe my math for the points is wrong?

Is exception handling enabled for the VS builds of fltk? I do not know.

I do know that the gcc-based builds of fltk (on all platforms, including Windows) disables exception support since the fltk library does not use it. (Adding exception support bulks up the lib a lot, which is wasteful if we are not using it.)

It may be that, if you are using the compiler options that fltk sets, it is disabling your exception code?

Though to be honest I'd expect that to throw a warning (or error) at compile time, rather than to just fail silently.

[Osman Zakir]

Only my Release configurations show those header file errors, whether it be for x86 or x64.  Debug configuration shows no compiler or linker errors.  That's the problem I'm facing on this right now.

I know that exceptions should be working for me because I've managed to have error messages for the exceptions I catch appear on my window as Text objects before.  That's why I thought maybe I was doing something wrong this time.  

[Osman Zakir]

Oh and, before I forget: I saved a .txt file with info on the FLTK library code that's triggering the exception, as well as the uncaught exception error message VS gives me if I don't catch the exception.  I've attached the file to this message.

On Tuesday, May 23, 2017 at 6:27:41 PM UTC+5, MacArthur, Ian (Leonardo, UK) wrote:

[Albrecht Schlosser]

YOU ARE STILL TOP-POSTING! PLEASE, PLEASE STOP THIS!

On 23.05.2017 20:36 Osman Zakir wrote:
> Only my Release configurations show those header file errors, whether it
> be for x86 or x64. Debug configuration shows no compiler or linker
> errors. That's the problem I'm facing on this right now.

Did you read my post at all? Okay, maybe it was not clear enough or you

didn't understand... Here is the main point again. I wrote:

> Without checking this, ISTR that these settings all depend on the
> configuration which makes some sense if different configurations (Debug,
> Release) need to link to different libraries etc.. So please check if
> the correct linker path and libs are still configured in each
> configuration you use.

The point is: you must check *each* configuration because the *setting*
is per configuration. This explains why the Debug configuration works
and other configurations don't. Please check again: choose the Release
configuration, then go to the linker and compiler settings, and check if
the FLTK library locations are set correctly. Compare the settings in
Release configuration with those in the Debug configuration.

> On Tuesday, May 23, 2017 at 6:27:41 PM UTC+5, MacArthur, Ian (Leonardo,
> UK) wrote:

PS: If you continue to top-post and to reply to different posts of
different users in one post without enough context so that it is
difficult to get the correct context I may decide not to reply to your
posts any longer. I'm sorry to say that, but it's really hard to
understand what exactly you are replying to. If you still don't know
what top-posting is, please ask here or use the search engine of your
choice. Look also for 'netiquette'. Thanks.

[Greg Ercolano]

> On 23.05.2017 20:36 Osman Zakir wrote:

On 05/23/17 14:34, Albrecht Schlosser wrote:
> YOU ARE STILL TOP-POSTING! PLEASE, PLEASE STOP THIS!

+1

Osman: please reply /below/ other people's replies
when including quoted text. A lot of this is very hard
to follow because of how the continuity jumps around.

[Osman Zakir]

I hit the arrow next to your post when replying to you.  How did it still top-post?  Maybe it'll help if I remove all of the quoted posts below my message?

Anyway, where are you saying I should check the settings?  I've already made sure that the correct path is specified for my include directories in all configurations.  Everything's the same for the include directory path in each configuration.  I put it in Additional Include Directories and it's the path to where my FLTK headers are.  I don't get why it can't find them.  I put in this path: "C:\Program Files (x86)\fltk-1.3.4-1".  Do I need a different location for the headers that the Release configuration would need?

[Albrecht Schlosser]

On 24.05.2017 08:58 Osman Zakir wrote:
> I hit the arrow next to your post when replying to you. How did it
> still top-post? Maybe it'll help if I remove all of the quoted posts
> below my message?

Not all of the quoted posts and not _below_ your message. Leave as much
of the quoted text as we need to understand what you're replying to and
edit your reply below (between) the quoted text. As you can see here.

> Anyway, where are you saying I should check the settings? I've already
> made sure that the correct path is specified for my include directories
> in all configurations. Everything's the same for the include directory
> path in each configuration. I put it in Additional Include Directories
> and it's the path to where my FLTK headers are. I don't get why it
> can't find them. I put in this path: "C:\Program Files
> (x86)\fltk-1.3.4-1". Do I need a different location for the headers
> that the Release configuration would need?

No, it's the same for all configurations with FLTK. What are the exact
error messages? Please copy at least one (or more if they differ) into
your next reply. It would be really strange if the compiler couldn't
find the headers if this is the correct path. However, is this really
the correct path? The FLTK sources should usually not be in "C:\Program
Files (x86)\...". They should be somewhere in your user directories
where you have full read/write access as a normal user. Did you
"install" the FLTK library in "C:\Program Files (x86)\fltk-1.3.4-1"?

[Osman Zakir]

It's been in that same directory the whole time and there've been no problems until now.  And even now it's only happening with Release configurations.  

[Osman Zakir]

I moved the FLTK source files to C:\Users\Osman, and set the Additional Include Directories path to the new path, but I'm still having the same problem with the Release configurations.

On Wednesday, May 24, 2017 at 2:26:07 PM UTC+5, Albrecht Schlosser wrote:

[Osman Zakir]

Okay, I figured it out.  It was my own silly mistake.  I had to set the configuration to the Active Configuration in the Property pages and then set the Additional Include Directories.  It doesn't matter if it's in C:\Program Files (x86) or not.  I'll make another thread for that exception problem now.