Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

[John Baldwin]

On 10/15/18 11:55 AM, Warner Losh wrote:
> 
> 
> On Mon, Oct 15, 2018 at 12:25 PM John Baldwin  > wrote:
> 
> On 10/15/18 11:06 AM, Warner Losh wrote:
> >
> >
> > On Mon, Oct 15, 2018, 10:20 AM John Baldwin    >> wrote:
> >
> >     On 10/12/18 6:51 AM, Mark Millard wrote:
> >     > The following is from attempting to build devel/powerpc-gcc
> >     > via poudriere-devel on the powerpc64 system after having
> >     > bootstrapped via (in part) base/binutils and the .txz
> >     > produced on the host (amd64).
> >     >
> >     > Looks like having both:
> >     >
> >     > /usr/bin/powerpc64-unknown-freebsd12.0-*
> >     > and:
> >     > /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> >     >
> >     > in a powerpc64 environment confuses "phase: build-depends"
> >     > in poudriere for the devel/powerpc64-gcc build:
> >
> >     Ah, I could see that.  I had kept the longer binary names with the 
> full tuple
> >     since the original base/binutils had them, but I've considered 
> stripping them
> >     as we only really need /usr/bin/as, etc. for the base system.  I 
> hadn't gotten
> >     to the point of trying to build any ports with base/* as I'm still 
> trying to
> >     just do a buildworld (and running poudriere in a qemu image of 
> mips64 would
> >     be very unpleasant).  I think probably base/binutils just needs to 
> drop the
> >     names with a full tuple if possible.
> >
> >
> > Having symlinks to the long names plays nicer with autoconf, of at 
> least has in the past. Our build system doesn't care, though...
> 
> I think it only plays nicer for the port.  We've never had 
> /usr/bin/x86_64-freebsd-ld
> linked to /usr/bin/ld in base, and base/binutils' role is to provide 
> /usr/bin/as,
> /usr/bin/ld, etc.
> 
> 
> The tools built by xdev did, though not that specific link... I do agree that 
> if we do this, it's only of marginal benefit.

The xdev tools are probably more inline with the devel/-binutils and
devel/-gcc ports which do install those links to be cross-build friendly.

-- 
John Baldwin


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

[Warner Losh]

On Mon, Oct 15, 2018 at 12:25 PM John Baldwin  wrote:

> On 10/15/18 11:06 AM, Warner Losh wrote:
> >
> >
> > On Mon, Oct 15, 2018, 10:20 AM John Baldwin  j...@freebsd.org>> wrote:
> >
> > On 10/12/18 6:51 AM, Mark Millard wrote:
> > > The following is from attempting to build devel/powerpc-gcc
> > > via poudriere-devel on the powerpc64 system after having
> > > bootstrapped via (in part) base/binutils and the .txz
> > > produced on the host (amd64).
> > >
> > > Looks like having both:
> > >
> > > /usr/bin/powerpc64-unknown-freebsd12.0-*
> > > and:
> > > /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> > >
> > > in a powerpc64 environment confuses "phase: build-depends"
> > > in poudriere for the devel/powerpc64-gcc build:
> >
> > Ah, I could see that.  I had kept the longer binary names with the
> full tuple
> > since the original base/binutils had them, but I've considered
> stripping them
> > as we only really need /usr/bin/as, etc. for the base system.  I
> hadn't gotten
> > to the point of trying to build any ports with base/* as I'm still
> trying to
> > just do a buildworld (and running poudriere in a qemu image of
> mips64 would
> > be very unpleasant).  I think probably base/binutils just needs to
> drop the
> > names with a full tuple if possible.
> >
> >
> > Having symlinks to the long names plays nicer with autoconf, of at least
> has in the past. Our build system doesn't care, though...
>
> I think it only plays nicer for the port.  We've never had
> /usr/bin/x86_64-freebsd-ld
> linked to /usr/bin/ld in base, and base/binutils' role is to provide
> /usr/bin/as,
> /usr/bin/ld, etc.
>

The tools built by xdev did, though not that specific link... I do agree
that if we do this, it's only of marginal benefit.

Warner
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

[John Baldwin]

On 10/15/18 11:06 AM, Warner Losh wrote:
> 
> 
> On Mon, Oct 15, 2018, 10:20 AM John Baldwin  > wrote:
> 
> On 10/12/18 6:51 AM, Mark Millard wrote:
> > The following is from attempting to build devel/powerpc-gcc
> > via poudriere-devel on the powerpc64 system after having
> > bootstrapped via (in part) base/binutils and the .txz
> > produced on the host (amd64).
> >
> > Looks like having both:
> >
> > /usr/bin/powerpc64-unknown-freebsd12.0-*
> > and:
> > /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> >
> > in a powerpc64 environment confuses "phase: build-depends"
> > in poudriere for the devel/powerpc64-gcc build:
> 
> Ah, I could see that.  I had kept the longer binary names with the full 
> tuple
> since the original base/binutils had them, but I've considered stripping 
> them
> as we only really need /usr/bin/as, etc. for the base system.  I hadn't 
> gotten
> to the point of trying to build any ports with base/* as I'm still trying 
> to
> just do a buildworld (and running poudriere in a qemu image of mips64 
> would
> be very unpleasant).  I think probably base/binutils just needs to drop 
> the
> names with a full tuple if possible.
> 
> 
> Having symlinks to the long names plays nicer with autoconf, of at least has 
> in the past. Our build system doesn't care, though...

I think it only plays nicer for the port.  We've never had 
/usr/bin/x86_64-freebsd-ld
linked to /usr/bin/ld in base, and base/binutils' role is to provide 
/usr/bin/as,
/usr/bin/ld, etc.

-- 
John Baldwin


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

[Warner Losh]

On Mon, Oct 15, 2018, 10:20 AM John Baldwin  wrote:

> On 10/12/18 6:51 AM, Mark Millard wrote:
> > The following is from attempting to build devel/powerpc-gcc
> > via poudriere-devel on the powerpc64 system after having
> > bootstrapped via (in part) base/binutils and the .txz
> > produced on the host (amd64).
> >
> > Looks like having both:
> >
> > /usr/bin/powerpc64-unknown-freebsd12.0-*
> > and:
> > /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> >
> > in a powerpc64 environment confuses "phase: build-depends"
> > in poudriere for the devel/powerpc64-gcc build:
>
> Ah, I could see that.  I had kept the longer binary names with the full
> tuple
> since the original base/binutils had them, but I've considered stripping
> them
> as we only really need /usr/bin/as, etc. for the base system.  I hadn't
> gotten
> to the point of trying to build any ports with base/* as I'm still trying
> to
> just do a buildworld (and running poudriere in a qemu image of mips64 would
> be very unpleasant).  I think probably base/binutils just needs to drop the
> names with a full tuple if possible.
>

Having symlinks to the long names plays nicer with autoconf, of at least
has in the past. Our build system doesn't care, though...

Warner

-- 
> John Baldwin
>
>
>
> ___
> freebsd-toolchain@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "
> freebsd-toolchain-unsubscr...@freebsd.org"
>
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

[John Baldwin]

On 10/12/18 6:51 AM, Mark Millard wrote:
> The following is from attempting to build devel/powerpc-gcc
> via poudriere-devel on the powerpc64 system after having
> bootstrapped via (in part) base/binutils and the .txz
> produced on the host (amd64).
> 
> Looks like having both:
> 
> /usr/bin/powerpc64-unknown-freebsd12.0-*
> and:
> /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> 
> in a powerpc64 environment confuses "phase: build-depends"
> in poudriere for the devel/powerpc64-gcc build:

Ah, I could see that.  I had kept the longer binary names with the full tuple
since the original base/binutils had them, but I've considered stripping them
as we only really need /usr/bin/as, etc. for the base system.  I hadn't gotten
to the point of trying to build any ports with base/* as I'm still trying to
just do a buildworld (and running poudriere in a qemu image of mips64 would
be very unpleasant).  I think probably base/binutils just needs to drop the
names with a full tuple if possible.

-- 
John Baldwin


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

[Mark Millard via freebsd-toolchain]

The following is from attempting to build devel/powerpc-gcc
via poudriere-devel on the powerpc64 system after having
bootstrapped via (in part) base/binutils and the .txz
produced on the host (amd64).

Looks like having both:

/usr/bin/powerpc64-unknown-freebsd12.0-*
and:
/usr/local/bin/powerpc64-unknown-freebsd12.0-*

in a powerpc64 environment confuses "phase: build-depends"
in poudriere for the devel/powerpc64-gcc build:

===
===>   powerpc64-gcc-6.4.0_2 depends on executable: 
powerpc64-unknown-freebsd12.0-as - found

I.e., poudriere finds /usr/bin/powerpc64-unknown-freebsd12.0-as
and concludes that devel/powerpc64-binutils does not need to be
installed for the devel/powerpc64-gcc to build.

Eventually this leads to aborting based on gcc's config noticing
an oddity:

. . .
checking for ld used by GCC... /usr/bin/powerpc64-unknown-freebsd12.0-ld
checking if the linker (/usr/bin/powerpc64-unknown-freebsd12.0-ld) is GNU ld... 
yes
configure: error: cannot execute: 
/usr/local/bin/powerpc64-unknown-freebsd12.0-ld: check --with-ld or env. var. 
DEFAULT_LINKER


This is associated with:

CONFIGURE_ARGS+=--target=${GCC_TARGET} --disable-nls --enable-languages=c,c++ \
--enable-gnu-indirect-function \
--without-headers \
--with-gmp=${LOCALBASE} \
--with-pkgversion="FreeBSD Ports Collection for 
${PKGNAMEPREFIX:C/-//g}" \
--with-system-zlib \
--with-gxx-include-dir=/usr/include/c++/v1/ \
--with-sysroot="/" \
--with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \
--with-ld=${LOCALBASE}/bin/${BU_PREFIX}-ld

having the --with-ld not list the */bin/${BU_PREFIX}-ld it actually
finds and tests in config ( /usr used instead of ${LOCALBASE} ).


If any other port binds to devel/powerpc64-binutils it probably
has the same sort of issue. (Unlikely?)

This is not likely to be specific to powerpc64 as a base/binutils
target: powerpc64 is likely just an example.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"