robertl@killer.UUCP (Robert Lord) (06/24/87)
I am working on an Altos 2086 machine with Xenix, and having some trouble
with the curses package in C. I issue the command 'cc file.c -lcurses'
and it after a while it says:
/bin/ld: Unresolved externals:
_tgoto in file(s):
/lib/Slibcurses.a(cr_tty.c) /lib/Slibcurses.a(cr_put.c)
And this goes on for about 6 lines(differnt 'xxx in files' each time). The
wierd thing is that cc creates the file a.out, but does not make it executible, and if you chmod it and run it it goes crazy.
I am hoping that this is a simple problem with an include file or something
(yes, I included <curses.h>!) that another Altos user might be able to help me
with.
Thanks,
Robert Lord
{ihnp4, seismo}!killer!robertlatdingle@phoenix.PRINCETON.EDU (Adam Thomas Dingle) (07/01/87)
You need to include '-ltermcap' on the command line as well, after the '-lcurses'. The curses routines call some lower-level routines (such as tgoto) found in the termcap library. Adam
guardian@laidbak.UUCP (Harry Skelton) (07/01/87)
In article <1032@killer.UUCP> robertl@killer.UUCP (Robert Lord) writes: > >I am working on an Altos 2086 machine with Xenix, and having some trouble >with the curses package in C. I issue the command 'cc file.c -lcurses' >and it after a while it says: > >/bin/ld: Unresolved externals: >_tgoto in file(s): > /lib/Slibcurses.a(cr_tty.c) /lib/Slibcurses.a(cr_put.c) > >And this goes on for about 6 lines(differnt 'xxx in files' each time). The > Thanks, > Robert Lord > {ihnp4, seismo}!killer!robertl With the ld giving unresolved external, it seems that you forgot a variable to include into your source. Check the documentation and see where that external is used and how you must declare it. If not found under the curses section...check 'termcap' as in some systems, curses uses termcap routines. Harry Skelton guardian@laidbak.UUCP ihnp4!laidbak!guardian
bill@westpt.usma.edu (Bill Gunshannon) (07/02/87)
In article <1032@killer.UUCP>, robertl@killer.UUCP (Robert Lord) writes: > > I issue the command 'cc file.c -lcurses' > and it after a while it says: > > /bin/ld: Unresolved externals: > > _tgoto in file(s): > /lib/Slibcurses.a(cr_tty.c) /lib/Slibcurses.a(cr_put.c) > The problem is that all the routines you need aren't in Slibcurses.a. You will also need to include either Slibtermcap.a or Slibtermlib.a. I have seen either or both on various machines and they are usually just a copy of each other so it doesn't matter which one you use. So, try 'cc file.c -lcurses -ltermlib' and good luck. bill gunshannon UUCP: {philabs,phri}!westpt!bill PHONE: (914)446-7747 US SNAIL: Martin Marietta Data Systems RADIO: KB3YV USMA, Bldg 600, Room 26 AX.25 KB3YV @ WA2RKN West Point, NY 10996
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/04/87)
In article <1032@killer.UUCP> robertl@killer.UUCP (Robert Lord) writes: >... I issue the command 'cc file.c -lcurses' ... I don't know much about Xenix, but I suspect it's termcap-based, in which case you need to append " -ltermlib" to your link command. The reason "ld" did not make the a.out executable was because there were unsatisfied external references (as it told you). Of course an incomplete load module goes crazy if you try to run it!
rwhite@nu3b2.UUCP (Robert C. White Jr.) (07/06/87)
In article <6050@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <1032@killer.UUCP> robertl@killer.UUCP (Robert Lord) writes: > >... I issue the command 'cc file.c -lcurses' ... > > I don't know much about Xenix, but I suspect it's termcap-based, in > which case you need to append " -ltermlib" to your link command. > > The reason "ld" did not make the a.out executable was because there > were unsatisfied external references (as it told you). Of course an > incomplete load module goes crazy if you try to run it! Hello, I don't have the original article so I am responding here. I is important to note that curses simulates "many of the older termlib functions for compatibility reasons" What this means in real life is that it may or may not be there, as a macro or function definition. The only aproach I have found is to #include <curses.h> and see what falls out the cracks in a serious lint. If this is no joy, compare the function/ argument list in the manual, a lot of things have been changed around a bit to ceep the intra-curses interface consistant. When I imported "kermit.c" to my machine I wouldn't compile correctly no matter what cosmetically neuter changes I made. I've got to go after it with hooks and prods [hack and kludge] later. If you are using a system like mine [3B2/310 SVR2.0.4+] you may find that some libraaries [malloc/signal/and some others] are/arn't being loaded because of internals. make shure that you have #included <malloc.h> if you use the calls, if you do try it with and without -lmalloc [etc...] Robert. Disclaimer: My mind is so fragmented by random excursions into a wilderness of abstractions and incipient ideas that the practical purposes of the moment are often submerged in my consciousness and I don't know what I'm doing. [my employers certainly have no idea]
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/06/87)
In article <784@nu3b2.UUCP> rwhite@nu3b2.UUCP (Robert C. White Jr.) writes: > I is important to note that curses simulates "many of the older >termlib functions for compatibility reasons" This is true of the terminfo-based libcurses, first shipped with SVR2.0, but NOT of the older termcap-based libcurses, for which one has to also link in libtermlib as I said. > If you are using a system like mine [3B2/310 SVR2.0.4+] you may find >that some libraaries [malloc/signal/and some others] are/arn't being loaded >because of internals. make shure that you have #included <malloc.h> if you >use the calls, if you do try it with and without -lmalloc [etc...] I think you're going to confuse people with this. The old standard malloc()/free()/calloc()/realloc() functions are still found in the standard C library. <malloc.h> defines some stuff specifically for libmalloc, which is an OPTIONAL "improved" version of malloc that includes some additional routines. <malloc.h> should NOT be used unless you plan to make use of the additional routines. Otherwise whether or not to link in libmalloc should not matter except perhaps as a matter of run-time efficiency.