Why do graphics programs require libtinfo/ncurses?

Linux specific questions.
Post Reply
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Why do graphics programs require libtinfo/ncurses?

Post by xlucas »

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!
Julcar
Posts: 141
Joined: Oct 19, 2010 18:52
Contact:

Re: Why do graphics programs require libtinfo/ncurses?

Post by Julcar »

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
Landeel
Posts: 777
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Re: Why do graphics programs require libtinfo/ncurses?

Post by Landeel »

I'm interested too.
Maybe the "-s gui" flag could be used on Linux to eliminate the libtinfo dependency.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Why do graphics programs require libtinfo/ncurses?

Post by caseih »

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.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Why do graphics programs require libtinfo/ncurses?

Post by caseih »

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
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:

Code: Select all

print "Hello, world!"
Compile that with -g and then examine the symbols in your binary:

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
Compare that to:

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
Does any of this matter? No not really. Either way your program still pulls a ton of stuff in from the run time library that you are not using, like the FB terminal support routines that use libtinfo.
Roland Chastain
Posts: 995
Joined: Nov 24, 2011 19:49
Location: France
Contact:

Re: Why do graphics programs require libtinfo/ncurses?

Post by Roland Chastain »

caseih wrote: Compile that with -g and then examine the symbols in your binary:
Hello! Interesting. I didn't know the nm command.

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]$
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Why do graphics programs require libtinfo/ncurses?

Post by caseih »

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).
Roland Chastain
Posts: 995
Joined: Nov 24, 2011 19:49
Location: France
Contact:

Re: Why do graphics programs require libtinfo/ncurses?

Post by Roland Chastain »

@caseih

Thank you for the explanation.

Regards.

Roland
TeeEmCee
Posts: 375
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: Why do graphics programs require libtinfo/ncurses?

Post by TeeEmCee »

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:

Code: Select all

fbc -nodeflibs -l m -l pthread -l c -l gcc_s -l fbmt -l dl termcap_stub.o  <normal fbc args>
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).
TeeEmCee
Posts: 375
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: Why do graphics programs require libtinfo/ncurses?

Post by TeeEmCee »

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]$
BTW, the @@GLIBC_2.3.4 suffix does indeed mean it requires glibc 2.3.4+, which was released on 2004-12-29.

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.
Post Reply