11.0 -r297369: _el_fn_sh_complete missing in buildworld; /usr/obj/. . ./lib/libedit/ has no filecomplete.*

2016-03-29 Thread Mark Millard 
Going from 11.0-CURRENT -r297048 to -r297369: buildworld after svnlite update:
/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/. . . ends up with no 
filecomplete.*
but the build tries to use what would be some of its contents 
(_el_fn_sh_complete)

The details. . .

> --- all_subdir_bin ---
> --- sh.full ---
> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -isystem 
> /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include 
> --sysroot=/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp 
> -B/usr/local/powerpc
> 64-freebsd/bin/ -O2 -pipe -DSHELL -I. -I/usr/src/bin/sh -g -std=gnu99 
> -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k 
> -Wno-uninitialized -Wno-pointer-sign -Wno-error=unused-function -W
> no-error=enum-compare -Wno-error=logical-not-parentheses 
> -Wno-error=bool-compare -Wno-error=uninitialized -Wno-error=array-bounds 
> -Wno-error=clobbered -Wno-error=cast-align -Wno-error=extra -Wno-error
> =attributes -Wno-error=inline -Wno-error=unused-but-set-variable 
> -Wno-error=unused-value -Wno-error=strict-aliasing -Wno-error=address  -o 
> sh.full alias.o arith_yacc.o arith_yylex.o cd.o echo.o error.
> o eval.o exec.o expand.o histedit.o input.o jobs.o kill.o mail.o main.o 
> memalloc.o miscbltin.o mystring.o options.o output.o parser.o printf.o 
> redir.o show.o test.o trap.o var.o builtins.o nodes.o syn
> tax.o   -ledit
> . . .
> --- all_subdir_bin ---
> histedit.o:(.toc+0x10): undefined reference to `_el_fn_sh_complete'
> collect2: error: ld returned 1 exit status
> *** [sh.full] Error code 1
> 
> bmake[4]: stopped in /usr/src/bin/sh
> 1 error
> 
> bmake[4]: stopped in /usr/src/bin/sh


> # find /usr/src -name .svn -prune -o -exec grep el_fn_sh_complete {} ; -print 
> | more
> unsigned char   _el_fn_sh_complete(EditLine *, int);
> /usr/src/lib/libedit/histedit.h
> _el_fn_sh_complete(EditLine *el, int ch __attribute__((__unused__)))
> /usr/src/lib/libedit/filecomplete.c
> _el_fn_sh_complete);
> /usr/src/bin/sh/histedit.c


> # find /usr/src -name .svn -prune -o -exec grep filecomplete {} \; -print | 
> more
> Binary file /usr/src/lib/libedit matches
> /usr/src/lib/libedit
> #include "filecomplete.h"
> /usr/src/lib/libedit/readline.c
> /*  $NetBSD: filecomplete.h,v 1.9 2009/12/30 22:37:40 christos Exp $  
>   */
>  * $FreeBSD: head/lib/libedit/filecomplete.h 276881 2015-01-09 07:40:56Z bapt 
> $
> /usr/src/lib/libedit/filecomplete.h
> OSRCS=  chared.c common.c el.c emacs.c fcns.c filecomplete.c help.c \
> /usr/src/lib/libedit/Makefile
> /*  $NetBSD: filecomplete.c,v 1.34 2014/10/18 15:07:02 riz Exp $*/
> __RCSID("$NetBSD: filecomplete.c,v 1.34 2014/10/18 15:07:02 riz Exp $");
> __FBSDID("$FreeBSD: head/lib/libedit/filecomplete.c 296435 2016-03-06 
> 21:32:54Z pfg $");
> #include "filecomplete.h"
> /usr/src/lib/libedit/filecomplete.c


> # find /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/ -name .svn -prune -o 
> -name "filecomplete*" -print | more
> # 


Supporting details. . .

build command (self hosted on a powerpc64 PowerMac):

> env __MAKE_CONF=/root/src.configs/make.conf 
> SRC_ENV_CONF=/root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host 
> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain/powerpc.powerpc64 make -j 5 buildworld 
> buildkernel


make.conf is empty.

src.conf:

> TO_TYPE=powerpc64
> TOOLS_TO_TYPE=${TO_TYPE}
> FROM_TYPE=powerpc64
> TOOLS_FROM_TYPE=${FROM_TYPE}
> VERSION_CONTEXT=11.0
> #
> KERNCONF=GENERIC64vtsc-NODEBUG
> TARGET=powerpc
> .if ${.MAKE.LEVEL} == 0
> TARGET_ARCH=${TO_TYPE}
> .export TARGET_ARCH
> .endif
> #
> WITHOUT_CROSS_COMPILER=
> #
> WITH_FAST_DEPEND=
> WITH_LIBCPLUSPLUS=
> WITH_BOOT=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_LLDB=
> #
> # LIB32 builds but does not work via gcc variants
> WITHOUT_LIB32=
> WITHOUT_GCC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> MALLOC_PRODUCTION=
> WITH_DEBUG_FILES=
> #
> #
> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related bintutils...
> #
> CROSS_TOOLCHAIN=${TO_TYPE}-gcc
> X_COMPILER_TYPE=gcc
> CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
> .if ${.MAKE.LEVEL} == 0
> XCC=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gcc
> XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g++
> XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-cpp
> .export XCC
> .export XCXX
> .export XCPP
> XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
> XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
> XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
> XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
> XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
> XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
> XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
> XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
> #NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
> XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
> .export XAS
> .export XAR
> .export

Re: warning: DWARF2 only supports one section per compilation unit

2016-03-29 Thread Konstantin Belousov 
On Tue, Mar 29, 2016 at 07:49:14PM +0200, Dimitry Andric wrote:
> These are harmless, and have been showing up for at least a year now.
> Clang is just notifying you that due to DWARF2 limitations, it will not
> emit debug info for more than one code section.
> 
> All such warnings in our tree are about artificially added sections,
> such as .note.GNU-stack, .reloc and __xen_guest, and it is not likely
> that anybody cares that those sections will not have debug info.
> 
> Lastly, I never found an option to shut up the warnings.  Well, apart
> from using -gdwarf-4. :-)

.note.GNU-stack should not have any content at all.  Issuing the warning
for empty section is pointless, and it would hide in the noise a real
bug if anything migrates under the section.
___
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: warning: DWARF2 only supports one section per compilation unit

2016-03-29 Thread Dimitry Andric 
On 29 Mar 2016, at 16:45, Andriy Gapon  wrote:
> 
> I've noticed many messages like the following during amd64 buildworld with 
> very
> recent head:
> 
>> warning: DWARF2 only supports one section per compilation unit
>> .section .note.GNU-stack,"",%progbits
> 
> Reported sections varied (e.g. there was .rodata).
> The messages seem to be related to .s files.
> I hope that those are harmless?

These are harmless, and have been showing up for at least a year now.
Clang is just notifying you that due to DWARF2 limitations, it will not
emit debug info for more than one code section.

All such warnings in our tree are about artificially added sections,
such as .note.GNU-stack, .reloc and __xen_guest, and it is not likely
that anybody cares that those sections will not have debug info.

Lastly, I never found an option to shut up the warnings.  Well, apart
from using -gdwarf-4. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail