Re: zsh 4.0.1 make check failures on irix, freebsd, solaris, aix, linux

[Timothy Miller <tsm@xxxxxxxxxxxxxxxxxxxx>]

On Sat, 9 Jun 2001 04:59:24 +0000, "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Thanks for the feedback, Tim ...

You're welcome.

> The failures in Y03 are a known problem that occurred as a result of a
> last-minute patch for a different problem.  A fix has been applied to the
> CVS repository at SourceForge <https://sourceforge.net/cvs/?group_id=4068>.
> You will probably want to "cvs -d ... co -r zsh-4_0-patches".

Ok; I'll take a look at this a little later..

> } On Irix 6.3, gcc 2.8.0, C02, Y01, Y02, Y03 fail. Y0[123] appear to be due to 
> } zpty failure, which is documented as a lack of support, so I don't include
> } them (just C02). Using the SGI cc gives essentially the same result.
> 
> The -N test is known to fail on NFS filesystems.  Is your build dir NFS'd?

Yes, that's probably it then.

> } On Irix 6.5, gcc 2.91.66, again fails C02
> } On Solaris 2.7 (Sunos 5.7), gcc 2.95.3, C02
> 
> Test ./C02cond.ztst failed: bad status 1, expected 0 from:
>   [[ -g modish && ! -g zerolength ]]
> 
> I tend to think this is NFS-related as well; the test is initialized by
> trying to chmod a directory for set-group-id.  Depending on the NFS
> mount options and whether the current user's default group exists on
> the remote server, that might not be possible.

The source directory is on a filesystem mounted with grpid so new
directories get the parent group, but the parent group isn't one I'm in, so
I presume that was the problem. It might help to have some code to test for
that case and try to deliberately "chgrp $GID <whatever>" if the new
directory's group isn't in $(groups).

> } On RedHat 7.0 linux 2.2.16 gcc 2.96 20000731, C02
> 
> Test ./C02cond.ztst failed: bad status 1, expected 0 from:
>   if ! grep '#define HAVE_FIFOS' $ZTST_testdir/../config.h; then
>     print -u8 'Warning: Not testing [[ -p pipe ]] (FIFOs not supported)'
>     [[ ! -p zerolength ]]
>   else
>     if whence mkfifo && mkfifo pipe || mknod pipe p; then
>       [[ -p pipe && ! -p zerolength ]]
>     else
>       print -u8 'Warning: Not testing [[ -p pipe ]] (cannot create FIFO)'
>       [[ ! -p zerolength ]]
>     fi
>   fi
> 
> I suspect NFS again, particularly if one of the SGI machines is your NFS
> server.  I wouldn't expect a FIFO created on an NFS filesystem to work
> properly (though it should when both client and server are Linux).

Ok. (The server's a sun, though, just so you know.) Is there a reason not to 
put your temporary testing files in /tmp if NFS is a problem?

> } determined that the link line for both gcc and cc lacks -L to tell it where
> } to find libzsh-... Adding that manually produced a zsh which ran and
> } immediately segfaulted (even with -f).
> 
> The -L information is helpful, thanks (in fact, if you could post a short
> manual excerpt relating to it that might be helpful too).

Some more details then:

the zsh linking command from "CC=cc ./configure --prefix=/cs" is

LD_RUN_PATH=/cs/lib/zsh cc -qlanglvl=ansi  -s  -o zsh main.o libzsh-4.0.1.so -ldl -lcurses -lm  -lc

The error that produces on trying to run the resulting zsh is

exec(): 0509-036 Cannot load program ./zsh because of the following errors:
        0509-022 Cannot load library libzsh-4.0.1.so.
        0509-026 System error: A file or directory in the path name does not 
        exist.

I changed the link line to

cc -qlanglvl=ansi  -s  -o zsh main.o  -L/cs/lib/zsh libzsh-4.0.1.so -ldl -lcurses -lm  -lc

which produced the zsh that just segfaulted. It turns out it doesn't
segfault if you don't install any modules and run it with -f, but does if
the modules are installed or -f isn't given.

some relevant excerpts from the ld man page:

    Note: If you specify a shared object, or an archive file containing a shared
    object, with an absolute or relative path name, instead of with the -lName
    flag, the path name is included in the import file ID string in the loader
    section of the output file. You can override this behavior with the
    -bnoipath option.

[...]

-LDirectory Adds Directory to the list of search directories used for finding
libraries designated by the -l (lowercase letter L) flag. The list of
directories, including the standard library directories, is also recorded in the
output object file loader section for use by the system loader unless you use
the -blibpath or -bnolibpath option. You can repeat this flag.

[...]

Options (-bOptions)

The following values are possible for the Options variable of the -b flag. You
can list more than one option after the -b flag, separating them with a single
blank.

[...]

libpath:Path Uses Path as the library path when writing the loader section of
the output file. Path is neither checked for validity nor used when searching
for libraries specified by the -l flag. Path overrides any library paths
generated when the -L flag is used.

If you do not specify any -L flags, or if you specify the nolibpath option, the
default library path information is written in the loader section of the output
file. The default library path information is the value of the LIBPATH
environment variable if it is defined, and /usr/lib:/lib, otherwise.

[...]

Environment Variables

[LD_RUN_PATH is NOT listed]

[...]

LIBPATH If LIBPATH is defined, its value is used as the default libary path
information. Otherwise, the default library path information is /usr/lib:/lib.
If no -L flags are specified and no -blibpath option is specified, the default
library path information is written in the loader section of the output file.
Regardless of any options specified, LIBPATH is not used when searching for
libraries that are specified from the command line.

> } but, surprisingly, not Y03.
> 
> That is surprising.  My guess is it never got tried.

If I do "ZTST_verbose=1 gmake TESTNUM=Y03 check" it just prints out
"./Y03arguments.ztst: starting.", pauses for a bit, and then exits (not
printing anything more), so you seem to be right.
   Tim