Guile 6.4 on NCR MPRAS

Guile 6.4 on NCR MPRAS

[Kevin Pendleton]

Hi All,

I am trying to compile guile 6.4 (so that I can compile GNU libmatheval)
on NCR MPRAS (i686-ncr-sysv4.3).  I am compiling with gcc 3.3.2,
binutils 2.14 and GNU make 3.80.  Originally the configure script
complained that my libreadline was to old, so I compiled GNU Readline
4.3.  Now, after running configure again successfully, I get the
following error on the make:

gcc -DHAVE_CONFIG_H -I. -I/usr/local/src/guile-1.6.4/libguile -I.. -I..
-I/usr/local/src/guile-1.6.4/libguile/..
-I/usr/local/src/guile-1.6.4/libguile-ltdl -g -O2 -Wall
-Wmissing-prototypes -MT
gc_os_dep.lo -MD -MP -MF .deps/gc_os_dep.Tpo -c
/usr/local/src/guile-1.6.4/libguile/gc_os_dep.c
-fPIC -DPIC -o .libs/gc_os_dep.lo
/usr/local/src/guile-1.6.4/libguile/gc_os_dep.c:380: error: parse error
before '--' token
make[2]: *** [gc_os_dep.lo] Error 1
make[2]: Leaving directory `/usr/local/src/guile164/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/guile164'
make: *** [all] Error 2

I am configuring with the following options:

/usr/local/src/guile-1.6.4/configure \
	--build=i686-ncr-sysv4.3 \
	--prefix=/usr/gnu \
	--with-gnu-ld

Is there a proper way to send my config.log if that is needed?  I'm sure
there is still something I need to add on my side to get it to work.  If
anyone has any ideas, they would be much appreciated.

Thanks,

Kevin



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Guile 6.4 on NCR MPRAS

[Kevin Pendleton]

I took a look at the code and realized that it just didn't realize what
my machine type was.  I changed line 380 in the file
./guile-1.6.4/libguile/gc_os_dep.c to this:

# ifndef mach_type_known
#    define I386
#    define SYSV
#    define mach_type_known
# endif

And then I got these errors:

gcc -g -O2 -Wall -Wmissing-prototypes -o .libs/guile .libs/guileS.o guile.o -Wl,--export-dynamic
 ./.libs/libguile.so /usr/local/src/guile164/libguile-ltdl/.libs/libguile-ltdl.so -ldl -lcrypt -lm -Wl,--rpath -Wl,/usr/gnu/lib
./.libs/libguile.so: undefined reference to `recv'
./.libs/libguile.so: undefined reference to `connect'
./.libs/libguile.so: undefined reference to `_mwvalidcheckl'
./.libs/libguile.so: undefined reference to `recvfrom'
./.libs/libguile.so: undefined reference to `gethostbyaddr'
./.libs/libguile.so: undefined reference to `socket'
./.libs/libguile.so: undefined reference to `send'
./.libs/libguile.so: undefined reference to `accept'
./.libs/libguile.so: undefined reference to `h_errno'
./.libs/libguile.so: undefined reference to `bind'
./.libs/libguile.so: undefined reference to `setsockopt'
./.libs/libguile.so: undefined reference to `sendto'
./.libs/libguile.so: undefined reference to `listen'
./.libs/libguile.so: undefined reference to `inet_ntoa'
./.libs/libguile.so: undefined reference to `shutdown'
./.libs/libguile.so: undefined reference to `gethostbyname'
./.libs/libguile.so: undefined reference to `getpeername'
./.libs/libguile.so: undefined reference to `_mwoflocheckl'
./.libs/libguile.so: undefined reference to `getsockopt'
./.libs/libguile.so: undefined reference to `getsockname'
collect2: ld returned 1 exit status
make[2]: *** [guile] Error 1
make[2]: Leaving directory `/usr/local/src/guile164/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/guile164'
make: *** [all] Error 2


I then set LIBS="-lm -lmw -lnsl" and re-configured and it was able to
compile fine.  When I run a make check I get the following results:

Running alist.test
Running bit-operations.test
Running c-api.test
Running chars.test
Running common-list.test
Running environments.test
Running eval.test
Running exceptions.test
Running format.test
Running gc.test
Running getopt-long.test
Running goops.test
Running guardians.test
Running hooks.test
Running import.test
Running interp.test
Running list.test
Running load.test
Running numbers.test
Running optargs.test
Running ports.test
Running r4rs.test
Running reader.test
Running regexp.test
Running srfi-10.test
Running srfi-13.test
Running srfi-14.test
Running srfi-19.test
FAIL: srfi-19.test: SRFI date/time library: #<procedure time-utc->date
(time . tz-offset)> respects local DST if no TZ-OFFSET given
FAIL: srfi-19.test: SRFI date/time library: #<procedure time-tai->date
(time . tz-offset)> respects local DST if no TZ-OFFSET given
FAIL: srfi-19.test: SRFI date/time library: #<procedure
time-monotonic->date (time . tz-offset)>
respects local DST if no TZ-OFFSET given
FAIL: srfi-19.test: SRFI date/time library: #<procedure julian-day->date
(jdn . tz-offset)> respects local DST if no TZ-OFFSET given
FAIL: srfi-19.test: SRFI date/time library: #<procedure
modified-julian-day->date (jdn . tz-offset)> respects local DST if no
TZ-OFFSET given
FAIL: srfi-19.test: SRFI date/time library: string->date respects local
DST if no time zone is read
Running srfi-4.test
Running srfi-9.test
Running strings.test
Running symbols.test
Running syncase.test
Running syntax.test
Running time.test
Running version.test
Running weaks.test

Totals for this test run:
passes:                 2227
failures:               6
unexpected passes:      0
expected failures:      18
unresolved test cases:  0
untested test cases:    0
unsupported test cases: 9
errors:                 0

FAIL: check-guile
===================
1 of 1 tests failed
===================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/usr/local/src/guile164'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/usr/local/src/guile164'
make: *** [check-recursive] Error 1

Are these failures important and are they just system-specific?  I can
provide my check-guile.log if needed.

Thanks for any help,

Kevin



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Guile 6.4 on NCR MPRAS

[Kevin Ryde]

Kevin Pendleton <kevin@electron-pc.com> writes:
>
> I then set LIBS="-lm -lmw -lnsl"

configure is supposed to grab -lnsl when needed, by looking for
gethostbyname.  You can check if that's happened.  It ought to get
into libguile.la as a dependency.

What's -lmw and what's it needed for?

> FAIL: srfi-19.test: SRFI date/time library: #<procedure time-utc->date
> (time . tz-offset)> respects local DST if no TZ-OFFSET given

Might be the way TZ is changed only with putenv (in the tests).  I
think configure decides a LOCALTIME_CACHE for when tzset needs to be
called (and it's then called by `localtime' etc).  You might have to
investigate further.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Guile 6.4 on NCR MPRAS

[Kevin Pendleton]

On Sat, 2004-03-27 at 14:33, Kevin Ryde wrote:
> Kevin Pendleton <kevin@electron-pc.com> writes:
> >
> > I then set LIBS="-lm -lmw -lnsl"
> 
> configure is supposed to grab -lnsl when needed, by looking for
> gethostbyname.  You can check if that's happened.  It ought to get
> into libguile.la as a dependency.
> 

Looking at it all again, I have found that there are just the two LIBS
that are needed.  I did not need to add "-lm".  "-lnsl" does not get
added appropriately.  When checking for gethostbyname, it fails both
times, (undefined reference to `gethostbyname'), with and without
-lnsl.  Here's the synopsis from the man page for gethostbyname for
MPRAS:

          #include <sys/types.h>
          #include <sys/socket.h>
          #include <netdb.h>

          struct hostent *gethostent()

          struct hostent *gethostbyaddr(addr, len, type)
          char *addr;
          int len, type;

          struct hostent *gethostbyname(name)
          char *name;

          sethostent(stayopen)
          int stayopen

          endhostent()

> What's -lmw and what's it needed for?

The way I understand it, for NCR MP-RAS systems, the system needs to
explicitly link against -lmw to pull in some symbols such as
_mwoflocheckl and others.  This was discovered during the configuration
of perl for MPRAS. For more details on the perl hints file see:

http://search.cpan.org/src/JHI/perl-5.8.1/ext/POSIX/hints/svr4.pl

If I include -lnsl and not -lmw I get the following two errors:

./.libs/libguile.so: undefined reference to `_mwvalidcheckl'
./.libs/libguile.so: undefined reference to `_mwoflocheckl'

> 
> > FAIL: srfi-19.test: SRFI date/time library: #<procedure time-utc->date
> > (time . tz-offset)> respects local DST if no TZ-OFFSET given
> 
> Might be the way TZ is changed only with putenv (in the tests).  I
> think configure decides a LOCALTIME_CACHE for when tzset needs to be
> called (and it's then called by `localtime' etc).  You might have to
> investigate further.

I'll have to continue to look into this part.

Thanks,

Kevin



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Guile 6.4 on NCR MPRAS

[Kevin Ryde]

Kevin Pendleton <kevin@electron-pc.com> writes:
>
> When checking for gethostbyname, it fails both
> times, (undefined reference to `gethostbyname'), with and without
> -lnsl.

config.log will contain the code of the failing program, you can see
if it works or if it needs to be massaged.

>           #include <sys/types.h>
>           #include <sys/socket.h>
>           #include <netdb.h>

Maybe the test program will need these includes, if there's something
silly being done with macros.

> The way I understand it, for NCR MP-RAS systems, the system needs to
> explicitly link against -lmw to pull in some symbols such as
> _mwoflocheckl and others.

I see libtool AC_CHECK_LIBM knows to do this on *-ncr-sysv4.3*.  We
should either use that, or do something similar.  Does a program using
say "cos" fail to link if -lm is used but not -lmw too?


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Guile 6.4 on NCR MPRAS

[Kevin Pendleton]

On Tue, 2004-03-30 at 15:05, Kevin Ryde wrote:
> Kevin Pendleton <kevin@electron-pc.com> writes:
> >
> > When checking for gethostbyname, it fails both
> > times, (undefined reference to `gethostbyname'), with and without
> > -lnsl.
> 
> config.log will contain the code of the failing program, you can see
> if it works or if it needs to be massaged.
> 
I am also working on compiling some other programs and I noticed that
Tcl's configure was able to find gethostbyname, so I took a look at the
way it is done there and noticed this comment:
   
#--------------------------------------------------------------------
#   Check for the existence of the -lsocket and -lnsl libraries.
#   The order here is important, so that they end up in the right
#   order in the command line generated by make.  Here are some
#   special considerations:
#   1. Use "connect" and "accept" to check for -lsocket, and
#      "gethostbyname" to check for -lnsl.
#   2. Use each function name only once:  can't redo a check because
#      autoconf caches the results of the last check and won't redo it.
#   3. Use -lnsl and -lsocket only if they supply procedures that
#      aren't already present in the normal libraries.  This is because
#      IRIX 5.2 has libraries, but they aren't needed and they're
#      bogus:  they goof up name resolution if used.
#   4. On some SVR4 systems, can't use -lsocket without -lnsl too.
#      To get around this problem, check for both libraries together
#      if -lsocket doesn't work by itself.
#--------------------------------------------------------------------

Looking at the configure for guile it attempts to find connect after
gethostbyname, etc.  Comparing the two configure files, there have been
some small changes to those functions as well.  It looks like guile's
configure was made with Autoconf 2.57 and Tcl's configure was made with
Autoconf 2.59.  Is it possible that this has already been hashed out and
resolved?  What is the best way to recreate configure?  Should I just
manually change configure and send in the diff?

> I see libtool AC_CHECK_LIBM knows to do this on *-ncr-sysv4.3*.  We
> should either use that, or do something similar.  Does a program using
> say "cos" fail to link if -lm is used but not -lmw too?
> 
I know I have had problems with this in the past but am currently unable
to remember with what.

Kevin



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Guile 6.4 on NCR MPRAS

[Kevin Ryde]

Kevin Pendleton <kevin@electron-pc.com> writes:
>
> #   2. Use each function name only once:  can't redo a check because
> #      autoconf caches the results of the last check and won't redo it.
> #   3. Use -lnsl and -lsocket only if they supply procedures that
> #      aren't already present in the normal libraries.  This is because
> #      IRIX 5.2 has libraries, but they aren't needed and they're
> #      bogus:  they goof up name resolution if used.

AC_SEARCH_LIBS probably covers this.  Probe libraries, add them if
they're needed, don't add them if they're not.

> #   4. On some SVR4 systems, can't use -lsocket without -lnsl too.
> #      To get around this problem, check for both libraries together
> #      if -lsocket doesn't work by itself.

Or I presume just ensure -lnsl is probed first.

> Is it possible that this has already been hashed out and resolved?

Probably not.

> What is the best way to recreate configure?

You can try going from the guile cvs, either the head or the
branch_release-1-6, and have a look at autogen.sh.

Modest fixes can get into the 1.6 branch, major surgery will have to
wait for the head and the next major release.

> Should I just manually change configure and send in the diff?

No, not configure, but you can advise what's needed for configure.in.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user