Subject: Re: CVS commit: othersrc/bootstrap-pkgsrc
To: None <tech-pkg@NetBSD.ORG>
From: MLH <MLH@goathill.org>
List: tech-pkg
Date: 03/01/2003 01:00:54
On 28 Feb 2003 02:50:01 -0600, Simon J. Gerraty wrote:
>>On 27 Feb 2003 23:35:00 -0600, grant beattie wrote:
>>>> Right now, /opt/SUNWspro/bin/cc can't be used because the recommended
>>>> /usr/ucb/install trashes SUNWspro binaries when it tries to strip
>>>> them and /usr/sbin/install uses different arguments. And you can't
> 
> Isn't it more that Sun's strip command trashes binaries created by Sun's
> compiler?
> 
> Anyway, why not simpy do without strip?  
> _STRIPFLAG_INSTALL=""
> on the command line should do it (based on a 10s look at pkgsrc/mk so
> no guarantee ;-)

Ok. I figured it out. gcc's strip is what is causing the problem.
Gcc's strip doesn't grok the workshop compiler's objects. So just
specifying which compiler to use isn't enough, one has to either
change one's path and put /usr/ccs/bin before the gcc compiler or
have some way of specifying which strip /usr/ucb/install is to use.
I don't see anything in the /usr/ucb/install manpage that would
allow one to specify this.  /usr/ccs/bin/strip works. Sure would
be handy if this were documented.

But I'm still back to the problem with devel/m4:

checking whether we are using GNU C... no
checking for a BSD compatible install... /usr/ucb/install -c -o root -g root
checking whether /usr/pkg/bin/bmake sets $MAKE... ./configure: bad substitution

However, thanks for fixing the id -u problem in bootsrap. It works
now.

As to the other person trying to use othersrc/bootstrap-pkgsrc on
Solaris, he's on :
  SunOS ss20a 5.9 Generic sun4m sparc SUNW,SPARCstation-20
and is using the gcc-2.95.3 referenced in pkgsrc, but he built
manually in order to build bootstrap. He had tried using the
sunfreeware gcc but ran into problems there and couldn't build
bootstrap. With gcc-2.95.3, he got bootstrap built, but is having
trouble with pkgsrc packages:

Any ideas on how to help him? I'm wondering if xpg4 is causing his
problems as he's using that am I'm not.

Thanks
====================================================
The above is a typical example from the first post-bootstrap
package I tried to build.  Notice, that the check of the host
system type is botched.  if I go down into the work directory
and run "config.guess" manually, it correctly determines
"sparc-sun-solaris2.9".  But somehow the 'sparc' substring is
being lopped off when the configure script is running in the
pkgsrc automata.

...

This is seriously frustrating.  I wish the system could make up its
mind about whether the OMF is ELF or a.out.

Seems every time I turn around, it complains that such-and-such package
that's already installed is one OMF and that I'm trying build in the
other OMF.

I think I've found the root of the problem, though.

    /usr/pkgsrc/mk/bsd.prefs.mk

fails to set "MACHINE_ARCH" properly, so it defaults to "a.out".  (It
also explains the botching of "MACHINE_GNU_PLATFORM" as "-sun-solaris".)

I've forced "MACHINE_ARCH=sparc" in /etc/mk.conf.  That's when things
started making the converse complaint about incompatible OMFs.

With that bit of knowledge, I'm going to start over from scratch again.

BTW, I tried to build "xpkgwedge" and it stops, claiming:

=====> xpkgwedge-1.7 is not available for SunOS-5.9-tvo4

That's when I figured out the MACHINE_ARCH problem.  With it fixed,
it still complains

=====> xpkgwedge-1.7 is not available for SunOS-5.9-sparc
/