compilation issues

compilation issues

[Oliver Kiddle]

In advance of any final release, I thought I'd try compiling on the
various sourceforge compile farm machines.

x86 Linux 2.2 (Debian 2.2) - only a couple of warnings (for zftp in zfgetline)

ppc Linux 2.2 (Debian 2.2)

no problems except test of [[ -N .. ]] - probably due to NFS.

x86 FreeBSD 4.2-stable

make check yields several
/usr/libexec/ld-elf.so.1: Shared object "libzsh-4.0.1-pre-5.so" not found

It seems that make check uses a `make install.modules' but libzsh is
installed as part of `make install.bin'. We need to fix this but I'm not
sure I fully understand this part of the Makefiles. Isn't this an issue
for cygwin?

Once I had them running, there were a couple of test failures. The
first was due to it failing to find any block device files (second test
in C02cond). I expect that sourceforge are giving us a chrooted
environment but if this is typical of FreeBSD we need to check $block
and do something sane if it fails to find a block device. One of the
trap tests seems to fail too but not consistently so I haven't tracked
it down.

alpha Compaq Tru64 5.1

It was this machine where I got the V01zmodload test seg fault so it
isn't just Solaris and Cygwin.

A number of warnings including many like this:

cc: Info: compctl.c, line 516: In this statement, an array subscript expression
is either less than zero or greater than the largest value that can be represent
ed by the size_t type. (badsubscript)
                        *argv = "" - 1;
---------------------------------^

Every time it links a shared object it also warns about a list of
unresolved symbols. These are basically all the mod_exported symbols.

The other test failure was in C02cond, the [[ -e /dev/fd/0 ]] test.
This is exactly the same problem as I fixed for AIX in 10073 but unlike
AIX, there is no faccessx system call to fix this easily here. Any
ideas how to work out the access permissions for an open file
descriptor?

sparc Sun Solaris 8, gcc

Presumably most people are using Sun's compiler for this but they only
have gcc and it fails at its first invocation with this:

gcc -c -I.  -DHAVE_CONFIG_H -Wall -Wno-implicit -Wmissing-prototypes -O2  -o builtin.o builtin.c
In file included from zsh.mdh:15,
                 from builtin.c:30:
system.h:155: redefinition of `struct timezone'
In file included from zsh.mdh:16,
                 from builtin.c:30:
zsh.h:1469: field `tchars' has incomplete type
In file included from zsh.mdh:41,
                 from builtin.c:30:
jobs.epro:9: `MAXJOB' undeclared here (not in a function)
In file included from zsh.mdh:53,
                 from builtin.c:30:
signals.epro:27: parse error before `handler'
signals.epro:27: warning: data definition has no type or storage class
builtin.c:141: warning: no previous prototype for `createbuiltintable'

followed by many similar warnings for builtin.c.

sparc Linux 2.2 (Debian 2.2)

no problems except the same [[ -e /dev/fd/0 ]] failure as for Tru64. /dev/fd
doesn't exist which is odd as this is Linux. Maybe chroot or maybe /dev/fd
support can be compiled out of the kernel.

Oliver

Re: compilation issues

[Andrej Borsenkow]

On Wed, 23 May 2001, Oliver Kiddle wrote:

> x86 FreeBSD 4.2-stable
>
> make check yields several
> /usr/libexec/ld-elf.so.1: Shared object "libzsh-4.0.1-pre-5.so" not found
>
> It seems that make check uses a `make install.modules' but libzsh is
> installed as part of `make install.bin'. We need to fix this but I'm not
> sure I fully understand this part of the Makefiles. Isn't this an issue
> for cygwin?
>

No, it was there long before. I suspect, that tests were never run on a
system that needed libzsh (or already installed version was silently
used).

Exactly on Cygwin it runs correctly, because it tries first to find DLL in
the same directory as executable.

-andrej

Re: compilation issues

[Peter Stephenson]

Oliver Kiddle wrote:
> alpha Compaq Tru64 5.1
> 
> It was this machine where I got the V01zmodload test seg fault so it
> isn't just Solaris and Cygwin.

This sounds like it needs something added in Etc/MACHINES.

> sparc Sun Solaris 8, gcc
> 
> Presumably most people are using Sun's compiler for this but they only
> have gcc and it fails at its first invocation with this:

As I said yesterday, I had no problem at all with SunOS 5.8 with gcc with
the default configuration.  I was using gcc 2.95.2.  It could be another
manifestation of the problems with warnings in headers, but there are still
some odd things going on.

> gcc -c -I.  -DHAVE_CONFIG_H -Wall -Wno-implicit -Wmissing-prototypes -O2  -o builtin.o builtin.c
> In file included from zsh.mdh:15,
> 		   from builtin.c:30:
> system.h:155: redefinition of `struct timezone'

You should have

#define HAVE_STRUCT_TIMEZONE 1

which avoids this.  struct timezone is defined in sys/time.h:

#if (!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)) || \
        defined(__EXTENSIONS__)
#ifndef _ASM
struct timezone {
        int     tz_minuteswest; /* minutes west of Greenwich */
        int     tz_dsttime;     /* type of dst correction */
};

#endif  /* _ASM */
#endif  /* (!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE))... */

> In file included from zsh.mdh:16,
> 		   from builtin.c:30:
> zsh.h:1469: field `tchars' has incomplete type

That means HAVE_TERMIO_H isn't being defined as it should be.

> In file included from zsh.mdh:41,
> 		   from builtin.c:30:
> jobs.epro:9: `MAXJOB' undeclared here (not in a function)

This is very suspicious --- this should be defined by configure in
config.h.  It should default to 50.

> In file included from zsh.mdh:53,
> 		   from builtin.c:30:
> signals.epro:27: parse error before `handler'
> signals.epro:27: warning: data definition has no type or storage class

That means RETSIGTYPE isn't being defined properly in config.h.  It ought
to be `void'.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: compilation issues

[Sven Wischnowsky]

Peter Stephenson wrote:

> Oliver Kiddle wrote:
> > alpha Compaq Tru64 5.1
> > 
> > It was this machine where I got the V01zmodload test seg fault so it
> > isn't just Solaris and Cygwin.
> 
> This sounds like it needs something added in Etc/MACHINES.

Hm, I'm working on a Tru64 box. V01 ends for me with a core dump, too
(from a floating point exception). And before that I get lots of
`Unresolved symbol ...' from the loader. Something I haven't seen before
and which doesn't happen with that version in normal work.

Hm, it happens at the unload for me, too. The messages about the
unresolved symbols are ok, because the last-but-one test removes all
dependencies, so zmodload thinks it can unload all modules and it's just
that the loader here is clever enough to tell us that some modules have
problems after other modules they really depend upon have been unloaded.

If I try to do at least some of the steps from the test by hand, I don't
get the floating point exception. Looking at the core dump: this seems
to have to do with the zprof module (that seems to make sense, there are
functions running and zprof hooks into the function calling code, but
that should be taken care of (delayed unloading)). And even if I wrap
some functions around the calls to zmodload I don't get the exception.

Dunno what to do now.


The other tests using modules work fine.

Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: compilation issues

[Oliver Kiddle]

Peter Stephenson wrote:

> > gcc -c -I.  -DHAVE_CONFIG_H -Wall -Wno-implicit -Wmissing-prototypes -O2  -o builtin.o builtin.c
> > In file included from zsh.mdh:15,
> >                  from builtin.c:30:
> > system.h:155: redefinition of `struct timezone'
> 
> You should have
> #define HAVE_STRUCT_TIMEZONE 1
 
I went to have a closer look at this this morning and it did erroneously
have #undef HAVE_STRUCT_TIMEZONE in config.h. Strangely though, when I
reran configure it changed its mind and I can't get it to fail as before
now. Something strange must have happened when I ran configure yesterday
but it all seems fine now including all tests.

I've also now done a test build on alpha/NetBSD which was successful
including tests apart from the same problem as FreeBSD with make check
not installing the libzsh-4.0.1-pre-5.so.

Oliver