Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problem with Solaris 9 and mtr-0.58

10 views
Skip to first unread message

jampier

unread,
Jun 23, 2004, 6:09:54 PM6/23/04
to
Hello everybody.

I'm having problem doing make for mtr-0.58. I install glib and system
SUNWGtkr and SUNWGtku - GTK - The GIMP Toolkit (Root,Usr). I'm
runing Solaris 9, GNU make 3.80 SPARC 64bit Solaris 9 and gcc 3.3.2.

I follow instruction on README from mtr-0.58 that indicated to add
manually -lcurses on the gcc line. But I still having problems with
this Undefined symbols as show below.

mtr-0.58> gcc -g -o mtr curses.o mtr.o net.o dns.o raw.o split.o
display.o report.o getopt.o getopt1.o select.o -lresolv -lnsl
-lsocket -lm -ltermcap -lcurses
Undefined first referenced
symbol in file
gethostbyname2 mtr.o
wattr_off curses.o
wattr_on curses.o
ld: fatal: Symbol referencing errors. No output written to mtr
collect2: ld returned 1 exit status


Does any body have any clues?

Thanks

Javier.

Dave Uhring

unread,
Jun 23, 2004, 6:48:31 PM6/23/04
to
On Wed, 23 Jun 2004 15:09:54 -0700, jampier wrote:

> mtr-0.58> gcc -g -o mtr curses.o mtr.o net.o dns.o raw.o split.o
> display.o report.o getopt.o getopt1.o select.o -lresolv -lnsl
> -lsocket -lm -ltermcap -lcurses
> Undefined first referenced
> symbol in file
> gethostbyname2 mtr.o
> wattr_off curses.o
> wattr_on curses.o
> ld: fatal: Symbol referencing errors. No output written to mtr
> collect2: ld returned 1 exit status

Not sure about the gethostbyname2 but you can solve the wattr_* problems
by reading attr_get(3XCURSES).

Casper H.S. Dik

unread,
Jun 24, 2004, 8:35:22 AM6/24/04
to
Dave Uhring <daveu...@yahoo.com> writes:

Actually, this is a problem of using the wrong include files or
the wrong library.

If there's an ncurses installation, remove it's headers from
/usr/local/include and recompile.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Thomas Dickey

unread,
Jun 24, 2004, 2:34:47 PM6/24/04
to
Casper H.S. Dik <Caspe...@sun.com> wrote:

> Actually, this is a problem of using the wrong include files or
> the wrong library.

half right, as usual

> If there's an ncurses installation, remove it's headers from
> /usr/local/include and recompile.

...or (if your sense of humor is good enough), give correct advice
by reading mtr's makefile.

> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.

understatement.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Casper H.S. Dik

unread,
Jun 25, 2004, 7:04:27 AM6/25/04
to
Thomas Dickey <dic...@saltmine.radix.net> writes:

>Casper H.S. Dik <Caspe...@sun.com> wrote:

>> Actually, this is a problem of using the wrong include files or
>> the wrong library.

>half right, as usual

We're bing specially nice today, aren't we.

>> If there's an ncurses installation, remove it's headers from
>> /usr/local/include and recompile.

>...or (if your sense of humor is good enough), give correct advice
>by reading mtr's makefile.

I think you're talking abotu reading mtr's README; then you'll find
that my advice is in fact the correct advice but that mtr's author
would like to be clued in.

Casper

Thomas Dickey

unread,
Jun 25, 2004, 9:10:29 AM6/25/04
to
Casper H.S. Dik <Caspe...@sun.com> wrote:
> Thomas Dickey <dic...@saltmine.radix.net> writes:

>>Casper H.S. Dik <Caspe...@sun.com> wrote:

>>> Actually, this is a problem of using the wrong include files or
>>> the wrong library.

>>half right, as usual

> We're bing specially nice today, aren't we.

^^^^ (parse error)

>>> If there's an ncurses installation, remove it's headers from
>>> /usr/local/include and recompile.

>>...or (if your sense of humor is good enough), give correct advice
>>by reading mtr's makefile.

> I think you're talking abotu reading mtr's README; then you'll find
> that my advice is in fact the correct advice but that mtr's author
> would like to be clued in.

This one came up some months ago; I recall looking into it and noting
that the advice given in this newsgroup was incorrect. (It's buildable
either way, but it would be nice if the advice took that into account).

Casper H.S. Dik

unread,
Jun 25, 2004, 10:12:39 AM6/25/04
to
Thomas Dickey <dic...@saltmine.radix.net> writes:

>This one came up some months ago; I recall looking into it and noting
>that the advice given in this newsgroup was incorrect. (It's buildable
>either way, but it would be nice if the advice took that into account).

The advice was not so much incorrect as well as incomplete;
the "easy way out" is to remove the ncurses includes because you
generally don't need them; but my description of the symptom is
correct: the program is being compiled against ncurses headers but
linked against the Solaris curses library.

Yes, you can pick either one and it works both ways, but the problem
is symptomatic of a bad software installation; and it is in the user's
best interest to fix that.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.

Thomas Dickey

unread,
Jun 25, 2004, 11:41:09 AM6/25/04
to
Casper H.S. Dik <Caspe...@sun.com> wrote:
> Thomas Dickey <dic...@saltmine.radix.net> writes:

>>This one came up some months ago; I recall looking into it and noting
>>that the advice given in this newsgroup was incorrect. (It's buildable
>>either way, but it would be nice if the advice took that into account).

> The advice was not so much incorrect as well as incomplete;
> the "easy way out" is to remove the ncurses includes because you

the easy way out is to change the couple of lines in mtr's makefile.

> generally don't need them; but my description of the symptom is
> correct: the program is being compiled against ncurses headers but
> linked against the Solaris curses library.

> Yes, you can pick either one and it works both ways, but the problem
> is symptomatic of a bad software installation; and it is in the user's
> best interest to fix that.

reportedly the sunfreeware package is updated to ncurses 5.4 (which makes
it harder to create the conflict - however there are all those cd's that
Sun distributes which probably won't be corrected for several years).

Adam Summerfield

unread,
Jun 25, 2004, 9:09:10 PM6/25/04
to
Rather than fighting amongst yourselves as to who is right, why not help the group and tell us exactly how to fix the problem.

Adam


"Thomas Dickey" <dic...@saltmine.radix.net> wrote in message news:10dohsl...@corp.supernews.com...

Thomas Dickey

unread,
Jun 26, 2004, 7:06:25 AM6/26/04
to
Adam Summerfield <adams_re...@madman.homeip.net> wrote:
> Rather than fighting amongst yourselves as to who is right, why not help the
> group and tell us exactly how to fix the problem.

mtr has more than one problem (the authors haven't given much thought to making
it portable). To address the particular issue that we're discussing, I'd use a
shell-script to setup the environment so it doesn't run into the conflict.

Editing the configured files doesn't work as the README would indicate.

For example:

cfg-curses --without-gtk

gets it past that (though the gethostbyname2 prevents it from linking - google
hints that the library order used by mtr may be the problem):

** Sat Jun 26 06:52:51 EDT 2004
** node: saltmine
** user: uid=8037(dickey) gid=50(users)
** make:
make all-recursive
Making all in img
cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c mtr.c
mtr.c: In function `main':
mtr.c:351: warning: implicit declaration of function `gethostbyname2'
mtr.c:351: warning: assignment makes pointer from integer without a cast
mtr.c:355: warning: implicit declaration of function `herror'
gcc: -lcurses: linker input file unused since linking not done
cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c net.c
net.c: In function `net_save_increment':
net.c:648: warning: implicit declaration of function `memmove'
gcc: -lcurses: linker input file unused since linking not done
cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c dns.c
dns.c: In function `linkresolvehost':
dns.c:544: warning: implicit declaration of function `strcasecmp'
gcc: -lcurses: linker input file unused since linking not done
cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c raw.c
gcc: -lcurses: linker input file unused since linking not done
cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c split.c
gcc: -lcurses: linker input file unused since linking not done
cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c display.c
gcc: -lcurses: linker input file unused since linking not done
cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c report.c
report.c: In function `report_close':
report.c:108: warning: implicit declaration of function `index'
gcc: -lcurses: linker input file unused since linking not done
cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c getopt.c
gcc: -lcurses: linker input file unused since linking not done
cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c getopt1.c
gcc: -lcurses: linker input file unused since linking not done
cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c select.c
gcc: -lcurses: linker input file unused since linking not done
cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c curses.c
curses.c: In function `mtr_curses_keyaction':
curses.c:269: warning: implicit declaration of function `index'
gcc: -lcurses: linker input file unused since linking not done
cc-curses -O2 -Wall -o mtr curses.o mtr.o net.o dns.o raw.o split.o display.o report.o getopt.o getopt1.o select.o -lresolv -lnsl -lsocket -lm -ltermcap


Undefined first referenced
symbol in file
gethostbyname2 mtr.o

ld: fatal: Symbol referencing errors. No output written to mtr
collect2: ld returned 1 exit status

*** Error code 1
make: Fatal error: Command failed for target `mtr'
Current working directory /export/home/dickey/Mail/mtr-0.58-curses
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /export/home/dickey/Mail/mtr-0.58-curses
*** Error code 1
make: Fatal error: Command failed for target `all-recursive-am'

Here's cc-curses:

#!/bin/sh
cc \
-D_XOPEN_SOURCE=500 \
-D_XOPEN_VERSION=4 \
-I/usr/include $* -L/usr/lib -lcurses

Here's cfg-curses:

#!/bin/sh
# work-around broken sfw package for ncurses, as well as Sun's broken headers.
CPPFLAGS="-I/usr/include \
-D_XOPEN_SOURCE=500 \
-D_XOPEN_VERSION=4" \
CC=cc-curses cfg-normal $*

and finally, cfg-normal:

#!/bin/sh
OUT=configure.out
cat >>$OUT <<EOF/
** `date`
** node: `hostname`
** user: `id`
** conf: $*
EOF/
rm -f config.status config.cache
./configure --verbose \
--disable-echo \
--disable-overwrite \
--enable-warnings \
--with-warnings \
--prefix=$HOME \
--exec-prefix=$HOME $* 2>&1 | tee -a $OUT

Thomas Dickey

unread,
Jun 26, 2004, 7:18:39 AM6/26/04
to
Thomas Dickey <dic...@saltmine.radix.net> wrote:

> mtr has more than one problem (the authors haven't given much thought to making
> it portable). To address the particular issue that we're discussing, I'd use a
> shell-script to setup the environment so it doesn't run into the conflict.

> Editing the configured files doesn't work as the README would indicate.
> For example:
> cfg-curses --without-gtk

... and a corresponding cfg-ncurses script would be needed to make it use
ncurses. (My configure scripts don't need that, though, and there is no
point in illustrating it).

Casper H.S. Dik

unread,
Jun 26, 2004, 8:25:18 AM6/26/04
to
Thomas Dickey <dic...@saltmine.radix.net> writes:

>cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c curses.c

The crucial bit is the "-I/usr/include"; it will cause the compiler to
pick up the include files match /usr/lib/libcurses.so.

There's no need to add -lcurses since we're also linking -ltermcap
which is really the same a -lcurses:

lrwxrwxrwx 1 root root 16 Mar 3 22:14 libcurses.so -> ./libcurses.so.1
-rwxr-xr-x 1 root bin 237256 Apr 6 2002 libcurses.so.1
lrwxrwxrwx 1 root root 15 Mar 3 22:14 libtermcap.so -> libtermcap.so.1
lrwxrwxrwx 1 root root 14 Mar 3 22:14 libtermcap.so.1 -> libcurses.so.1

>Here's cfg-curses:

>#!/bin/sh
># work-around broken sfw package for ncurses, as well as Sun's broken headers.

There's no brokeness in the headers, just in gcc. (Or better put: there's
disagreement between the way "gcc" defines ANSI conformance and the
way Solaris defines it. "fix-includes" doesn't fix includes; it
transmogrifies them so they're acceptable to gcc.

My original recommendation of removing the ncurses includes from the
directories gcc searches by default (/usr/local/include?) still stands.

mtr, of course, shouldn't use long (5 years!) obsolete interfaces like
gethostbyname2().

Thomas Dickey

unread,
Jun 26, 2004, 11:28:15 AM6/26/04
to
Casper H.S. Dik <Caspe...@sun.com> wrote:
> Thomas Dickey <dic...@saltmine.radix.net> writes:

>>cc-curses -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include -D_XOPEN_SOURCE=500 -D_XOPEN_VERSION=4 -O2 -Wall -c curses.c

> The crucial bit is the "-I/usr/include"; it will cause the compiler to
> pick up the include files match /usr/lib/libcurses.so.

yes (not recommended in general, but at the moment it works).

> There's no need to add -lcurses since we're also linking -ltermcap
> which is really the same a -lcurses:

I'm aware of that (the scripts are those that I use for testing on this
machine). The termcap check in mtr's configure script is misplaced:
the authors seem to have trouble distinguishing SunOS 4.x from Solaris.

> lrwxrwxrwx 1 root root 16 Mar 3 22:14 libcurses.so -> ./libcurses.so.1
> -rwxr-xr-x 1 root bin 237256 Apr 6 2002 libcurses.so.1
> lrwxrwxrwx 1 root root 15 Mar 3 22:14 libtermcap.so -> libtermcap.so.1
> lrwxrwxrwx 1 root root 14 Mar 3 22:14 libtermcap.so.1 -> libcurses.so.1

>>Here's cfg-curses:

>>#!/bin/sh
>># work-around broken sfw package for ncurses, as well as Sun's broken headers.

> There's no brokeness in the headers, just in gcc. (Or better put: there's
> disagreement between the way "gcc" defines ANSI conformance and the
> way Solaris defines it. "fix-includes" doesn't fix includes; it
> transmogrifies them so they're acceptable to gcc.

not really (I'd have to look it up, but it's really Sun's problem).
Still, that's better than the largely-nonfunctional /usr/xpg4/ curses(*).

> My original recommendation of removing the ncurses includes from the
> directories gcc searches by default (/usr/local/include?) still stands.

It should be in /usr/local/include/ncurses/, or (for instance with
sunfreeware) in /opt/sfw/include/ncurses/.

(*) the only vendor implementation of X/Open curses that I've found to
be good is Tru64.

Gerry T

unread,
Jun 26, 2004, 6:12:54 PM6/26/04
to
Casper H.S. Dik <Caspe...@Sun.COM> wrote in message news:<40dd6b2e$0$48959$e4fe...@news.xs4all.nl>...

>
> My original recommendation of removing the ncurses includes from the
> directories gcc searches by default (/usr/local/include?) still stands.

Interesting. My gcc 3.4.0 doesnt have an include directory for C
only c++. Not an issue here.

> mtr, of course, shouldn't use long (5 years!) obsolete interfaces like
> gethostbyname2().

Luckily this only appears twice in mrt.c and can be #ifdef'd out of the
way however one sees fit. The first mention of gethostbyname2 is
already wrapped with an #ifdef ENABLE_IPV6. I took a rather lazy
approach and wrapped the second instance with:

if (host == NULL) {
#ifdef ENABLE_IPV6
host = gethostbyname2(Hostname, af);
#else
host = gethostbyname(Hostname);
#endif
}

Not the best way to deal with it, but hey this IS Usenet
and is does follow the 'logic' of the original code : >

I ran configure like so:
(LDFLAGS="-L/opt/csw/lib -R/opt/csw/lib" \
LD_RUN_PATH=/usr/lib:/opt/gcc/lib:/opt/csw/lib ./configure)
(I have blastwave gtk libs installed, my gcc was built from source
and lives in /opt/gcc)
ldd is happy with the resultant binary.. and
it seems to be working but I dont have an enterprise sized
network to test it with - just a single Ultra 2.

Thomas Dickey

unread,
Jun 27, 2004, 6:50:36 AM6/27/04
to
Gerry T <ger...@vcn.bc.ca> wrote:
> Casper H.S. Dik <Caspe...@Sun.COM> wrote in message news:<40dd6b2e$0$48959$e4fe...@news.xs4all.nl>...

>>
>> My original recommendation of removing the ncurses includes from the
>> directories gcc searches by default (/usr/local/include?) still stands.

> Interesting. My gcc 3.4.0 doesnt have an include directory for C
> only c++. Not an issue here.

Perhaps ncurses wasn't installed: blastwave compiles some of their
packages with Solaris curses, even - example dialog - where that is
a bad choice.

0 new messages