date:20170705

Re: 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)

2017-07-05 Thread Bryan Drewery

On 6/29/17 6:21 PM, Mark Millard wrote:
> [I found where the tools are listed that are copied,
> the list that is missing head.]
> 
> On 2017-Jun-29, at 3:33 PM, Mark Millard  wrote:
> 
>> [This is a clang targetting powerpc64 context from my
>> experimentation efforts, not the normal gcc 4.2.1 context
>> for powerpc64.]
>>
>> I break out the PATH into lines below to make it easier to scan.
>> See the later "sh: head: not found" line and the even later ls
>> of the directory with the x86-64 program directory in use: no
>> "head" is present to find.
>>
>> --- install32 ---
>> cd /usr/src/lib; MACHINE=powerpc MACHINE_ARCH=powerpc 
>> MAKEOBJDIRPREFIX=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/world32
>> PATH=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/usr/sbin
>> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/usr/bin
>> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/bin
>> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/usr/sbin
>> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/usr/bin
>> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/usr/sbin
>> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/usr/bin
>> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/bin
>> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/usr/sbin
>> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/usr/bin
>> :/tmp/install.7ljKosWa
>> SYSROOT=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32
>>  LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 DTRACE="dtrace" make 
>> LD="/usr/local/powerpc64-freebsd/bin/ld -m elf32ppc_fbsd" 
>> OBJCOPY="/usr/local/powerpc64-freebsd/bin/objcopy" 
>> NM="/usr/local/powerpc64-freebsd/bin/nm" -DCOMPAT_32BIT CC="cc -target 
>> powerpc64-unknown-freebsd12.0 
>> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp
>>  -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT -mcpu=powerpc -m32  
>> -L/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32
>>   
>> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32
>>   -B/usr/local/powerpc64-freebsd/bin/ 
>> -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32"
>>  CXX="c++  -target powerpc64-unknown-freebsd12.0 
>> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp
>>  -B/usr/local/powerpc64-freebsd/bin/  -DCOMPAT_32BIT -mcpu=powerpc -m32  -L/
>> usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32
>>   
>> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32
>>   -B/usr/local/powerpc64-freebsd/bin/ 
>> -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32"
>>  CPP="cpp -target powerpc64-unknown-freebsd12.0 
>> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp
>>  -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT -mcpu=powerpc -m32  
>> -L/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32
>>   
>> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32
>>   -B/usr/local/powerpc64-freebsd/bin/ 
>> -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32"
>>  -DNO_CPU_CFLAGS MK_CTF=no -DNO_LINT MK_TESTS=no 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: Unable to determine 
>> linker type from XLD=/usr/local/powerpc64-freebsd/bin/ld
>> *** [install32] Error code 1
>>
>> # ls -lT /tmp/install.7ljKosWa/
>> total 6151
>> -r-xr-xr-x1 root  wheel12592 Jun 29 14:02:46 2017 [
>> -r-xr-xr-x1 root  wheel   207320 Jun 29 14:02:46 2017 awk
>> -r-xr-xr-x1 root  wheel 8456 Jun 29 14:02:46 2017 cap_mkdb
>> -r-xr-xr-x1 root  wheel13272 Jun 29 14:02:46 2017 cat
>> . . .
>> -r-xr-xr-x1 root  wheel57632 Jun 29 14:02:46 2017 find
>> -r-xr-xr-x1 root  wheel99064 Jun 29 14:02:46 2017 grep
>> -r-xr-xr-x1 root  wheel13360 Jun 29 14:02:46 2017 id
>> . . .
>>
>> So there is no "head" to find. Below uses "find" instead
>> to confirm the x86-64 ELF status:
>>
>> # file /tmp/install.7ljKosWa/find
>> /tmp/install.7ljKosWa/find: ELF 64-bit LSB executable, x86-64, version 1 
>> (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 
>> 12.0 (1200036), FreeBSD-style, stripped
>>
>>
>>
>> From /usr/src/share/mk/bsd.linker.mk :
>>
>> .if ${ld} == "LD" || (${ld} == "XLD" && ${XLD} != ${LD})
>> .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION)
>> _ld_version!=   ${${ld}} --version 2>/dev/null | head -n 1 || echo none
>> .if ${_ld_version} == "none"
>> .er

Re: 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)

2017-07-05 Thread Mark Millard

On 2017-Jul-5, at 12:36 PM, Bryan Drewery  wrote:

> On 6/29/17 6:21 PM, Mark Millard wrote:
>> [I found where the tools are listed that are copied,
>> the list that is missing head.]
>> 
>> . . .
>> In /usr/src/Makefile.inc1 :
>> 
>> ITOOLS= [ awk cap_mkdb cat chflags chmod chown cmp cp \
>>date echo egrep find grep id install ${_install-info} \
>>ln make mkdir mtree mv pwd_mkdb \
>>rm sed services_mkdb sh strip sysctl test true uname wc ${_zoneinfo} \
>>${LOCAL_ITOOLS}
>> 
>> does not list "head" as a tool.
>> 
>> But I can externally add it via LOCAL_ITOOLS use.
>> 
> 
> This change should not be needed.  We don't want to be running 'ld'
> during installworld.  The changes I made around this time should already
> cover the problem.  Is it still occurring on a more recent
> buildworld+installworld, without the ITOOLS change?

ld was still in use last I checked. I've been using LOCAL_ITOOLS
to avoid the problem for powerpc64's world32 activity where the
problem was happening for me.

See Ed Maste's -r320502 check in which I expect is a alternate
workaround for the lack of "head" in that I get the same message
that is being avoided unless I cause "head" to be in the ITOOLS:


Author: emaste
Date: Fri Jun 30 16:34:17 2017
New Revision: 320502
URL: 
https://svnweb.freebsd.org/changeset/base/320502


Log:
  bsd.linker.mk: add band-aid for linker invocation failure
  
  In some cases bsd.linker.mk reports an error like:
  
make[4]: ".../share/mk/bsd.linker.mk" line 56:
Unknown linker from LD=ld -m elf32ppc_fbsd:"
  
  For now change this to a .warning, and then assume GNU ld 2.17.50.
  At present the linker type detection is used only for enabling build-id,
  and we can carry on without it when type detection fails.
  
  Also, show errors from ${LD} --version to aid in failure diagnosis.
  Successful invocations of ${LD} --version produce no output on stderr
  so this will not create any spam in non-failing builds.
  
  Tested by:swills
  Sponsored by: The FreeBSD Foundation
  Differential Revision:
https://reviews.freebsd.org/D11424


Modified:
  head/share/mk/bsd.linker.mk

Modified: head/share/mk/bsd.linker.mk
==
--- head/share/mk/bsd.linker.mk Fri Jun 30 16:16:21 2017(r320501)
+++ head/share/mk/bsd.linker.mk Fri Jun 30 16:34:17 2017(r320502)
@@ -47,9 +47,9 @@ ${var}=   ${${var}.${${X_}_ld_hash}}
 
 .if ${ld} == "LD" || (${ld} == "XLD" && ${XLD} != ${LD})
 .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION)
-_ld_version!=  ${${ld}} --version 2>/dev/null | head -n 1 || echo none
+_ld_version!=  (${${ld}} --version || echo none) | head -n 1
 .if ${_ld_version} == "none"
-.error Unable to determine linker type from ${ld}=${${ld}}
+.warning Unable to determine linker type from ${ld}=${${ld}}
 .endif
 .if ${_ld_version:[1..2]} == "GNU ld"
 ${X_}LINKER_TYPE=  bfd
@@ -58,7 +58,9 @@ _v=   ${_ld_version:M[1-9].[0-9]*:[1]}
 ${X_}LINKER_TYPE=  lld
 _v=${_ld_version:[2]}
 .else
-.error Unknown linker from ${ld}=${${ld}}: ${_ld_version}
+.warning Unknown linker from ${ld}=${${ld}}: ${_ld_version}, defaulting to bfd
+${X_}LINKER_TYPE=  bfd
+_v=2.17.50
 .endif
 ${X_}LINKER_VERSION!=  echo "${_v:M[1-9].[0-9]*}" | \
  awk -F. '{print $$1 * 1 + $$2 * 100 + $$3;}'



The actual error is from the piping through head
when head is missing, at least in my context.

===
Mark Millard
markmi at dsl-only.net


___
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: 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)

2017-07-05 Thread Bryan Drewery

On 7/5/17 1:35 PM, Mark Millard wrote:
> On 2017-Jul-5, at 12:36 PM, Bryan Drewery  wrote:
> 
>> On 6/29/17 6:21 PM, Mark Millard wrote:
>>> [I found where the tools are listed that are copied,
>>> the list that is missing head.]
>>>
>>> . . .
>>> In /usr/src/Makefile.inc1 :
>>>
>>> ITOOLS= [ awk cap_mkdb cat chflags chmod chown cmp cp \
>>>date echo egrep find grep id install ${_install-info} \
>>>ln make mkdir mtree mv pwd_mkdb \
>>>rm sed services_mkdb sh strip sysctl test true uname wc ${_zoneinfo} 
>>> \
>>>${LOCAL_ITOOLS}
>>>
>>> does not list "head" as a tool.
>>>
>>> But I can externally add it via LOCAL_ITOOLS use.
>>>
>>
>> This change should not be needed.  We don't want to be running 'ld'
>> during installworld.  The changes I made around this time should already
>> cover the problem.  Is it still occurring on a more recent
>> buildworld+installworld, without the ITOOLS change?
> 
> ld was still in use last I checked. I've been using LOCAL_ITOOLS
> to avoid the problem for powerpc64's world32 activity where the
> problem was happening for me.
> 
> See Ed Maste's -r320502 check in which I expect is a alternate
> workaround for the lack of "head" in that I get the same message
> that is being avoided unless I cause "head" to be in the ITOOLS:
> 
> 
> Author: emaste
> Date: Fri Jun 30 16:34:17 2017
> New Revision: 320502
> URL: 
> https://svnweb.freebsd.org/changeset/base/320502
> 
> 
> Log:
>   bsd.linker.mk: add band-aid for linker invocation failure
>   
>   In some cases bsd.linker.mk reports an error like:
>   
> make[4]: ".../share/mk/bsd.linker.mk" line 56:
> Unknown linker from LD=ld -m elf32ppc_fbsd:"
>   
>   For now change this to a .warning, and then assume GNU ld 2.17.50.
>   At present the linker type detection is used only for enabling build-id,
>   and we can carry on without it when type detection fails.
>   
>   Also, show errors from ${LD} --version to aid in failure diagnosis.
>   Successful invocations of ${LD} --version produce no output on stderr
>   so this will not create any spam in non-failing builds.
>   
>   Tested by:  swills
>   Sponsored by:   The FreeBSD Foundation
>   Differential Revision:  
> https://reviews.freebsd.org/D11424
> 
> 
> Modified:
>   head/share/mk/bsd.linker.mk
> 
> Modified: head/share/mk/bsd.linker.mk
> ==
> --- head/share/mk/bsd.linker.mk   Fri Jun 30 16:16:21 2017
> (r320501)
> +++ head/share/mk/bsd.linker.mk   Fri Jun 30 16:34:17 2017
> (r320502)
> @@ -47,9 +47,9 @@ ${var}= ${${var}.${${X_}_ld_hash}}
>  
>  .if ${ld} == "LD" || (${ld} == "XLD" && ${XLD} != ${LD})
>  .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION)
> -_ld_version!=${${ld}} --version 2>/dev/null | head -n 1 || echo none
> +_ld_version!=(${${ld}} --version || echo none) | head -n 1
>  .if ${_ld_version} == "none"
> -.error Unable to determine linker type from ${ld}=${${ld}}
> +.warning Unable to determine linker type from ${ld}=${${ld}}
>  .endif
>  .if ${_ld_version:[1..2]} == "GNU ld"
>  ${X_}LINKER_TYPE=bfd
> @@ -58,7 +58,9 @@ _v= ${_ld_version:M[1-9].[0-9]*:[1]}
>  ${X_}LINKER_TYPE=lld
>  _v=  ${_ld_version:[2]}
>  .else
> -.error Unknown linker from ${ld}=${${ld}}: ${_ld_version}
> +.warning Unknown linker from ${ld}=${${ld}}: ${_ld_version}, defaulting to 
> bfd
> +${X_}LINKER_TYPE=bfd
> +_v=  2.17.50
>  .endif
>  ${X_}LINKER_VERSION!=echo "${_v:M[1-9].[0-9]*}" | \
> awk -F. '{print $$1 * 1 + $$2 * 100 + $$3;}'
> 
> 
> 
> The actual error is from the piping through head
> when head is missing, at least in my context.

Right, neither that commit nor adding head to [LOCAL_]ITOOLS should be
needed.  I wasn't able to recreate any of the problems when I tried
last.  I will look again.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: 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)

2017-07-05 Thread Mark Millard

[I show the specifics for how I normally build
powerpc64 with world32/lib32 involved. Ed Maste's
submittal also mentions "elf32ppc_fbsd". The
issue's context may be powerpc64 specific.]

On 2017-Jul-5, at 1:54 PM, Bryan Drewery  wrote:

> On 7/5/17 1:35 PM, Mark Millard wrote:
>> On 2017-Jul-5, at 12:36 PM, Bryan Drewery  wrote:
>> 
>>> On 6/29/17 6:21 PM, Mark Millard wrote:
 [I found where the tools are listed that are copied,
 the list that is missing head.]
 
 . . .
 In /usr/src/Makefile.inc1 :
 
 ITOOLS= [ awk cap_mkdb cat chflags chmod chown cmp cp \
   date echo egrep find grep id install ${_install-info} \
   ln make mkdir mtree mv pwd_mkdb \
   rm sed services_mkdb sh strip sysctl test true uname wc ${_zoneinfo} 
 \
   ${LOCAL_ITOOLS}
 
 does not list "head" as a tool.
 
 But I can externally add it via LOCAL_ITOOLS use.
 
>>> 
>>> This change should not be needed.  We don't want to be running 'ld'
>>> during installworld.  The changes I made around this time should already
>>> cover the problem.  Is it still occurring on a more recent
>>> buildworld+installworld, without the ITOOLS change?
>> 
>> ld was still in use last I checked. I've been using LOCAL_ITOOLS
>> to avoid the problem for powerpc64's world32 activity where the
>> problem was happening for me.
>> 
>> See Ed Maste's -r320502 check in which I expect is a alternate
>> workaround for the lack of "head" in that I get the same message
>> that is being avoided unless I cause "head" to be in the ITOOLS:
>> 
>> 
>> Author: emaste
>> Date: Fri Jun 30 16:34:17 2017
>> New Revision: 320502
>> URL: 
>> https://svnweb.freebsd.org/changeset/base/320502
>> 
>> 
>> Log:
>>  bsd.linker.mk: add band-aid for linker invocation failure
>> 
>>  In some cases bsd.linker.mk reports an error like:
>> 
>>make[4]: ".../share/mk/bsd.linker.mk" line 56:
>>Unknown linker from LD=ld -m elf32ppc_fbsd:"
>> 
>>  For now change this to a .warning, and then assume GNU ld 2.17.50.
>>  At present the linker type detection is used only for enabling build-id,
>>  and we can carry on without it when type detection fails.
>> 
>>  Also, show errors from ${LD} --version to aid in failure diagnosis.
>>  Successful invocations of ${LD} --version produce no output on stderr
>>  so this will not create any spam in non-failing builds.
>> 
>>  Tested by:  swills
>>  Sponsored by:   The FreeBSD Foundation
>>  Differential Revision:  
>> https://reviews.freebsd.org/D11424
>> 
>> 
>> Modified:
>>  head/share/mk/bsd.linker.mk
>> 
>> Modified: head/share/mk/bsd.linker.mk
>> ==
>> --- head/share/mk/bsd.linker.mk  Fri Jun 30 16:16:21 2017
>> (r320501)
>> +++ head/share/mk/bsd.linker.mk  Fri Jun 30 16:34:17 2017
>> (r320502)
>> @@ -47,9 +47,9 @@ ${var}=${${var}.${${X_}_ld_hash}}
>> 
>> .if ${ld} == "LD" || (${ld} == "XLD" && ${XLD} != ${LD})
>> .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION)
>> -_ld_version!=   ${${ld}} --version 2>/dev/null | head -n 1 || echo none
>> +_ld_version!=   (${${ld}} --version || echo none) | head -n 1
>> .if ${_ld_version} == "none"
>> -.error Unable to determine linker type from ${ld}=${${ld}}
>> +.warning Unable to determine linker type from ${ld}=${${ld}}
>> .endif
>> .if ${_ld_version:[1..2]} == "GNU ld"
>> ${X_}LINKER_TYPE=bfd
>> @@ -58,7 +58,9 @@ _v=${_ld_version:M[1-9].[0-9]*:[1]}
>> ${X_}LINKER_TYPE=lld
>> _v=  ${_ld_version:[2]}
>> .else
>> -.error Unknown linker from ${ld}=${${ld}}: ${_ld_version}
>> +.warning Unknown linker from ${ld}=${${ld}}: ${_ld_version}, defaulting to 
>> bfd
>> +${X_}LINKER_TYPE=   bfd
>> +_v= 2.17.50
>> .endif
>> ${X_}LINKER_VERSION!=echo "${_v:M[1-9].[0-9]*}" | \
>>awk -F. '{print $$1 * 1 + $$2 * 100 + $$3;}'
>> 
>> 
>> 
>> The actual error is from the piping through head
>> when head is missing, at least in my context.
> 
> Right, neither that commit nor adding head to [LOCAL_]ITOOLS should be
> needed.  I wasn't able to recreate any of the problems when I tried
> last.  I will look again.

Note that Ed Maste's submittal mentions "elf32ppc_fbsd"
and the only context I've seen the issue is for
powerpc64 with world32/lib32 involved as well.

In my case this is with an external binutils because
the system binutils fail last I tried and the llvm
one do not work either. It is also the case that for
me the compiler is the system's clang in my normal use.

My normal powerpc64 build context in more detail, first
the script that in turn binds SRC_ENV_CONF and then the
bound file:

# more 
~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host.sh
 
kldload -n filemon && \
script 
~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host-$(date
 +%Y-%m-%d:%H:%M:%S) \
env __MAKE_CONF="/root/src.configs

Re: 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)

Re: 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)

Re: 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)

Re: 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)

4 matches

Site Navigation

Mail list logo

Footer information