After talking to Jeff I noticed that DISABLE_NCURSES from the Android branch has been merged now, which is good since it covers what I had in mind with DISABLE_TERMCAP. Plus, the DISABLE_NCURSES patch made be notice that I disabled more parts of fb_hInit() than necessary in my DISABLE_TERMCAP patch....

Probably not, unfortunately. fbfrog has almost no C++ support. I'm not even sure whether FB itself has enough C++ support to be compatible to Qt or even the C++ standard library (lack of templates and multiple inheritance...).

Yea, it's -nolib a,b,c as you had suggested. I've put that into the fbc --help output and the man page, and if this pull request is accepted I'll update the wiki docs too. I've been using -nolib ncurses,tinfo to test some other changes (rtlib without requiring termcap/ncurses/libtinfo, but those are...

Well, our patches aren't the same: I wrote the termcap stubs to keep as much working as possible by returning success codes so rtlib's hInit() continues through the normal setup. getkey, multikey, inkey, fb_keyhit, getmouse, color, width (and the SIGWINCH and other signal handlers) and disabling of...

Opened a pull request now, where I'm proposing a -nolib option. It can override default libs or any others such as from #inclib.

Interesting, that's the same as my DISABLE_TERM attempt and the termcap function stubs . Good to know that an rtlib compile-time option like DISABLE_TERM/TERMINFO/NCURSES is needed anyways for portability. I see no problem having it, as long as it's not necessary to build & deploy every possible...

The FB runtime has a global destructor, but unfortunately it's not always the last one, sometimes another FB runtime (in a shared library or another process) ends up being last instead. But yea, multi-threading is also a problem (with regards to the internal state capture and the temporary re-config...

Hey again, I've experimented a bit, here are the results... 1. libfb without terminal support (DISABLE_TERM): PRINT and perhaps INKEY still work, but with reduced feature set, and basically nothing else related to console works (no LOCATE, COLOR, VIEW, CLS, etc.). This allows disabling more than jus...

After thinking about this a bit more, I feel like -nodeflibs might already be good enough. It seems better to maintain a list of required dependencies as in -nodeflibs -l fbmt -l pthread -l c (or via #inclib "fbmt" etc. in code), than to maintain an exclude list of dependencies that are no...

Yea, I remember that some of the issue was fixed by adding more mutex locking in shell(), exec(), dylibload() around its console cleanup/re-initialization. But even now I'm still seeing problems with a multi-threaded FB program that calls exec() multiple times in parallel. The main problem I'm notic...

Adding libtinfo to libfb is an interesting idea that I hadn't considered, I'll look into that to see whether licensing would allow it and whether it seems doable. I wouldn't want to copy the database but maybe the functions. However, it's not only about libtinfo. The FB runtime is doing some things ...

About -nodeflib <lib>, it would in theory be useful when linking against .so's, right? Normally the linker automatically skips specified but unused libraries, but not in that case... However, regarding libtinfo: Does -nodeflibs already help to avoid the libtinfo dependency? I tried but it didn't see...

Hi, today I was (once again) thinking about how odd it is that fbc links against libtinfo even though it does nothing more than PRINT to stdout. How about getting rid of that dependency, not for all FB programs, but for those that do not require it, such as fbc itself? As far as I know, this is stil...

Hey - made a pull request for this

Thanks for doing the work of adding the changes to fbc, and putting them into Git too. I've merged both branches together and merged them into master. I think that should be fine, since I don't think the changes break anything else. We can improve it further as needed.