Subject: Re: pkgsrc on IRIX...
To: Jan Schaumann <jschauma@netmeister.org>
From: Stuart Shelton <stuart@zeus.com>
List: tech-pkg
Date: 09/05/2005 04:06:29
On Sun, 2005-08-14 at 19:38 -0400, Jan Schaumann wrote:
> Stuart Shelton <stuart@zeus.com> wrote:
>  
> > Seriously, though - do you know what machine/OS/compiler suite these
> > packages are compiled with?  I guess they're probably gcc rather than
> > MIPSpro - which is fine of course, but it'd be great to be able to
> > confirm that packages do build with the OS' own compiler.
> 
> Actually, the packages are built with MIPSPro 7.41.

I'm now on IRIX 6.5.28 with a fully-patched MIPSpro 7.4.3m compiler
suite.  Apparently, SGI re-wrote huge chunks of the suite for 7.4.3, so
there could be significant differences.

> > > bmake: "/usr/bsd/src/x11/fox/Makefile" line 22: warning: String comparison operator should be either == or !=
> > > bmake: "/usr/bsd/src/x11/fox/Makefile" line 22: Malformed conditional ((${OPSYS} == "NetBSD") && (${OS_VERSION:R} < 3))
> > > bmake: "/usr/bsd/src/x11/fox/Makefile" line 22: Missing dependency operator
> > > bmake: "/usr/bsd/src/x11/fox/Makefile" line 24: if-less endif
> > > bmake: "/usr/bsd/src/x11/fox/Makefile" line 24: Need an operator
> > > bmake: Fatal errors encountered -- cannot continue
> > 
> > Oops...
> 
> Hmm.  If this is still the case in the latest version, then this needs
> to be fixed.  Could you (did you) send-pr this?

I don't actually remember whether I did a send-pr on this, but now I try
to install it again it does seem to work, so one way or another it seems
to be fixed.

Now I've just got to try to remember what I wanted this package for ;)

> > > printf string <LI><STRONG> apache\\&lt;1.3.14 has a re ... too long
> > > Input record number 82410, file /tmp/mkreadme/database
> > > Source line number 369
> > > Error:  genreadme.awk failed to create README.html files
> > > *** Error code 1
> > > 
> > > Stop.
> > 
> > Hmm - now I'm wondering if this is an OS issue again.  IRIX seems to
> > want to only accept a very small number of command-line arguments, and
> > I'm not sure how (or if) I can alter this.  For example, doing a "grep
> > foo *" in a directory with even only a few hundred items will result in
> > "Arg list too long".  Is this limit perhaps being reached here?
> 
> Most likely.  We've been trying to work around such OS limitations, but
> occasionally there are some bugs to iron out left.  This is during 'make
> readme', right?  Again, this probably should be submitted as a PR, to
> make sure that it gets addressed and not forgotten.

Fair enough - I'll file one now.

I increased the number of allowed arguments with "systune ncargs
65535" (which can also be achieved by adding "ncargs  = 65535"
to /var/sysgen/stune) - although the maximum value seems to be 65528
(0xfff8).

This time the error is:

Generating package README.html files
 
Reading database file
Making sure binary package cache file is up to date...
----> Checking master cache file /usr/bsd/src/packages/.pkgcache
      Creating master cache file /usr/bsd/src/packages/.pkgcache
Loading binary package cache file...
    * /usr/bsd/src/packages/.pkgcache
Flattening dependencies
Flattening build dependencies
Reading vulnerability file "/usr/bsd/src/distfiles/pkg-vulnerabilities"
 which was updated at Sep 3 18:03

   Loaded 1388 vulnerabilities
Generating README.html files
.............................sprintf string <LI><STRONG> mysql-server\
\&lt;3.23.
49nb ... too long
Input record number 100290, file /tmp/mkreadme/database
Source line number 369
Error:  genreadme.awk failed to create README.html files
*** Error code 1

Stop.

One other thing I notice is that this output suggests that the files are
being generated from /tmp/, rather than from the pkgsrc tmp directory
(/usr/bsd/var/tmp/) - which could be an issue on IRIX where the default
is very small root partitions (where /tmp lives) with only about 70Mb of
free space.

/tmp can't be made to be a symlink to /usr/tmp because it is needed for
system recovery purposes before /usr is mounted, and I'm not aware of
IRIX supporting bind-mounts.
Update: I've just noticed that the script makes use of TMPDIR, so I've
now set this.

My other observation is that I can override the tool locations used by
running, e.g. "bmake GREP=/usr/bsd/bin/grep readme" - which seems to
work for all parameters but AWK, where I can't seem to change the value
from /usr/bin/nawk - so this problem might be caused by a non-overridden
tool which doesn't react in the way that pkgsrc expects.

Update: Actually, this is interesting: If I invoke
"AWK=/usr/bsd/bin/nawk bmake clean" then the value I specify isn't used.
If I invoke "bmake AWK=/usr/bsd/bin/nawk clean" then it is.  Is the AWK
value (only) being clobbered somewhere?  The other values (CMP, FGREP,
GREP, FIND, SED, SORT, etc.) work fine with prefixing or postfixing
"bmake".

Additionally, if I add these default tool locations to /etc/mk.conf,
then again all values apply except for those for AWK and ECHO, which
remain at the default "/usr/bin/nawk" and "echo" values.

With BSD/GNU versions of the utilities, "bmake readme" does complete,
but still appears broken:

Generating category readmes
Category = archivers
...
Category = x11
Generating toplevel readmes:
        /usr/bsd/src/README.html
        /usr/bsd/src/README-all.html
 
Generating the README-IPv6.html file
 
./mk/scripts/mkreadme[422]: /usr/bsd/bin/grep: arg list too long
 
Pruning unused README.html files
 
./mk/scripts/mkreadme[450]: /usr/gnu/bin/ls: arg list too long
 
README.html generation finished:  Sun Sep  4 20:28:05 BST 2005
 
A fix for this would be to change lines 451-452 of mkreadme to:

    for d in `${FIND} -type d -maxdepth 2` ; do
        if [ ! -f ${d}/Makefile -a -f ${d}/README.html ]; then

... and line 422 to:

cat /dev/null > $ipv6
for FILE in */*/Makefile */*/options.mk; do
    ${GREP} -l -e '^BUILD_DEFS.*=.*USE_INET6' -e
'^PKG_SUPPORTED_OPTIONS.*=.*ine
t6' $FILE | ${SED} -e 's;Makefile;;g' -e 's;options.mk;;g' >> $ipv6
done

> > Finally, gettext-0.11.5nb5:
> > 
> > > cc-1054 cc: ERROR File = po-lex.c, Line = 517
> > >   There are not enough arguments in a macro invocation.
> > > 
> > >                     po_gram_error (_("invalid multibyte sequence"));
> > >                                                                   ^
> > 
> > > cc-1054 cc: ERROR File = po-lex.c, Line = 544
> > >   There are not enough arguments in a macro invocation.
> > > 
> > >   incomplete multibyte sequence at end of file"));
> > >                                                 ^
> > 
> > > cc-1054 cc: ERROR File = po-lex.c, Line = 1049
> > >   There are not enough arguments in a macro invocation.
> > > 
> > >                                            _("end-of-line within string"));
> > >                                                                          ^
> > 
> > Any clues on this one?
> 
> Hmm, strange.  I don't get this error on IRIX64 6.5.23f with CC 7.41.

What options are you building with?  With 7.3.4m and CFLAGS="-c99 -O2
-n32 -mips4 -r12000 -apo -float_const -use_readonly_const
-TARG:isa=mips4:platform=ip30:processor=r12000 -TENV:zeroinit_in_bss=ON
-DEFAULT:platform=ip30
-OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON
-LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -woff
1174,1183,1552" the compilers barfs at the macro definitions in po-lex.h
and po-lex.c.

I've just a couple of days ago submitted a patch to fix this to the list
(which only adds one additional check to each file to use a function
rather than a macro - which should mean that the only penalty is a
potential slight drop in efficiency on MIPSpro compilers which do
compile the macros successfully).

Cheers,

	Stuart