Why do graphics programs require libtinfo/ncurses?
Why do graphics programs require libtinfo/ncurses?
Hi! I have a doubt and it's likely I've misunderstood something. Please point me out in the right direction...
As I understand it, libtinfo and ncurses are the same library. What they do is provide an API that makes it seems like you are programming a text mode similar to that of DOS, positioning the cursor and changing colours, when what's actually going on is that console escape codes are being issued. I understand why this is required in a text mode FreeBasic program. What I don't understand is why, when I make a program that does not use text mode at all and sets a graphic mode immediately at the beginning, it still requires this library as a dependency.
Less importantly, but related, I'm curious about whether it'd be possible to completely go around this library even in text mode and write to the console myself, so that I can get rid of that dependency, as I feel that this layer of abstraction is very simple and I could easily create LOCATE and COLOR sentences myself.
Does using InKey or GetKey to read keys from the keyboard have anything to do with this dependency during graphics mode?
Thanks!
As I understand it, libtinfo and ncurses are the same library. What they do is provide an API that makes it seems like you are programming a text mode similar to that of DOS, positioning the cursor and changing colours, when what's actually going on is that console escape codes are being issued. I understand why this is required in a text mode FreeBasic program. What I don't understand is why, when I make a program that does not use text mode at all and sets a graphic mode immediately at the beginning, it still requires this library as a dependency.
Less importantly, but related, I'm curious about whether it'd be possible to completely go around this library even in text mode and write to the console myself, so that I can get rid of that dependency, as I feel that this layer of abstraction is very simple and I could easily create LOCATE and COLOR sentences myself.
Does using InKey or GetKey to read keys from the keyboard have anything to do with this dependency during graphics mode?
Thanks!
Re: Why do graphics programs require libtinfo/ncurses?
Hi xlucas, I am also interested on this. I mostly compile for the web, not needing to display to console, but still I have to carry on with the ncurses dependency which makes grow my binaries
Re: Why do graphics programs require libtinfo/ncurses?
I'm interested too.
Maybe the "-s gui" flag could be used on Linux to eliminate the libtinfo dependency.
Maybe the "-s gui" flag could be used on Linux to eliminate the libtinfo dependency.
Re: Why do graphics programs require libtinfo/ncurses?
Sure the FB devs could build some kind of flag in to indicate that and then link in a version of the runtime that does not have any text mode capabilities. But it's probably not worth it as it doesn't really have any impact on 99% of the few FB Linux users out there. A libtinfo dependency does not bloat your binary. It's a shared library after all. Sure your binary carries a bunch of FB runtime library call paths with it that you never use.
Re: Why do graphics programs require libtinfo/ncurses?
How are you outputting your html code? Just be aware that if you are using FB's PRINT statement, then you're bringing in the entire text i/o section from the FB runtime library. You can prove this by making a little test binary from the following code:Julcar wrote:Hi xlucas, I am also interested on this. I mostly compile for the web, not needing to display to console, but still I have to carry on with the ncurses dependency which makes grow my binaries
Code: Select all
print "Hello, world!"
Code: Select all
$ nm mybinary | grep -i print
0000000000404940 T fb_ConsolePrintBuffer
0000000000404730 T fb_ConsolePrintBufferEx
0000000000402cc0 T fb_hFilePrintBuffer
0000000000402c70 T fb_hFilePrintBufferEx
00000000004046a0 T fb_PrintBuffer
0000000000404680 T fb_PrintBufferEx
00000000004042f0 T fb_PrintPad
0000000000404220 T fb_PrintPadEx
0000000000402600 T fb_PrintString
00000000004025b0 T fb_PrintStringEx
0000000000402680 T fb_PrintVoid
0000000000402640 T fb_PrintVoidEx
U fprintf@@GLIBC_2.2.5
Code: Select all
#include "crt.bi"
printf(!"Hello, world!\n")
Code: Select all
$ nm myotherbinary | grep -i print
U fprintf@@GLIBC_2.2.5
U printf@@GLIBC_2.2.5
-
- Posts: 995
- Joined: Nov 24, 2011 19:49
- Location: France
- Contact:
Re: Why do graphics programs require libtinfo/ncurses?
Hello! Interesting. I didn't know the nm command.caseih wrote: Compile that with -g and then examine the symbols in your binary:
There must be a problem in my configuration, because I see two different versions of GLIBC:
[roland@localhost test]$ nm print | grep -i print
0000000000405230 T fb_ConsolePrintBuffer
0000000000405020 T fb_ConsolePrintBufferEx
00000000004033b0 T fb_hFilePrintBuffer
0000000000403370 T fb_hFilePrintBufferEx
0000000000404fa0 T fb_PrintBuffer
0000000000404f80 T fb_PrintBufferEx
0000000000404ce0 T fb_PrintPad
0000000000404bf0 T fb_PrintPadEx
0000000000402750 T fb_PrintString
0000000000402700 T fb_PrintStringEx
00000000004027e0 T fb_PrintVoid
0000000000402790 T fb_PrintVoidEx
U __fprintf_chk@@GLIBC_2.3.4
U __snprintf_chk@@GLIBC_2.3.4
U snprintf@@GLIBC_2.2.5
[roland@localhost test]$ nm printf | grep -i print
U __fprintf_chk@@GLIBC_2.3.4
U __snprintf_chk@@GLIBC_2.3.4
U snprintf@@GLIBC_2.2.5
[roland@localhost test]$
Re: Why do graphics programs require libtinfo/ncurses?
I don't think there's anything wrong with your configuration. The symbols are versioned by the linker. In other words, that is versions that the binary will require. So in your case, part of the program can work with 2.2.5 or newer, and the other part needs 2.3.4. What this probably means is that your glibc is newer than mine, and includes a re-implemented snprintf that is compatible with the old 2.2.5 ABI, but internally it actually calls snprintf_chk, which is a newer safer version of snprintf, which was released in glibc 2.3.4. Hope that makes sense. Your binaries will not run on my distro because of this.
EDIT. Actually my version of glibc does provide __snprintf_chk at the proper version. I wonder why my binaries don't use it. Maybe it's because of my old FB compiler (still 1.05).
EDIT. Actually my version of glibc does provide __snprintf_chk at the proper version. I wonder why my binaries don't use it. Maybe it's because of my old FB compiler (still 1.05).
-
- Posts: 995
- Joined: Nov 24, 2011 19:49
- Location: France
- Contact:
Re: Why do graphics programs require libtinfo/ncurses?
@caseih
Thank you for the explanation.
Regards.
Roland
Thank you for the explanation.
Regards.
Roland
Re: Why do graphics programs require libtinfo/ncurses?
Yes, I'd like to make the libtinfo dependency optional, it's truly awful. Maybe fbc could avoid it automatically if you don't use any commands that need to read termcaps, just like libfbgfx is optional.
If you don't want your Linux binaries to depend on libtinfo nor libncurses then you can use the same hack the OHRRPGCE uses, which is to compile this termcap_stub.c stub file and link it to your program. Unfortunately fbc will still link to the library even though no functions in it are needed. To get around this you need to pass -nodeflibs to fbc and then manually specify the standard libs. In my case that's:
Use "fbc -v <normal args>" (without -nodeflibs) to see which libraries fbc normally links.
There are various tricks the OHRRPGCE uses to produce portable linux binaries; you can find more here (not necessarily complete or totally up to date).
If you don't want your Linux binaries to depend on libtinfo nor libncurses then you can use the same hack the OHRRPGCE uses, which is to compile this termcap_stub.c stub file and link it to your program. Unfortunately fbc will still link to the library even though no functions in it are needed. To get around this you need to pass -nodeflibs to fbc and then manually specify the standard libs. In my case that's:
Code: Select all
fbc -nodeflibs -l m -l pthread -l c -l gcc_s -l fbmt -l dl termcap_stub.o <normal fbc args>
There are various tricks the OHRRPGCE uses to produce portable linux binaries; you can find more here (not necessarily complete or totally up to date).
Re: Why do graphics programs require libtinfo/ncurses?
BTW, the @@GLIBC_2.3.4 suffix does indeed mean it requires glibc 2.3.4+, which was released on 2004-12-29.Roland Chastain wrote:[roland@localhost test]$ nm printf | grep -i print
U __fprintf_chk@@GLIBC_2.3.4
U __snprintf_chk@@GLIBC_2.3.4
U snprintf@@GLIBC_2.2.5
[roland@localhost test]$
If you're like to check which glibc/gcc standard libraries your binary requires you can use this utility.
This doesn't tell you about dependencies due to other libraries, not even tinfo/curses, but if you solve your tinfo problems then probably glibc and gcc are your next biggest portability problem between linux distros.