“Error opening terminal: vt100.” while running a binary with ncurses on ARM



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








0















I cross-compiled ncurses for ARM. Wrote a sample application that links to it. While trying to run the binary on ARM, I am getting this error.



Error opening terminal: vt100.



Looks like I am missing some terminfo installation, but not entirely sure how to do that. Can someone please help me with that?



This is the ./configure command -
./configure --host arm64-linux-gnu --prefix=/sw/nic/third-party/ncurses-6.1/arm64/ -with-termlib --enable-termcap --with-caps --disable-database --with-fallbacks --without-xterm-new



** Configuration summary for NCURSES 6.1 20180127:



 extended funcs: yes
xterm terminfo: xterm-old

bin directory: /ncurses-6.1/arm64//bin
lib directory: /ncurses-6.1/arm64//lib
include directory: /ncurses-6.1/arm64//include/ncurses
man directory: /ncurses-6.1/arm64//share/man


** Include-directory is not in a standard location
After this, I am doing make, I am packaging the following and loading it on the ARM board.
ncurses-6.1/lib/*
/usr/share/terminfo/*



Thanks in advance.



Regards,
Sai










share|improve this question






























    0















    I cross-compiled ncurses for ARM. Wrote a sample application that links to it. While trying to run the binary on ARM, I am getting this error.



    Error opening terminal: vt100.



    Looks like I am missing some terminfo installation, but not entirely sure how to do that. Can someone please help me with that?



    This is the ./configure command -
    ./configure --host arm64-linux-gnu --prefix=/sw/nic/third-party/ncurses-6.1/arm64/ -with-termlib --enable-termcap --with-caps --disable-database --with-fallbacks --without-xterm-new



    ** Configuration summary for NCURSES 6.1 20180127:



     extended funcs: yes
    xterm terminfo: xterm-old

    bin directory: /ncurses-6.1/arm64//bin
    lib directory: /ncurses-6.1/arm64//lib
    include directory: /ncurses-6.1/arm64//include/ncurses
    man directory: /ncurses-6.1/arm64//share/man


    ** Include-directory is not in a standard location
    After this, I am doing make, I am packaging the following and loading it on the ARM board.
    ncurses-6.1/lib/*
    /usr/share/terminfo/*



    Thanks in advance.



    Regards,
    Sai










    share|improve this question


























      0












      0








      0


      0






      I cross-compiled ncurses for ARM. Wrote a sample application that links to it. While trying to run the binary on ARM, I am getting this error.



      Error opening terminal: vt100.



      Looks like I am missing some terminfo installation, but not entirely sure how to do that. Can someone please help me with that?



      This is the ./configure command -
      ./configure --host arm64-linux-gnu --prefix=/sw/nic/third-party/ncurses-6.1/arm64/ -with-termlib --enable-termcap --with-caps --disable-database --with-fallbacks --without-xterm-new



      ** Configuration summary for NCURSES 6.1 20180127:



       extended funcs: yes
      xterm terminfo: xterm-old

      bin directory: /ncurses-6.1/arm64//bin
      lib directory: /ncurses-6.1/arm64//lib
      include directory: /ncurses-6.1/arm64//include/ncurses
      man directory: /ncurses-6.1/arm64//share/man


      ** Include-directory is not in a standard location
      After this, I am doing make, I am packaging the following and loading it on the ARM board.
      ncurses-6.1/lib/*
      /usr/share/terminfo/*



      Thanks in advance.



      Regards,
      Sai










      share|improve this question
















      I cross-compiled ncurses for ARM. Wrote a sample application that links to it. While trying to run the binary on ARM, I am getting this error.



      Error opening terminal: vt100.



      Looks like I am missing some terminfo installation, but not entirely sure how to do that. Can someone please help me with that?



      This is the ./configure command -
      ./configure --host arm64-linux-gnu --prefix=/sw/nic/third-party/ncurses-6.1/arm64/ -with-termlib --enable-termcap --with-caps --disable-database --with-fallbacks --without-xterm-new



      ** Configuration summary for NCURSES 6.1 20180127:



       extended funcs: yes
      xterm terminfo: xterm-old

      bin directory: /ncurses-6.1/arm64//bin
      lib directory: /ncurses-6.1/arm64//lib
      include directory: /ncurses-6.1/arm64//include/ncurses
      man directory: /ncurses-6.1/arm64//share/man


      ** Include-directory is not in a standard location
      After this, I am doing make, I am packaging the following and loading it on the ARM board.
      ncurses-6.1/lib/*
      /usr/share/terminfo/*



      Thanks in advance.



      Regards,
      Sai







      cross-compiling ncurses xterm vt100






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 15 '18 at 17:44







      user1912491

















      asked Nov 15 '18 at 12:57









      user1912491user1912491

      284




      284






















          1 Answer
          1






          active

          oldest

          votes


















          1














          The INSTALL file in the ncurses source tells what you need to know:



          --disable-database 
          Use only built-in data. The ncurses libraries normally read terminfo
          and termcap data from disk. You can configure ncurses to have a
          built-in database, aka "fallback" entries. Embedded applications may
          have no need for an external database. Some, but not all of the
          programs are useful in this configuration, e.g., reset and tput versus
          infocmp and tic.

          --with-fallbacks=XXX
          Specify a list of fallback terminal descriptions which will be
          compiled into the ncurses library. See CONFIGURING FALLBACK ENTRIES.


          The command shown in the question does not list any fallback terminal descriptions (such as vt100).



          The command should list the descriptions that you want to build into the library, e.g.,



          ./configure command - ./configure --host arm64-linux-gnu --prefix=/sw/nic/third-party/ncurses-6.1/arm64/ -with-termlib --enable-termcap --with-caps --disable-database --with-fallbacks=vt100 --without-xterm-new


          Because you disabled the database, there is no point in copying /usr/share/terminfo/*, and because this uses (the default) static library, there is no need for copying the libncursesw.a to the embedded system (except in the rare case where you actually use a compiler/linker toolset running on the arm64 machine).



          ...responding to the followup on November 18: the fallback support in the ncurses library is only used in the case where setupterm is called (or its callers newterm, initscr)—see source code. For instance, programs such as clear will run, but not infocmp.



          In a quick check, I ran this to build a test-copy, turning on ncurses' trace feature:



          #!/bin/sh
          unset TERM
          unset TERMINFO
          unset TERMINFO_DIRS
          ./configure
          --prefix=/tmp/FOO
          --enable-termcap
          --with-trace
          --without-debug
          --without-ada
          --with-fallbacks=vt100,vt102,screen
          make


          and then in ./progs



          #!/bin/sh
          export TERM=vt100
          unset TERMINFO
          unset TERMINFO_DIRS
          rm -f trace
          export NCURSES_TRACE=0xffff
          ./clear


          (doing the unset's to avoid picking up my environment). The trace file does not tell where the resulting description comes from. That's done before the set_curterm call. If it were read from a file, that would show up. But the clear command works. Here's the complete trace, showing the failed calls for the file-accesses, and finally the tputs call with the expected data:



          TRACING NCURSES version 6.1.20181117 (tracelevel=0xffff)
          called setupterm("vt100",0,(nil))
          your terminal name is vt100
          using 2048 for getstr limit
          + called _nc_first_db
          duplicate /tmp/FOO/share/terminfo
          not found /users/tom/.terminfo
          not found /tmp/FOO/share/terminfo
          not found /etc/termcap
          not found /usr/share/misc/termcap
          + return
          + called set_curterm(0x242a2a0)
          + return (nil)
          + called def_shell_mode((nil)) ->term 0x242a2a0
          _nc_get_tty_mode(0): iflags: BRKINT, IXON cflags: CREAD CS8 lflags: ISIG
          + return 0
          + called def_prog_mode((nil)) ->term 0x242a2a0
          _nc_get_tty_mode(0): iflags: BRKINT, IXON cflags: CREAD CS8 lflags: ISIG
          + return 0
          + called baudrate((nil))
          + return 38400
          screen size: terminfo lines = 24 columns = 80
          SYS screen size: environment LINES = 40 COLUMNS = 80
          screen size is 40x80
          TABSIZE = 8
          return 0
          tputs( = "e[He[J$<50>", 40, 0x403630) called
          called delay_output(0x7ffca32a2f50,50)
          return 0
          called tigetstr((nil), E3)
          return (cancelled)
          tputs((cancelled), 40, 0x403630) called


          Running strings on clear shows this:



          vt100|vt100-am|dec vt100 (w/advanced video)


          which is the complete line from the terminfo source-file.






          share|improve this answer

























          • Thanks Thomas. After doing this. Is it enough if I take the ncurses/lib/*a to my ARM board? Or should I copy some other files too? Thanks.

            – user1912491
            Nov 16 '18 at 7:24












          • The ".a" file is a static library, which you likely linked with your application already (no need for the library on the embedded system in that case).

            – Thomas Dickey
            Nov 16 '18 at 9:16











          • Thanks much Thomas. I tried with --with-fallbacks=vt100,vt102,screen. I am still seeing the error.

            – user1912491
            Nov 18 '18 at 12:18











          • I tried with —enable-database, but in vain. Is there a way to check if the support for fallback is getting compiled-in either in the .bin or .a file, using the nm or the string command on them? I suspect that, that part is failing somehow.

            – user1912491
            Nov 18 '18 at 19:40











          • You could run strings on the linked-executable, and see the name compiled-in for the fallback table. The current debug-trace doesn't show this detail, but I added an example to show how I verified what's there today.

            – Thomas Dickey
            Nov 18 '18 at 20:19











          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53320009%2ferror-opening-terminal-vt100-while-running-a-binary-with-ncurses-on-arm%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          The INSTALL file in the ncurses source tells what you need to know:



          --disable-database 
          Use only built-in data. The ncurses libraries normally read terminfo
          and termcap data from disk. You can configure ncurses to have a
          built-in database, aka "fallback" entries. Embedded applications may
          have no need for an external database. Some, but not all of the
          programs are useful in this configuration, e.g., reset and tput versus
          infocmp and tic.

          --with-fallbacks=XXX
          Specify a list of fallback terminal descriptions which will be
          compiled into the ncurses library. See CONFIGURING FALLBACK ENTRIES.


          The command shown in the question does not list any fallback terminal descriptions (such as vt100).



          The command should list the descriptions that you want to build into the library, e.g.,



          ./configure command - ./configure --host arm64-linux-gnu --prefix=/sw/nic/third-party/ncurses-6.1/arm64/ -with-termlib --enable-termcap --with-caps --disable-database --with-fallbacks=vt100 --without-xterm-new


          Because you disabled the database, there is no point in copying /usr/share/terminfo/*, and because this uses (the default) static library, there is no need for copying the libncursesw.a to the embedded system (except in the rare case where you actually use a compiler/linker toolset running on the arm64 machine).



          ...responding to the followup on November 18: the fallback support in the ncurses library is only used in the case where setupterm is called (or its callers newterm, initscr)—see source code. For instance, programs such as clear will run, but not infocmp.



          In a quick check, I ran this to build a test-copy, turning on ncurses' trace feature:



          #!/bin/sh
          unset TERM
          unset TERMINFO
          unset TERMINFO_DIRS
          ./configure
          --prefix=/tmp/FOO
          --enable-termcap
          --with-trace
          --without-debug
          --without-ada
          --with-fallbacks=vt100,vt102,screen
          make


          and then in ./progs



          #!/bin/sh
          export TERM=vt100
          unset TERMINFO
          unset TERMINFO_DIRS
          rm -f trace
          export NCURSES_TRACE=0xffff
          ./clear


          (doing the unset's to avoid picking up my environment). The trace file does not tell where the resulting description comes from. That's done before the set_curterm call. If it were read from a file, that would show up. But the clear command works. Here's the complete trace, showing the failed calls for the file-accesses, and finally the tputs call with the expected data:



          TRACING NCURSES version 6.1.20181117 (tracelevel=0xffff)
          called setupterm("vt100",0,(nil))
          your terminal name is vt100
          using 2048 for getstr limit
          + called _nc_first_db
          duplicate /tmp/FOO/share/terminfo
          not found /users/tom/.terminfo
          not found /tmp/FOO/share/terminfo
          not found /etc/termcap
          not found /usr/share/misc/termcap
          + return
          + called set_curterm(0x242a2a0)
          + return (nil)
          + called def_shell_mode((nil)) ->term 0x242a2a0
          _nc_get_tty_mode(0): iflags: BRKINT, IXON cflags: CREAD CS8 lflags: ISIG
          + return 0
          + called def_prog_mode((nil)) ->term 0x242a2a0
          _nc_get_tty_mode(0): iflags: BRKINT, IXON cflags: CREAD CS8 lflags: ISIG
          + return 0
          + called baudrate((nil))
          + return 38400
          screen size: terminfo lines = 24 columns = 80
          SYS screen size: environment LINES = 40 COLUMNS = 80
          screen size is 40x80
          TABSIZE = 8
          return 0
          tputs( = "e[He[J$<50>", 40, 0x403630) called
          called delay_output(0x7ffca32a2f50,50)
          return 0
          called tigetstr((nil), E3)
          return (cancelled)
          tputs((cancelled), 40, 0x403630) called


          Running strings on clear shows this:



          vt100|vt100-am|dec vt100 (w/advanced video)


          which is the complete line from the terminfo source-file.






          share|improve this answer

























          • Thanks Thomas. After doing this. Is it enough if I take the ncurses/lib/*a to my ARM board? Or should I copy some other files too? Thanks.

            – user1912491
            Nov 16 '18 at 7:24












          • The ".a" file is a static library, which you likely linked with your application already (no need for the library on the embedded system in that case).

            – Thomas Dickey
            Nov 16 '18 at 9:16











          • Thanks much Thomas. I tried with --with-fallbacks=vt100,vt102,screen. I am still seeing the error.

            – user1912491
            Nov 18 '18 at 12:18











          • I tried with —enable-database, but in vain. Is there a way to check if the support for fallback is getting compiled-in either in the .bin or .a file, using the nm or the string command on them? I suspect that, that part is failing somehow.

            – user1912491
            Nov 18 '18 at 19:40











          • You could run strings on the linked-executable, and see the name compiled-in for the fallback table. The current debug-trace doesn't show this detail, but I added an example to show how I verified what's there today.

            – Thomas Dickey
            Nov 18 '18 at 20:19















          1














          The INSTALL file in the ncurses source tells what you need to know:



          --disable-database 
          Use only built-in data. The ncurses libraries normally read terminfo
          and termcap data from disk. You can configure ncurses to have a
          built-in database, aka "fallback" entries. Embedded applications may
          have no need for an external database. Some, but not all of the
          programs are useful in this configuration, e.g., reset and tput versus
          infocmp and tic.

          --with-fallbacks=XXX
          Specify a list of fallback terminal descriptions which will be
          compiled into the ncurses library. See CONFIGURING FALLBACK ENTRIES.


          The command shown in the question does not list any fallback terminal descriptions (such as vt100).



          The command should list the descriptions that you want to build into the library, e.g.,



          ./configure command - ./configure --host arm64-linux-gnu --prefix=/sw/nic/third-party/ncurses-6.1/arm64/ -with-termlib --enable-termcap --with-caps --disable-database --with-fallbacks=vt100 --without-xterm-new


          Because you disabled the database, there is no point in copying /usr/share/terminfo/*, and because this uses (the default) static library, there is no need for copying the libncursesw.a to the embedded system (except in the rare case where you actually use a compiler/linker toolset running on the arm64 machine).



          ...responding to the followup on November 18: the fallback support in the ncurses library is only used in the case where setupterm is called (or its callers newterm, initscr)—see source code. For instance, programs such as clear will run, but not infocmp.



          In a quick check, I ran this to build a test-copy, turning on ncurses' trace feature:



          #!/bin/sh
          unset TERM
          unset TERMINFO
          unset TERMINFO_DIRS
          ./configure
          --prefix=/tmp/FOO
          --enable-termcap
          --with-trace
          --without-debug
          --without-ada
          --with-fallbacks=vt100,vt102,screen
          make


          and then in ./progs



          #!/bin/sh
          export TERM=vt100
          unset TERMINFO
          unset TERMINFO_DIRS
          rm -f trace
          export NCURSES_TRACE=0xffff
          ./clear


          (doing the unset's to avoid picking up my environment). The trace file does not tell where the resulting description comes from. That's done before the set_curterm call. If it were read from a file, that would show up. But the clear command works. Here's the complete trace, showing the failed calls for the file-accesses, and finally the tputs call with the expected data:



          TRACING NCURSES version 6.1.20181117 (tracelevel=0xffff)
          called setupterm("vt100",0,(nil))
          your terminal name is vt100
          using 2048 for getstr limit
          + called _nc_first_db
          duplicate /tmp/FOO/share/terminfo
          not found /users/tom/.terminfo
          not found /tmp/FOO/share/terminfo
          not found /etc/termcap
          not found /usr/share/misc/termcap
          + return
          + called set_curterm(0x242a2a0)
          + return (nil)
          + called def_shell_mode((nil)) ->term 0x242a2a0
          _nc_get_tty_mode(0): iflags: BRKINT, IXON cflags: CREAD CS8 lflags: ISIG
          + return 0
          + called def_prog_mode((nil)) ->term 0x242a2a0
          _nc_get_tty_mode(0): iflags: BRKINT, IXON cflags: CREAD CS8 lflags: ISIG
          + return 0
          + called baudrate((nil))
          + return 38400
          screen size: terminfo lines = 24 columns = 80
          SYS screen size: environment LINES = 40 COLUMNS = 80
          screen size is 40x80
          TABSIZE = 8
          return 0
          tputs( = "e[He[J$<50>", 40, 0x403630) called
          called delay_output(0x7ffca32a2f50,50)
          return 0
          called tigetstr((nil), E3)
          return (cancelled)
          tputs((cancelled), 40, 0x403630) called


          Running strings on clear shows this:



          vt100|vt100-am|dec vt100 (w/advanced video)


          which is the complete line from the terminfo source-file.






          share|improve this answer

























          • Thanks Thomas. After doing this. Is it enough if I take the ncurses/lib/*a to my ARM board? Or should I copy some other files too? Thanks.

            – user1912491
            Nov 16 '18 at 7:24












          • The ".a" file is a static library, which you likely linked with your application already (no need for the library on the embedded system in that case).

            – Thomas Dickey
            Nov 16 '18 at 9:16











          • Thanks much Thomas. I tried with --with-fallbacks=vt100,vt102,screen. I am still seeing the error.

            – user1912491
            Nov 18 '18 at 12:18











          • I tried with —enable-database, but in vain. Is there a way to check if the support for fallback is getting compiled-in either in the .bin or .a file, using the nm or the string command on them? I suspect that, that part is failing somehow.

            – user1912491
            Nov 18 '18 at 19:40











          • You could run strings on the linked-executable, and see the name compiled-in for the fallback table. The current debug-trace doesn't show this detail, but I added an example to show how I verified what's there today.

            – Thomas Dickey
            Nov 18 '18 at 20:19













          1












          1








          1







          The INSTALL file in the ncurses source tells what you need to know:



          --disable-database 
          Use only built-in data. The ncurses libraries normally read terminfo
          and termcap data from disk. You can configure ncurses to have a
          built-in database, aka "fallback" entries. Embedded applications may
          have no need for an external database. Some, but not all of the
          programs are useful in this configuration, e.g., reset and tput versus
          infocmp and tic.

          --with-fallbacks=XXX
          Specify a list of fallback terminal descriptions which will be
          compiled into the ncurses library. See CONFIGURING FALLBACK ENTRIES.


          The command shown in the question does not list any fallback terminal descriptions (such as vt100).



          The command should list the descriptions that you want to build into the library, e.g.,



          ./configure command - ./configure --host arm64-linux-gnu --prefix=/sw/nic/third-party/ncurses-6.1/arm64/ -with-termlib --enable-termcap --with-caps --disable-database --with-fallbacks=vt100 --without-xterm-new


          Because you disabled the database, there is no point in copying /usr/share/terminfo/*, and because this uses (the default) static library, there is no need for copying the libncursesw.a to the embedded system (except in the rare case where you actually use a compiler/linker toolset running on the arm64 machine).



          ...responding to the followup on November 18: the fallback support in the ncurses library is only used in the case where setupterm is called (or its callers newterm, initscr)—see source code. For instance, programs such as clear will run, but not infocmp.



          In a quick check, I ran this to build a test-copy, turning on ncurses' trace feature:



          #!/bin/sh
          unset TERM
          unset TERMINFO
          unset TERMINFO_DIRS
          ./configure
          --prefix=/tmp/FOO
          --enable-termcap
          --with-trace
          --without-debug
          --without-ada
          --with-fallbacks=vt100,vt102,screen
          make


          and then in ./progs



          #!/bin/sh
          export TERM=vt100
          unset TERMINFO
          unset TERMINFO_DIRS
          rm -f trace
          export NCURSES_TRACE=0xffff
          ./clear


          (doing the unset's to avoid picking up my environment). The trace file does not tell where the resulting description comes from. That's done before the set_curterm call. If it were read from a file, that would show up. But the clear command works. Here's the complete trace, showing the failed calls for the file-accesses, and finally the tputs call with the expected data:



          TRACING NCURSES version 6.1.20181117 (tracelevel=0xffff)
          called setupterm("vt100",0,(nil))
          your terminal name is vt100
          using 2048 for getstr limit
          + called _nc_first_db
          duplicate /tmp/FOO/share/terminfo
          not found /users/tom/.terminfo
          not found /tmp/FOO/share/terminfo
          not found /etc/termcap
          not found /usr/share/misc/termcap
          + return
          + called set_curterm(0x242a2a0)
          + return (nil)
          + called def_shell_mode((nil)) ->term 0x242a2a0
          _nc_get_tty_mode(0): iflags: BRKINT, IXON cflags: CREAD CS8 lflags: ISIG
          + return 0
          + called def_prog_mode((nil)) ->term 0x242a2a0
          _nc_get_tty_mode(0): iflags: BRKINT, IXON cflags: CREAD CS8 lflags: ISIG
          + return 0
          + called baudrate((nil))
          + return 38400
          screen size: terminfo lines = 24 columns = 80
          SYS screen size: environment LINES = 40 COLUMNS = 80
          screen size is 40x80
          TABSIZE = 8
          return 0
          tputs( = "e[He[J$<50>", 40, 0x403630) called
          called delay_output(0x7ffca32a2f50,50)
          return 0
          called tigetstr((nil), E3)
          return (cancelled)
          tputs((cancelled), 40, 0x403630) called


          Running strings on clear shows this:



          vt100|vt100-am|dec vt100 (w/advanced video)


          which is the complete line from the terminfo source-file.






          share|improve this answer















          The INSTALL file in the ncurses source tells what you need to know:



          --disable-database 
          Use only built-in data. The ncurses libraries normally read terminfo
          and termcap data from disk. You can configure ncurses to have a
          built-in database, aka "fallback" entries. Embedded applications may
          have no need for an external database. Some, but not all of the
          programs are useful in this configuration, e.g., reset and tput versus
          infocmp and tic.

          --with-fallbacks=XXX
          Specify a list of fallback terminal descriptions which will be
          compiled into the ncurses library. See CONFIGURING FALLBACK ENTRIES.


          The command shown in the question does not list any fallback terminal descriptions (such as vt100).



          The command should list the descriptions that you want to build into the library, e.g.,



          ./configure command - ./configure --host arm64-linux-gnu --prefix=/sw/nic/third-party/ncurses-6.1/arm64/ -with-termlib --enable-termcap --with-caps --disable-database --with-fallbacks=vt100 --without-xterm-new


          Because you disabled the database, there is no point in copying /usr/share/terminfo/*, and because this uses (the default) static library, there is no need for copying the libncursesw.a to the embedded system (except in the rare case where you actually use a compiler/linker toolset running on the arm64 machine).



          ...responding to the followup on November 18: the fallback support in the ncurses library is only used in the case where setupterm is called (or its callers newterm, initscr)—see source code. For instance, programs such as clear will run, but not infocmp.



          In a quick check, I ran this to build a test-copy, turning on ncurses' trace feature:



          #!/bin/sh
          unset TERM
          unset TERMINFO
          unset TERMINFO_DIRS
          ./configure
          --prefix=/tmp/FOO
          --enable-termcap
          --with-trace
          --without-debug
          --without-ada
          --with-fallbacks=vt100,vt102,screen
          make


          and then in ./progs



          #!/bin/sh
          export TERM=vt100
          unset TERMINFO
          unset TERMINFO_DIRS
          rm -f trace
          export NCURSES_TRACE=0xffff
          ./clear


          (doing the unset's to avoid picking up my environment). The trace file does not tell where the resulting description comes from. That's done before the set_curterm call. If it were read from a file, that would show up. But the clear command works. Here's the complete trace, showing the failed calls for the file-accesses, and finally the tputs call with the expected data:



          TRACING NCURSES version 6.1.20181117 (tracelevel=0xffff)
          called setupterm("vt100",0,(nil))
          your terminal name is vt100
          using 2048 for getstr limit
          + called _nc_first_db
          duplicate /tmp/FOO/share/terminfo
          not found /users/tom/.terminfo
          not found /tmp/FOO/share/terminfo
          not found /etc/termcap
          not found /usr/share/misc/termcap
          + return
          + called set_curterm(0x242a2a0)
          + return (nil)
          + called def_shell_mode((nil)) ->term 0x242a2a0
          _nc_get_tty_mode(0): iflags: BRKINT, IXON cflags: CREAD CS8 lflags: ISIG
          + return 0
          + called def_prog_mode((nil)) ->term 0x242a2a0
          _nc_get_tty_mode(0): iflags: BRKINT, IXON cflags: CREAD CS8 lflags: ISIG
          + return 0
          + called baudrate((nil))
          + return 38400
          screen size: terminfo lines = 24 columns = 80
          SYS screen size: environment LINES = 40 COLUMNS = 80
          screen size is 40x80
          TABSIZE = 8
          return 0
          tputs( = "e[He[J$<50>", 40, 0x403630) called
          called delay_output(0x7ffca32a2f50,50)
          return 0
          called tigetstr((nil), E3)
          return (cancelled)
          tputs((cancelled), 40, 0x403630) called


          Running strings on clear shows this:



          vt100|vt100-am|dec vt100 (w/advanced video)


          which is the complete line from the terminfo source-file.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 24 '18 at 22:23

























          answered Nov 15 '18 at 21:23









          Thomas DickeyThomas Dickey

          32.9k62861




          32.9k62861












          • Thanks Thomas. After doing this. Is it enough if I take the ncurses/lib/*a to my ARM board? Or should I copy some other files too? Thanks.

            – user1912491
            Nov 16 '18 at 7:24












          • The ".a" file is a static library, which you likely linked with your application already (no need for the library on the embedded system in that case).

            – Thomas Dickey
            Nov 16 '18 at 9:16











          • Thanks much Thomas. I tried with --with-fallbacks=vt100,vt102,screen. I am still seeing the error.

            – user1912491
            Nov 18 '18 at 12:18











          • I tried with —enable-database, but in vain. Is there a way to check if the support for fallback is getting compiled-in either in the .bin or .a file, using the nm or the string command on them? I suspect that, that part is failing somehow.

            – user1912491
            Nov 18 '18 at 19:40











          • You could run strings on the linked-executable, and see the name compiled-in for the fallback table. The current debug-trace doesn't show this detail, but I added an example to show how I verified what's there today.

            – Thomas Dickey
            Nov 18 '18 at 20:19

















          • Thanks Thomas. After doing this. Is it enough if I take the ncurses/lib/*a to my ARM board? Or should I copy some other files too? Thanks.

            – user1912491
            Nov 16 '18 at 7:24












          • The ".a" file is a static library, which you likely linked with your application already (no need for the library on the embedded system in that case).

            – Thomas Dickey
            Nov 16 '18 at 9:16











          • Thanks much Thomas. I tried with --with-fallbacks=vt100,vt102,screen. I am still seeing the error.

            – user1912491
            Nov 18 '18 at 12:18











          • I tried with —enable-database, but in vain. Is there a way to check if the support for fallback is getting compiled-in either in the .bin or .a file, using the nm or the string command on them? I suspect that, that part is failing somehow.

            – user1912491
            Nov 18 '18 at 19:40











          • You could run strings on the linked-executable, and see the name compiled-in for the fallback table. The current debug-trace doesn't show this detail, but I added an example to show how I verified what's there today.

            – Thomas Dickey
            Nov 18 '18 at 20:19
















          Thanks Thomas. After doing this. Is it enough if I take the ncurses/lib/*a to my ARM board? Or should I copy some other files too? Thanks.

          – user1912491
          Nov 16 '18 at 7:24






          Thanks Thomas. After doing this. Is it enough if I take the ncurses/lib/*a to my ARM board? Or should I copy some other files too? Thanks.

          – user1912491
          Nov 16 '18 at 7:24














          The ".a" file is a static library, which you likely linked with your application already (no need for the library on the embedded system in that case).

          – Thomas Dickey
          Nov 16 '18 at 9:16





          The ".a" file is a static library, which you likely linked with your application already (no need for the library on the embedded system in that case).

          – Thomas Dickey
          Nov 16 '18 at 9:16













          Thanks much Thomas. I tried with --with-fallbacks=vt100,vt102,screen. I am still seeing the error.

          – user1912491
          Nov 18 '18 at 12:18





          Thanks much Thomas. I tried with --with-fallbacks=vt100,vt102,screen. I am still seeing the error.

          – user1912491
          Nov 18 '18 at 12:18













          I tried with —enable-database, but in vain. Is there a way to check if the support for fallback is getting compiled-in either in the .bin or .a file, using the nm or the string command on them? I suspect that, that part is failing somehow.

          – user1912491
          Nov 18 '18 at 19:40





          I tried with —enable-database, but in vain. Is there a way to check if the support for fallback is getting compiled-in either in the .bin or .a file, using the nm or the string command on them? I suspect that, that part is failing somehow.

          – user1912491
          Nov 18 '18 at 19:40













          You could run strings on the linked-executable, and see the name compiled-in for the fallback table. The current debug-trace doesn't show this detail, but I added an example to show how I verified what's there today.

          – Thomas Dickey
          Nov 18 '18 at 20:19





          You could run strings on the linked-executable, and see the name compiled-in for the fallback table. The current debug-trace doesn't show this detail, but I added an example to show how I verified what's there today.

          – Thomas Dickey
          Nov 18 '18 at 20:19



















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53320009%2ferror-opening-terminal-vt100-while-running-a-binary-with-ncurses-on-arm%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          How to how show current date and time by default on contact form 7 in WordPress without taking input from user in datetimepicker

          Syphilis

          Darth Vader #20