FLTK logo

Re: [fltk.coredev] What does the "fluid-cmd" exe do on the WIN32 builds?

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: What does the "fluid-cmd" exe do on the WIN32 builds? Albrecht Schlosser Oct 01, 2022  
 
On 10/1/22 14:00 Ian MacArthur wrote:
All,

So, what *does* fluid-cmd.exe do?
It gets built by the cmake builds on Windows (the Makefile build doesn’t seem to build it?) but I cannot tell what it does - I can’t read cmake files very well, but it seems to be built out of the same things as “regular” fluid... and..?

The only difference is that it's a Windows Console (-mconsole) rather than a Windows GUI (-mwindows) executable. This was done on request (by Greg) because some fluid issues (e.g. not being able to access remote file systems or other errors) would not display an error message if built as GUI exe as it was before.

Anyway, I noticed this because a 32-bit mingw checkout choked at build for me - stuck in fluid-cmd.exe, just sitting there... indefinitely...

Sigh. This is something I experienced as well but it is not related to using fluid vs. fluid-cmd. I had this issue before and after the modification, and it happens sometimes but not every time I build FLTK with MinGW (MSYS2/mingw-w64 to be precise). I wonder if it has something to do with virus checking (Windows Defender) but I could never find it out. I tried to add a Defender exception but this didn't really work. I can usually see lots of CPU activity related to "virus checking" or whatever its name is while I'm building FLTK - unless I disable online virus checking entirely while building FLTK. Virus checking of the FLTK build is a PITA anyway (steals way too much CPU time and probably also disk activity).

Back to the original issue:
The symptoms are that some fluid instances seem to hang forever *after* the output files were written. If you build with `make -j3` it may happen that you have three (3) hanging fluid instances and then the build stalls. If you kill these fluid instances via the task manager the build continues but may hang later again. It's indeterminate AFAICT. I'm not sure if disabling virus checking really helps, I don't have enough test data.

When I experienced this issue first I terminated the build with ctrl/c and ran it again which continued often till the end. Hence this might help you too, but killing fluid instances via task manager was the most stable procedure for me so far. That said, my build about one hour ago executed successfully w/o hangs. Random, or should I say "Windows"?

Builds on other 32-bit machines didn’t show the issue, until I did a make clean, so when it then had to regenerate the various .fl files in the test directory, they too hang.

64-bit mingw builds appear to be immune (I need to check that properly though!) as did my recent msvc 32-bit IDE build.

I'm not sure but I would guess that this doesn't have to do with 32- vs. 64-bit. It might have to do with MSYS2/MinGW though. I never experienced such hangs in VS IDE build (VS 2019).

What is it, what’s it for, how/why is it different from “regular” fluid, etc.?
And why does it hang?

See above. It should not make a difference and it did not for me. Other Windows/MSYS2 magic seems to cause these hangs but I have no idea how to debug this (other than printf statements in fluid, maybe).

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/cdfb92aa-ee4a-4098-14d8-443ef92a941c%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.