Larry Rosenman writes:
> When it trys to run the following:
> configure:7174: gcc -o conftest -O2 -pipe -L/usr/local/lib conftest.c
> -lz -lcrypt -lresolv -lcompat -lm -lutil -ledit 1>&5
> configure: failed program was:
> #line 7170 "configure"
> #include "confdefs.h"
> int main() { return 0; }
> $
>
> that program dies:
> $ cat conftest.c
> #include "confdefs.h"
> int main() { return 0; }
>
> $ /lib conftest.c -lz -lcrypt -lresolv -lcompat -lm -lutil -ledit
> <
> $ ./conftest
> /usr/libexec/ld.so: Undefined symbol "_tputs" in
> conftest:/usr/lib/libedit.so.2.3
Yes, I've seen that before. The program links okay but does not execute
because of an undefined symbol. I think that's a linker bug. Why would I
need a linker if it doesn't make sure the executable has fully resolved
symbols? This can be observed at least with NetBSD -ledit and OpenBSD
-lreadline.
Here's how I would expect it to work:
configure:3249: checking for readline
configure:3271: gcc -o conftest -O2 -g conftest.c -lreadline 1>&5
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libreadline.so: undefined reference to `tgetnum'
[snip]
collect2: ld returned 1 exit status
configure: failed program was:
#line 3260 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still
apply. */
char readline();
int main() {
readline()
; return 0; }
[snip]
configure:3271: gcc -o conftest -O2 -g conftest.c -lreadline -ltermcap 1>&5
[success]
Can you take this to the OS developers?
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
