--4bRzO86E/ozDv8r1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Georg Schwarz <geos@epost.de> wrote:
> I am currently trying to get the NetBSD pkgsrc collection compile on an
> IRIX 5.3 system. As it turns out IRIX 5.3 is really old and seems to
> lack many of the features that IRIX 6.5.X must have (judging from the
> fact that it is listed as supported for pkgsrc).
>=20
> Nevertheless my efforts make steady progress (updated details can be
> found here: http://geos.maxsyncron.com/netbsd-pkgsrc-on-irix5.3;
> feedback would be appreciated), and I have already over 75 packages
> installed, being limited mainly by my SGI's speed...

This is great news.  I've had your posting in my inbox for a while and
ment to take a closer look at this, but have not yet gotten around to
it.  Nevertheless, if only so you know that your work is appreciated and
that we're interested, let me reply to some of the points you mention in
this mail and give you at least my $.02:

> - some packages make certain assumptions about available software that
> are not necessarily met. Examples are:
>=20
>  * security/audit-packages assumes that nroff is present without trying
> to install it (or a suitable replacement) if it is not available.

This should be fixed.  We should probably develop a buildlink for
textproc/groff which determines if the systems *roff (if existent) is
sufficient and if not creates a dependency on textproc/groff.  Any
package that needs (a) *roff would then need to include this buildlink.
Or maybe the defs.${OS}.mk should determine which roff is needed?

Either way, I think this is something that should be send-pr'd.

>  * archivers/afio needs fnmatch.h (and probably the respective library)
>  * many packages (e.g. php) require regex.h (and probably the respective
> library)

Both these issues apply to your bootstrapping process, too, so once
they're solved for boostrap, they should no longer be an issue.  Now as
to how bootstrap gets those... that's a different story.  Maybe when we
get around to merging bootstrap with regular pkgsrc we can find a
solution for this, too.

> - databases/db (and maybe others, too) assumes that CHOWN uses a : to
> separate group from user name. With IRIX's chown for example, it should
> be '.' instead. It would be a good idea not to hard code it into the
> scripts but to use a cofigurable variable like CHOWN_SEP_CHAR for it
> (which would default to ":").

Hmmm, I don't think I would like Yet Another Variable that would have to
go through all of pkgsrc.  But I don't have a better solution at hand,
either.  (FWIW, later Irix versions obviously support ':' -- they allow
both.)

> - many packages such as bftp or arpd, to name two, use -Wall. If a cc
> does not support that they fail to compile. Does pkgsrc offer a clean
> mechanism to get around this?

I believe that all compiler flags should be provided by pkgsrc, and not
by the package itself.  That is, these packages would need to be
patched, I'm afraid.

> - the output of LDD (defaults to ldd) is piped through awk 'NF =3D=3D 3
> {print $3}'. This implies that meaningful lines (i.e. the ones that list
> shared libraries) consist of exactly three columns. I've checked this on
> a Linux an a FreeBSD installation, and there it is a total of four
> columns, so that output should never match.

I'd say send-pr this.

> IRIX 5.3 BTW does not have ldd at all so I had to write a replacement
> script.

Sheesh!  Irix 5.3 sounds like FUN! ;-)

> - I am using LOCALBASE=3D/usr/local/pkg, which is non-standard, but should
> work nonetheless. Some packages such as archivers/dar will fail to find
> zlib.h for configure, even though the zlib-1.1.4nb1 package is installed
> and /usr/local/pkg/include/zlib.h exists.
> python22 seems to have similar problems.

These need to be send-pr'd so they work with non-standard LOCALBASE.  If
you have patches...

> - it appears that pkgsrc makes some effort to preserve the PATH
> environment variable when doing a su. However, it does not do so with
> LD_LIBRARY_PATH. If, as with guspatches for example, zip is being called
> in the installation process I have to do bmake install
> LD_LIBRARY_PATH=3D$LD_LIBRARY_PATH when issuing that command as non-root
> (evocing su being used). This seems to do the trick.

Pkgsrc doesn't use LD_LIBRARY_PATH.  All packages should be compiled
with the proper rpath flags as applicable to the OS/compiler/linker to
allow running the commands without LD_LIBRARY_PATH.  If an application
requires LD_LIBRARY_PATH then it should be fixed -> send-pr.

> - what about some "basic" software such as man apparently not included
> in pkgsrc. Should one compile it directly from the GNU sources?

Ideally pkgsrc (and bootstrap) would be self-hosting, I think.  But of
course one needs a compiler, a shell and some other things before one
can get started.  I guess that we have to draw a line somewhere where we
say this and that is required before you try to bootstrap.  We haven't
yet drawn that line, I believe.

> - what is the cleanest way to set specific compiler optimization
> options? (e.g. on IRIX it would make sense to use some -Olimit value
> when optimizing)=20

Optimizations are site-specific, no?  They should go into your own
/etc/mk.conf, I'd say.  Some other sites might not want to use the same
optimizations.  Otherwise, maybe add them to devel/cpuflags ?

-Jan

--=20
Probability factor of one to one. We have normality. I repeat, we have=20
normality. Anything you still can't cope with is therefore your own lookout.

--4bRzO86E/ozDv8r1
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFACGLgfFtkr68iakwRAkO0AJ9H9jcjkTMiDOomGhv2cfS68QNhswCfarJb
XwngfyhTQJ0UbqK+yqnEPHY=
=OgpK
-----END PGP SIGNATURE-----

--4bRzO86E/ozDv8r1--