mips.mips64elhf and mips.mips64el buildworld

[Cy Schubert]

In message <A3D57ABC-B3CC-4B90-B009-3527B3F9F10A at FreeBSD.org>, Dimitry 
Andric w
rites:
> 
>
> --Apple-Mail=_E66CB1B0-06CC-4CF6-A1CF-8037AA029C13
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> 	charset=us-ascii
>
> On 4 Apr 2018, at 17:02, Cy Schubert <Cy.Schubert at cschubert.com> wrote:
> > 
> > In message <06A6FF73-A15B-4EA1-854A-B2B741FB7E63 at FreeBSD.org>, Dimitry
> > Andric writes:
> ...
> >> Which program is producing the "could not read symbols" output?  The
> >> linker?  Maybe it trips up over these 32-bit shared libraries.
> > 
> > Yes, it appears to be the linker.
> > 
> >> 
> >> It would probably help a bit if you posted the buildworld output
> >> somewhere, so it is more easily visible how the libraries are built,
> >> and by which program(s) they are processed.
> > 
> > Do you have access to universe12b.freebsd.org? The output is in
> > /home/cy/projects/pvt/_.mips.mips64elhf.buildworld and
> > /home/cy/projects/pvt/_.mips.mips64el.buildworld.
> > 
> > The Makefile building the library in question is kerberos5/lib/libasn1/M
> > akefile. My alterations are:
> > 
> > universe12b$ svn diff -cr323334  kerberos5/lib/libasn1/Makefile
>
> FWIW, a clean head checkout as of r332035 can build world just fine for
> mips.mips64elhf, that is with __MAKE_CONF and SRCCONF both set to
> /dev/null.  So it's likely due to your changes, I'll try those tomorrow.

Agreed. I might be onto it. Building to verify my hypothesis.



-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.