Re: [fltk.general] FLTK as an external dependency in Bazel? - Forums

On Monday, 30 January 2023 at 07:54:17 UTC Manolo wrote:

On Jan 29, I started in this thread a sub-topic in reply to Albrecht's report on Jan 28 that FLTK building under macOS blocked with a certain but worked OK with another, earlier commit. "git bisect" allowed me to find what commit introduced this blocking. This commit (873d355) introduced a call to Fl::add_fd() at static initialization time in program fluid. It turned out this was the cause of the blocking:
- the building procedure builds and then runs program fluid to help build other programs;
- fluid erroneously calls Fl::add_fd() at static initialization time;
- specifically under macOS, Fl::add_fd() opens the display;
- for some reason which remains undetermined, an app run from /tmp may block
while attempting to open the display.

But, fluid should not open the display at static initialization time
because it must be usable in command line mode without access to a display.
Thus, Matthias removed from fluid, in a more recent commit (85ac3d3), the
call to Fl::add_fd() at static initialization time. In consequence, building
FLTK from /tmp no longer blocks. The sub-topic I opened is therefore to be
considered, I believe, closed and fixed.

Now, the main topic of this thread is, I believe, different.

Indeed so - though related by the fact that the underlying problem appears (as I understand it) to be that macOS _sometimes_ will not let an application show a window, if the app is invoked from a (private) /tmp folder.

Which seems strange - though, as Greg said, it does sound a lot like the sort of additional security layers that Apple have been adding.

If that is so, it must surely be affecting other projects too?

Doing transient work in /tmp is not _that_ unusual a thing to do, so there must be other projects hitting this change? (Assuming it is a change that Apple have introduced...)