“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;
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
add a comment |
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
add a comment |
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
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
cross-compiling ncurses xterm vt100
edited Nov 15 '18 at 17:44
user1912491
asked Nov 15 '18 at 12:57
user1912491user1912491
284
284
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
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 runstrings
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
|
show 2 more comments
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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 runstrings
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
|
show 2 more comments
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.
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 runstrings
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
|
show 2 more comments
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.
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.
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 runstrings
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
|
show 2 more comments
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 runstrings
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
|
show 2 more comments
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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