On 1/29/23 09:03 Manolo wrote:
Continuing investigation …
The commit mentionned above introduces a call to Fl::add_fd()
in the constructor of class ExternalCodeEditor.
At least under macOS, this call implies to open the display.
The blocking occurs while attempting to open the display.
Thanks for continuing the investigation.
One might consider that Fl::add_fd() should be avoided by
fluid in command-line mode because the display
should not be opened in that mode. The problem is that
there's a global object created at static initialization time :
Fl_Code_Type Fl_Code_type; (see line 547 of
fluid/Fl_Function_Type.cxx)
and type Fl_Code_Type contains a member variable of type
ExternalCodeEditor.
Therefore, the constructor of class ExternalCodeEditor runs (and
calls Fl::add_fd() since the recent commit)
at static initialization time, also when fluid is in
command-line mode.
Related to this thread or not, Matt committed in these two commits:
commit
16af5f432e9f7cc62b7205d47c147e1fc5909e94
Author: Matthias Melcher <...>
Date: Sun Jan 29 13:49:37 2023 +0100
Avoid Linux warning
commit 85ac3d31474e48d0e84d2dd03b369e0e559e007e
Author: Matthias Melcher <...>
Date: Sun Jan 29 11:51:44 2023 +0100
FLUID: defer calling Fl::add_fd.
that fluid opens its communication pipe (and thus calls add_fd())
deferred, i.e. only when needed.
I built FLTK as before (configure/make), but with the current
commit(s) and: it works!
However, there are still issues. I can execute the test/demo
programs w/o issues (not all tested, but it looks so).
I can *not* execute `fluid/fluid` from the commandline (it hangs),
but I can run the **identical** executable (verified by `diff`) from
within the created bundle, like so:
`fluid/
fluid.app/Contents/MacOS/fluid` **and** I can successfully
run `/tmp/fltk/fluid/fluid`, i.e. the same executable with its full
path. Running it with a relative path `./fluid/fluid` doesn't work
either (hangs).
I still don't know **why** this happens on macOS (here: Ventura
13.1).
There's a notable difference between configure/make builds and CMake
builds (I didn't investigate this further, it's just an observation:
configure/make:
- fluid/fluid is a full executable file, the same as in the bundle
(which still hangs if executed)
CMake:
- bin/fluid is a shell script that executes the fluid executable
within the bundle (which doesn't hang).
Back to the original topic:
If the OP created their executables inside the /tmp folder it
**might** help to try running the executable with its full path,
maybe this works. Creating a macOS bundle and executing the bundle
(open
xxx.app) might also work, at least until it's clear why the
issue happens and whether this is intended behavior on macOS.
