FLTK as an external dependency in Bazel?

[Zsolt Pajor-Gyulai]

I've been trying to integrate FLTK with my Bazel project on a MacOS Ventura 13.0.1. I'm using the following file to test whether I succeeded:
``` - test.cpp

#include <FL/Fl.H>

#include <FL/Fl_Box.H>

#include <FL/Fl_Window.H>

int main() {

Fl_Window window(200, 200, "I am a window");

Fl_Box box(0,0, 200, 200, Hello World");

window.show();

return Fl::run();

}

```

If I do 

```

brew install fltk

```

and use a makefile:

```

CC = clang++

CFLAGS = -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -lfltk -lpthread -framework Cocoa

INCLUDE_FLTK = -I/opt/homebrew/Cellar/fltk/1.3.8_1/include

LINK_FLTK = -L/opt/homebrew/Cellar/fltk/1.3.8_1/lib

INCLUDE_GUI = -I/Users/zsolt/Dropbox/Work/Learning/CompSci/C++/PPPuC++/GUI/

LINK_GUI = -I/Users/zsolt/Dropbox/Work/Learning/CompSci/C++/PPPuC++/GUI/

test:

@$(CC) $(INCLUDE_FLTK) $(LINK_FLTK) $(CFLAGS) -o test.out test.cpp

@./test.out

@make clean

clean:

$(RM) *.out

```

then everything works fine and my window pops up. However, if I now try to replicate it in bazel, for example by following this approach, then I can get everything to build successfully with the exception that `Fl::run()` just hangs without producing any output.

t

2. 

[Albrecht Schlosser]

On 1/24/23 07:56 Zsolt Pajor-Gyulai wrote:

I've been trying to integrate FLTK with my Bazel project on a MacOS Ventura 13.0.1.

I'm sceptical that anybody here can help you with a Bazel project. We suggest to use CMake.

However, I may be wrong and someone can help. Please be patient...

I'm using the following file to test whether I succeeded:
 - test.cpp

OK, that would open an empty window. If you want to display the text in the box you should assign a boxtype, like
```
  box.box(FL_FLAT_BOX);
```

But that doesn't seem to be your issue (maybe).

If I do 

```

brew install fltk

```

and use a makefile: [...]

then everything works fine and my window pops up. However, if I now try to replicate it in bazel, for example by following this approach, then I can get everything to build successfully with the exception that `Fl::run()` just hangs without producing any output.

What do you mean with "without producing any output"? Does an empty window appear or not?

Sorry, I can't help with bazel. I looked at your document but I can't tell what exactly it is doing.

One hint may be to use the FLTK source (downloaded from Git) to build the development version 1.4.0 (master), build it yourself, and try with that. But using the latest FLTK version wouldn't explain why it (homebrew, FLTK 1.3.8) works with a Makefile and not with bazel.

[Zsolt Pajor-Gyulai]

> What do you mean with "without producing any output"? Does an empty window appear or not?

Sorry, I should have made it clearer, no window appears whatsoever.

> One hint may be to use the FLTK source (downloaded from Git) to build the development version 1.4.0 (master), build it yourself, and try with that. But using the latest FLTK version wouldn't explain why it (homebrew, FLTK 1.3.8) works with a Makefile and not with bazel.

Thanks, I will try 1.4.0. My best bet is that it only appears to hang
and it is "displaying the window somewhere" waiting for me to close
it. I will also try to ask on a bazel forum to see if it would be
blocking the output, I will post back here if I find a solution.

> --
> You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/miGhgA3y0xE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/30973393-b4e5-65d5-0459-9b1a07b8ce71%40online.de.

[Mo_Al_]

Are you perhaps launching the gui or running the build from the /tmp dir?

[Albrecht Schlosser]

On 1/28/23 20:47 Mo_Al_ wrote:
> Are you perhaps launching the gui or running the build from the /tmp dir?

Hmm, now I'm curious. Do you think that this might change anything, is
there anything we should know?

I just started an FLTK program from the /tmp dir and it worked as
expected. I'm puzzled.

[Mohammed]

It’s a peculiar thing I’ll admit. it was reported in the fltk-rs repo:

Also check the linked issue in vcpkg (C++). 

Sent from my iPhone

On 28 Jan 2023, at 23:53, Albrecht Schlosser <Albrech...@online.de> wrote:

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/f6e7333a-2248-7cec-54ad-3d3d96952b5f%40online.de.

[Mohammed]

The comment after the build fix but the gui not showing. It seems peculiar to the macos tmp dir!

Sent from my iPhone

On 29 Jan 2023, at 00:01, Mohammed <may64...@gmail.com> wrote:



[Albrecht Schlosser]

On 1/28/23 22:01 Mohammed wrote:

It’s a peculiar thing I’ll admit. it was reported in the fltk-rs repo:

Oh, that's getting funny! ;-)

??? Not really.

Long story short: building FLTK inside/below /tmp on macOS Ventura 13.1 (MacBook Air M1) and launching apps works ... sometimes. Crazy!

OK, to test this, my first step was:
```
git worktree add /tmp/fltk
cd /tmp/fltk/
make -j7
test/hello
open test/hello.app/
```

Worked like a charm! Note that the first command checks out a "worktree" from the current Git working tree to /tmp/fltk.

So, why does it work here?

Checked: this was an older Git commit: 4bff15278e83616e4da6be9d36ed05c0c949545b from Jan 5, 2023.

OK, checking out the latest commit: 86a0a288152da0d3891ae67f56fd88014f6787f5, then running:
```
make distclean
make -j7
...
Generating keyboard_ui.cxx ... etc.  --- HANGS
```

Hmm, running `make -j1` or `make -k -j5` and other variations reveals: it hangs in `fluid` (as expected).
Even `make -j77` hangs.

Running `fluid -c any.fl` manually hangs too.

So what ... ?

Next try: Building with CMake and Ninja (default configuration): works flawlessly. I can run all test and demo programs I tested, including glpuzzle. `fluid -c` and interactive `fluid` work fine.

Conclusion: I don't know. Strange things are going on. Did I find a bug in macOS? Maybe, since I **can** run GUI programs built in /tmp with CMake ! ;-)

One more point: building with CMake + make (instead of ninja) works as well. I have no idea what's going on.

Sorry, that's it for tonight from me. Maybe someone else who knows more about macOS (Manolo?) can take a look.

Good night from here.

[Manolo]

Le dimanche 29 janvier 2023 à 00:02:51 UTC+1, Albrecht Schlosser a écrit :

OK, checking out the latest commit: 86a0a288152da0d3891ae67f56fd88014f6787f5, then running:
```
make distclean
make -j7
...
Generating keyboard_ui.cxx ... etc.  --- HANGS
```

I've continued the investigation with git bisect. The first bad commit is 

=====================

% git bisect good
873d355ec271b22f0e48dac1c8eaca7deb075e66 is the first bad commit
commit 873d355ec271b22f0e48dac1c8eaca7deb075e66
Author: Matthias Melcher
Date:   Fri Jan 27 11:35:05 2023 +0100

    FLUID: fixe external command alert on Unix

 fluid/ExternalCodeEditor_UNIX.cxx | 34 +++++++++++++++++++++++++++++++++-
 fluid/ExternalCodeEditor_UNIX.h   |  6 ++++++
 2 files changed, 39 insertions(+), 1 deletion(-)

====================

[Manolo]

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.

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.

[Albrecht Schlosser]

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.

[Manolo]

Le dimanche 29 janvier 2023 à 16:08:34 UTC+1, Albrecht Schlosser a écrit :

Related to this thread or not,

that is definitely related to this thread! (see comments to the first commit)

 

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.

 

The problem was that a recent commit made fluid call Fl::add_fd() in a static initializer thread.
For some reason, Fl::add_fd() opens the display, specifically on macOS, not on other platforms.

Matt removed this early call to add_fd().

I find the problem of hanging build process to be fixed now.

Hopefully that also solves the OP's problem.

[Zsolt Pajor-Gyulai]

Thank you for going down my rabbit hole. Bazel  runs things from the bazel cache which might include symlinking some tmp directories.

I found the compiled binaries and running it directly blocked the window as well.

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/miGhgA3y0xE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/e9fd90c5-3fd0-f43a-4c08-a986bd318802%40online.de.

[Zsolt Pajor-Gyulai]

The problem was that a recent commit made fluid call Fl::add_fd() in a static initializer thread.
For some reason, Fl::add_fd() opens the display, specifically on macOS, not on other platforms.

Matt removed this early call to add_fd().

I find the problem of hanging build process to be fixed now.

Hopefully that also solves the OP's problem.

I might be too uninitiated, but what is the suggested solution? To use the dev version 1.4.0?

[Manolo]

Le dimanche 29 janvier 2023 à 19:23:05 UTC+1, pgy...@gmail.com a écrit :

I might be too uninitiated, but what is the suggested solution? To use the dev version 1.4.0?

The recent posts deal with a recently introduced regression in FLTK 1.4 and its correction.
If the original problem was with FLTK 1.3, then recent posts are unrelated to this problem.

In all cases, FLTK 1.4 is highly recommended.

[Greg Ercolano]

    I'm coming in late here, but I see MacOS and /tmp being at issue, and it's possible
    Apple's weird new permission stuff might be getting triggered here?

    The /tmp directory has weird perms already (prevents users from accessing each other's tmp files),
    and there's all that new lower level permission stuff Apple's been adding over the last few years,
    not just with xattr(), but also with all that new stuff above and beyond unix permissions that involves
    the System Prefs -> Security screen, which gives individual executables access to specific devices
    (like microphones, cameras, etc), which include specific disk volumes. Perhaps apps need special
    access to /tmp?

    Anyway, to detect this "new" security stuff, you have to use the /System/Applications/Utilities/Console
    to monitor these errors while the app is running, as such errors often don't get reported via
    traditional unix mechanisms like errno and strerror(), and often post dialogs asking for access
    to things.

    So if you suspect weird new Apple security stuff, first run the Console app (mentioned above),
    and hit "Start streaming", then run your app and watch for weird error messages about your
    app in the console.

    The console is /very/ chatty, so you have hit "Pause" so you can scroll around or Copy/Paste
    into an editor to find errors/warnings related to your app. Apple's error messages in this log
    about the new privacy stuff are often quite clear about what the security/privacy problem is,
    and it can sometimes be related to how the process was started, and what limitations are set
    in place for that. For instance often the /bin/sh or /bin/bash has limitations on it that prevent
    users from running things from that shell.

[Albrecht Schlosser]

There are several suggestions. Everything we found out was about *building* FLTK in /tmp or a subdirectory of /tmp. If you didn't do this, it's probably not an issue, unless ...

In your previous post you wrote: "I found the compiled binaries and running it directly blocked the window as well."

Here are two questions:

(1) *where* did you find them, i.e. was this in or under /tmp?

(2) *how* did you "run the binaries directly"?

If these binaries are *not* inside /tmp then there's probably another problem, but *if* they are inside /tmp, read on:

First recommendation: check out the latest FLTK from git branch 'master' to get the latest fixes and build FLTK again.

Second recommendation: if Bazel can do it - or if you can do it yourself - create a macOS "bundle" and run the binaries from this bundle, for instance by `open my_prog.app`. You can also run a binary from within a bundle, for instance with `fluid` in the build directory 'fluid/fluid.app/Contents/MacOS/fluid'. This works for me, whereas 'fluid/fluid' would hang - although these binaries are really identical (checked with diff).

Third recommendation: copy the binaries to a place inside your home directory and run them from there.

Fourth recommendation: run the binaries with their *full* path, e.g. '/tmp/fltk/fluid/fluid'.

You can help us helping you and others if you try all recommendations and report whether each one works for you. Thanks in advance.

[Albrecht Schlosser]

On 1/29/23 19:47 Greg Ercolano wrote:
> I'm coming in late here, but I see MacOS and /tmp being at issue, and
> it's possible
>     Apple's weird new permission stuff might be getting triggered here?
>

>     [...] Perhaps apps need special access to /tmp?

Side note: it looks like "/tmp" is in reality "/private/tmp" which looks
like one of these mechanisms to make things really "private". I found
this out (accidentally) by using test/demo, enabling the "debug
terminal" and watching the output. Somehow "demo" gets the "real"
directory string. This may or may not have to do anything with the issue...

> Anyway, to detect this "new" security stuff, you have to use the
> /System/Applications/Utilities/Console
>     to monitor these errors while the app is running, as such errors
> often don't get reported via
>     traditional unix mechanisms like errno and strerror(), and often
> post dialogs asking for access
>     to things.

Great hint, thanks!

>     So if you suspect weird new Apple security stuff, first run the
> Console app (mentioned above),
>     and hit "Start streaming", then run your app and watch for weird
> error messages about your
>     app in the console.
>
>     The console is /very/ chatty, so you have hit "Pause" so you can
> scroll around or Copy/Paste
>     into an editor to find errors/warnings related to your app.

I used the "search" feature and selected either "Process" fluid or "PID"
and its PID. See attached logs.

> Apple's error messages in this log
>     about the new privacy stuff are often quite clear about what the
> security/privacy problem is,
>     and it can sometimes be related to how the process was started,
> and what limitations are set
>     in place for that. For instance often the /bin/sh or /bin/bash has
> limitations on it that prevent
>     users from running things from that shell.

I can't find anything useful in these logs which I'm attaching. In both
logs 'fluid' is started, once by running `fluid/fluid` (relative path:
this hangs) and the other by `/tmp/fltk/fluid/fluid` (full path: works).
Maybe someone else can see what's happening or can test on their
system(s). Mine is macOS Ventura 13.1 on MacBook Air (M1).

The names of the logs are self-explanatory, and as far as I can see they
are very similar until the "hanging" fluid stops. Notable difference:
the "working" process issues "SetFrontProcess: asn= options=1" somewhat
later than the hanging process - and continues to work and logs more
messages.

Maybe someone else can find the underlying issue and maybe even find a
workaround?

Maybe it *has* to do with the hidden "/private" in the working directory
and app directory before "/tmp"?

[Albrecht Schlosser]

On 1/29/23 21:29 Albrecht Schlosser wrote:
> I can't find anything useful in these logs which I'm attaching. In
> both logs 'fluid' is started, once by running `fluid/fluid` (relative
> path: this hangs) and the other by `/tmp/fltk/fluid/fluid` (full path:
> works). Maybe someone else can see what's happening or can test on
> their system(s). Mine is macOS Ventura 13.1 on MacBook Air (M1).
>
> The names of the logs are self-explanatory, and as far as I can see
> they are very similar until the "hanging" fluid stops. Notable
> difference: the "working" process issues "SetFrontProcess: asn=
> options=1" somewhat later than the hanging process - and continues to
> work and logs more messages.
>
> Maybe someone else can find the underlying issue and maybe even find a
> workaround?
>
> Maybe it *has* to do with the hidden "/private" in the working
> directory and app directory before "/tmp"?

Here's a new observation: there seems to be some kind of deadlock, or
our process waits for something to happen.

I did the following:

(1) execute fluid/fluid - hangs
(2) close notebook lid (suspends macOS ?)
(3) open notebook lid - yeah, the fluid window is there and works!!

As I said, maybe some kind of deadlock that's resolved by a system
message that "awakes" the fluid process?

See attached and commented log. This is something for someone more
familiar with macOS, maybe Manolo?

To make clear what I did, here's a summary from memory:

1. create git worktree or clone a fresh FLTK source tree in /tmp/fltk
(or another dir under /tmp)
2. cd to /tmp/fltk
3. make [-j7]
4. launch `fluid/fluid` - this hangs
5. suspend macOS (closing the notebook lid) - or maybe something else?
6. open the notebook: the window appears and is responsive

I also tried `cd /private/tmp/fltk` but - although `pwd` reports it
correctly - it doesn't change anything.

I remember that I backgrounded the running and hanging fluid process by
typing 'ctrl/z'. Some time later I foregrounded the process ('fg') and
the window appeared. However, I could not reproduce this when I tried
again. I can't tell what happened while the fluid process was
backgrounded and waiting. Maybe I had closed the notebook meanwhile, but
that's only a guess, I can't remember.

Manolo, is this of any help to find what's causing the window to not
appear when a process is launched
(a) under /tmp
(b) from the shell with a *relative* path
(c) from a bare binary, not inside a bundle

Using the full path to run fluid or running the binary from the bundle,
or copying it somewhere else, all this seems to "heal" the effect.

Really weird!

[Zsolt Pajor-Gyulai]

Just checked where the bazel cache physically is and it is:

/private/var/tmp/_bazel_zsolt

most likely I'm having the same issue as the one you are discussing.

> (1) execute fluid/fluid - hangs
> (2) close notebook lid (suspends macOS ?)
> (3) open notebook lid - yeah, the fluid window is there and works!!

I played with this and it did work! Not exactly my desired dev
workflow though :)

> --
> You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/miGhgA3y0xE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/08830632-2151-dfed-7772-79d134ddc939%40online.de.

[Albrecht Schlosser]

On 1/29/23 23:37 Zsolt Pajor-Gyulai wrote:
> Just checked where the bazel cache physically is and it is:
>
> /private/var/tmp/_bazel_zsolt
>
> most likely I'm having the same issue as the one you are discussing.
>
>> (1) execute fluid/fluid - hangs
>> (2) close notebook lid (suspends macOS ?)
>> (3) open notebook lid - yeah, the fluid window is there and works!!
> I played with this and it did work! Not exactly my desired dev
> workflow though :)

Sure, I noticed your smiley, but anyway: this thread developed to serve
two purposes:

(1) help you and other users to see what's happening and find a workaround
(2) analyse the problem to (hopefully) find a solution if this is
something we can solve.

Thank you for confirmation of my "trick", this may help to find the root
cause and to apply a fix, if possible. macOS has always some new
"features" we must be aware of.

[Zsolt Pajor-Gyulai]

Thank you for looking into it!

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/miGhgA3y0xE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/c2dcef94-3c90-1ce3-855b-964f97b01114%40online.de.

[Manolo]

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.

[Ian MacArthur]

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...)

[Matthias Melcher]

Ok, even later to the game.

Sorry about the Fl::add_fd() issue. I had no idea about the side effects. I have now moved that call, so Fl::add_fd() will not be called until the user actually launches and external editor. This should no longer interfere.

When I read that launching FLUID from /tmp will lock up, I couldn't believe it. But I checked, and yes, it's true. I attached the debugger and it hangs in `void Fl_Cocoa_Screen_Driver::open_display_platform()`, calling `[NSApp run];`, 1728 in Fl_cocoa.mm. Since it wasn't able to open a window, it will hang here forever, waiting for messages from that not existing window.

So the issue must be when creating the window, maybe not having permission to do that. I tried other apps from the test directory, and they have the same issue! FLUID in command line mode in /tmp however runs fine for me.

Looking at the Console output (scary stuff...), it seems that apps get a "Darwin Role" assigned by the "RunningBoard" which determines if an app interactive, but launched from "/tmp", FLUID's role is "Set darwin role to: NonUserInteractive". This looks very suspiciously like one of those boxes that Pandorra keeps throwing at me, and I am somewhat reluctant to open it.

cp build/Xcode/bin/Debug/fluid.app/Contents/MacOS/fluid /tmp

cd /tmp

./fluid  (hangs)

./fluid -h   (works)

./fluid -u test.fl   (works)    

[Matthias Melcher]

Just for completeness, the FLUID process that I started 1h ago did eventually pop up the toolbox window! It did not show in the toolbar or anywhere else, so I could not raise the rest of the UI, and had to kill it in the Activity Monitor. Huh!

[Manolo]

Problems to launch unbundled macOS apps from /tmp should be fixed with commit 1045538

[Greg Ercolano]

On 1/30/23 11:16, Manolo wrote:

Problems to launch unbundled macOS apps from /tmp should be fixed with commit 1045538

    Oh wow, I didn't know unbundled macOS apps could work at all.

    Back in ye olde days running an unbundled app (just the executable, no .app directory)
    did all kinds of weird window behavior things.

    So that "works" now? Sounds great if so.
    I always thought that was kinda weird when it didn't work just because it couldn't
    find those minimal plist files.

[Albrecht Schlosser]

On 1/30/23 20:16 Manolo wrote:
> Problems to launch unbundled macOS apps from /tmp should be fixed with
> commit 1045538

Great, tested and works like a charm!

Thank you very much!



@Lukas: if you can't pull from Git [1], the next snapshot is due on
Friday morning, at about 08:00 CET (as every week). Please report if
this helps with your Bazel issue as well.

[1] You can always download a zip file as of the latest commits from
GitHub. Go to https://github.com/fltk/fltk and click on the green "Code"
button and then on "Download ZIP".

[Albrecht Schlosser]

On 1/30/23 21:15 Albrecht Schlosser wrote:
>
> @Lukas: if you can't pull from Git [1], the next snapshot is due on
> Friday morning, at about 08:00 CET (as every week). Please report if
> this helps with your Bazel issue as well.

Sorry, this should read "at about 08:00 UTC", or if you like 8 am UTC.

[Albrecht Schlosser]

Sorry for yet another correction:

On 1/30/23 21:21 Albrecht Schlosser wrote:
> On 1/30/23 21:15 Albrecht Schlosser wrote:
>>
>> @Lukas: if you can't pull from Git [1], the next snapshot is due on
>> Friday morning, at about 08:00 CET (as every week). Please report if
>> this helps with your Bazel issue as well.
>
> Sorry, this should read "at about 08:00 UTC", or if you like 8 am UTC.

... and the OP's name is Zsolt, sorry, not Lukas (I had just read
another thread).

[Matthias Melcher]

Allright! Verified. Works.

[Manolo]

===== reply ====

FLTK supports unbundled macOS apps. SInce macOS 10.13 (2017), FLTK needs to start

the event loop of unbundled apps differently than what it does for bundled ones:

        [NSApp finishLaunching];

vs

        [NSApp run];

This requires that FLTK detects at run time whether a bundled or unbundled app

is being started.That is done comparing two folder paths, and when the unbundled app

is /tmp/fltk/prog, the comparison became "/tmp/fltk" vs "/private/tmp/fltk" which

were detected as different although they actually refer to the same folder. Then,

the event loop starting means adequate for bundled apps was used, and blocked the app.

This is now fixed.

[Zsolt Pajor-Gyulai]

Thank you all, this did the trick for me too!

To close out, I wanted to commemorate how I ended up using FLTK with
bazel as it was some trial and error. Just in case it's useful for
someone else too.

1. Clone FLTK from repo
2. Build with ./configure and make.
3. Add BUILD file in fltk checkout with content:
```
cc_library(
name = "fltk",
hdrs = glob(["FL/*.h", "FL/*.H"]),
srcs = glob(["lib/*.a"]),
includes = ["."],
linkopts = ["-Lfltk/lib", "-lfltk_forms", "-lfltk_gl", "-lfltk",
"-lfltk_images", "-lfltk_jpeg", "-lfltk_png", "-lfltk_z", "-lm",
"-ldl", "-lpthread", "-framework Cocoa"],
visibility = ["//visibility:public"],
)
```
4. reference it as `//path/to/fltk:fltk`.

There is probably a more elegant way, but it works.

Thanks again!

> --
> You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/miGhgA3y0xE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/8dea607a-387d-4e83-86b5-b521c0886e22n%40googlegroups.com.