Re: Still true at -r333575 : head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing)

Bryan Drewery <[email protected]>
Newsgroups gmane.os.freebsd.devel.toolchain,gmane.os.freebsd.devel.ppc
Organization FreeBSD
Message-ID <[email protected]>
On 5/19/2018 6:04 PM, Mark Millard wrote:
> On 2018-May-14, at 5:04 PM, Bryan Drewery <bdrewery at FreeBSD.org> wrote:
> 
>> On 5/13/2018 1:13 AM, Mark Millard wrote:
>>> Retrying the amd64 -> powerpc64 cross build via a powerpc64-gcc
>>> this time, combined with WITH_LIB32= , got: "sh: head: not found" and its
>>> later consequences, like before for installworld (to a directory on the
>>> amd64 host context). This is from the /usr/src/share/mk/bsd.linker.mk line
>>> that results in:
>>>
>>> (/usr/local/powerpc64-freebsd/bin/ld --version || echo none) | head -n 1
>>>
>>> but head is not available by default at the time (lib32 context). (I make
>>> head be available via using LOCAL_ITOOLS=head in order to work around the
>>> issue.)
>>>
>>> An example of the messages (without having LOCAL_ITOOLS=head) is:
>>>
>>> --- _installlinks ---
>>> install -l s  ../../libexec/ld-elf32.so.1 /usr/obj/DESTDIRs/xtcgcc-powerpc64-installworld/usr/libexec/ld-elf32.so.1
>>> cd /usr/src/usr.bin/ldd; PROG=ldd32 . . .
>>> . . .
>>> . . . MAKEOBJDIRPREFIX= MK_MAN=no MK_HTML=no  MK_TOOLCHAIN=no   -DLIBRARIES_ONLY  install
>>> sh: head: not found
>>> make[4]: "/usr/src/share/mk/bsd.linker.mk" line 47: warning: "(/usr/local/powerpc64-unknown-freebsd12.0/bin/ld --version || echo none) | head -n 1" returned non-zero status
>>> make[4]: "/usr/src/share/mk/bsd.linker.mk" line 58: warning: Unknown linker from XLD=/usr/local/powerpc64-unknown-freebsd12.0/bin/ld: , defaulting to bfd
>>>
>>>
>>> The two "make[4]" lines are consequences of the prior "sh: head: not found"
>>> issue that leaded to a "non-zero status" independent of the prior "--version"
>>> and "echo none" material. It then leads to assuming bfd.
>>>
>>> Using LOCAL_ITOOLS=head makes head available and so then the status value
>>> check works.
>>>
>>
>> Sure but this command being executed never should be executing during
>> install; Adding 'head' as a tool isn't the right fix.
>>
>> I have never been able to recreate the problem here. I have an idea I'll
>> test.
>>
> 
> May be the following will help. It shows a clear difference
> between the ${XLD} and ${LD} text that is used in:
> 
> .if ${ld} == "LD" || (${ld} == "XLD" && ${XLD} != ${LD})
> 
> when ${LD} == "XLD" in my context.
> 
> My src config that is involved has (extracted):
> 
> TO_TYPE=powerpc64
> VERSION_CONTEXT=12.0
> CROSS_TOOLCHAIN=${TO_TYPE}-gcc
> X_COMPILER_TYPE=gcc
> CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/
> .if ${.MAKE.LEVEL} == 0
> XLD=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/ld
> .export XLD
> .endif
> 
> and is used via:
> 
> SRCCONF="/dev/null" SRC_ENV_CONF="/root/src.configs/src.conf.powerpc64-xtoolchain-gcc.amd64-host"
> 
> Given that, by adding a:
> 
> .warning "ld=${ld} XLD=${XLD} LD=${LD} LINKER_TYPE=${${X_}LINKER_TYPE} LINKER_VERSION=${${X_}LINKER_VERSION}"
> 
> line just before before the /usr/src/share/mk/bsd.linker.mk line:
> 
> _ld_version!=   (${${ld}} --version || echo none) | head -n 1
> 
> that is being (incorrectly) executed and not finding head the
> extra .warning reported:
> 
> make[4]: "/usr/src/share/mk/bsd.linker.mk" line 47: warning: "ld=XLD XLD=/usr/local/powerpc64-unknown-freebsd12.0/bin/ld LD=/usr/local/powerpc64-unknown-freebsd12.0/bin/ld -m elf32ppc_fbsd LINKER_TYPE= LINKER_VERSION="
> 
> Note that the LD= part has the text:
> 
> -m elf32ppc_fbsd
> 
> in it where my explicit XLD assignment does not.
> 
> 
> Is my src config handling of XLD non-supported in some way?
> Did I step outside the intended coverage?

I mitigated the issue in r334791 to stop using 'head'.
But I did just theorize what the problem is while working on
WITH_SYSTEM_LINKER. Reading this mail does confirm my suspicion. What
you are doing is perfectly fine, I just lacked handling it properly like
done in r301287 and r301394 to pass along X_LINKER_* values for when XLD
is used. I'm working on a fix.

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


-- 
Regards,
Bryan Drewery
signature.asc (application/pgp-signature, 473 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJbI+jCAAoJEDXXcbtuRpfPUuwIANZgh0LCmotDoGz4rMei5qCd
jvFDBruMS471bfSBkcuMwa9ZRVX+CFPSSnuX5mK6P5pTpwTj5OTKRA8yk5J6l4lI
7tGiuINpbV+ZguqKI+2vNJ3x4JThS7OfxsFP/grH3LT7XW0hEEW6zRR3xAlcVKxQ
sVgyQlTBXYl5NqxUjWkVMzBn2i0BsVt3wRlfSlZGexrstk+04Ae7JOQInpHpcaf9
yLakF5VNNhJfIKY3gIfizHQqOWi/HmQnAlB9Lh7VVSIK/pgzrpMrJ00ct+QoCGdH
406L3+hyDnvkXcKvDs8L5tbnGIZRWt08dHJQ3CJ27jwYh2V1r9SAUsbkbSyr5XI=
=cdso
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.