Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-05-29 Thread Adrian Chadd 
On 28 May 2016 at 14:30, Mark Millard  wrote:
> On 2016-May-28, at 12:03 PM, Adrian Chadd  wrote:
>
>> [snip]
>>
>> hi,
>>
>> please don't patch the ports compiler assumptions about things like
>> this. We should be targeting external toolchains on OSes (eg macosx)
>> where it may already generate freebsd binaries and as such we should
>> be calling the compiler/linker with all the flags it needs.
>>
>> Having a patched compiler default for mips made things way, way harder
>> than it needed to be.
>>
>>
>>
>> -adrian
>
> Are there specific technical examples of specific lessons learned from the 
> "patched compiler default for mips" context?
>
> Is there an intent to use /usr/src/. . . materials for buildworld/buildkernel 
> and the like from a non-FreeBSD context? Are there examples?

Well, I'd like to be able to build it from non-freebsd environment.
Eg, eventually from the macosx shipped clang/llvm, or various other
external toolchains. Doubly so for whatever commercial / internal /
bring-up compilers that are used during platform bringup.

The hurt is that our Makefile stuff is still a bit messy. On the plus
side, Brian, Warner in particular have done a great job undoing all of
that and making things cleaner, so big props to them!


-adrian
___
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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-05-28 Thread Bryan Drewery 
On 5/28/2016 12:03 PM, Adrian Chadd wrote:
> [snip]

I beg of you to *stop* snipping all context.

> 
> hi,
> 
> please don't patch the ports compiler assumptions about things like

I said it was not right, and was an experiment.

> this. We should be targeting external toolchains on OSes (eg macosx)
> where it may already generate freebsd binaries and as such we should
> be calling the compiler/linker with all the flags it needs.
> 
> Having a patched compiler default for mips made things way, way harder
> than it needed to be.
> 
> 




-- 
Regards,
Bryan Drewery
bdrewery@freenode/EFNet
___
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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-05-28 Thread Mark Millard 
On 2016-May-28, at 12:03 PM, Adrian Chadd  wrote:

> [snip]
> 
> hi,
> 
> please don't patch the ports compiler assumptions about things like
> this. We should be targeting external toolchains on OSes (eg macosx)
> where it may already generate freebsd binaries and as such we should
> be calling the compiler/linker with all the flags it needs.
> 
> Having a patched compiler default for mips made things way, way harder
> than it needed to be.
> 
> 
> 
> -adrian

Are there specific technical examples of specific lessons learned from the 
"patched compiler default for mips" context?

Is there an intent to use /usr/src/. . . materials for buildworld/buildkernel 
and the like from a non-FreeBSD context? Are there examples?

Currently I'm just providing evidence that some FreeBSD committers have 
requested. I'm not a committer for FreeBSD or for upstream and will not be 
making any FreeBSD system or ports changes outside my personal context. I'm no 
direct risk to FreeBSD. So your note is more for the folks having me cross 
check xtoolchain and related behavior than for me.


Notes on my context. . . (stop reading if you do not care)

Unfortunately powerpc64 and powerpc still can not be clang based overall for 
buildworld/buildkernel.

I will say that in my use of devel/powerpc64-xtoolchain-gcc (and so 
devel/powerpc64-gcc ) to have a libc++ based FreeBSD on powerpc64 I've always 
had to have some form of work around to avoid /usr/local/include causing 
buildworld failures from use of the wrong files for buildworld purposes. I have 
either:

A) temporarily renamed files below /usr/local/include/ to avoid them being used 
(or otherwise blocked /usr/local/include access)

or

B) used C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to cause the C/C++ compiles to 
look below /usr/include/ before looking below /usr/local/include/ . (I've also 
experimented with extra -I's and the like.)

So far I've not used devel/powerpc64-gcc to build ports under FreeBSD. So far 
I've only built ports from a self-hosted context (no cross-built ports). So I 
tend to use something like lang/gcc49 to build ports. I'm not likely to adopt a 
technique for building the likes of lang/gcc49 that messes up using it to build 
ports.

I normally self-host buildworld/buildkernel on a powerpc64 FreeBSD context, an 
odd use of devel/powerpc64-gcc . But I have at times also cross-built from an 
amd64 FreeBSD context and it also can have the "wrong files for buildworld" 
problem for /usr/local/include/ in FreeBSD.

I've never tried buildworld/buildkernel from a non-FreeBSD context and so have 
never built devel/powerpc64-gcc or anything like its configuration outside 
FreeBSD.

===
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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-05-28 Thread Adrian Chadd 
[snip]

hi,

please don't patch the ports compiler assumptions about things like
this. We should be targeting external toolchains on OSes (eg macosx)
where it may already generate freebsd binaries and as such we should
be calling the compiler/linker with all the flags it needs.

Having a patched compiler default for mips made things way, way harder
than it needed to be.



-adrian
___
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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-05-28 Thread Mark Millard 
[Top post of failure to get rid of /usr/local/include from devel/powerpc64-gcc 
search list.]

I have tried:

> # svnlite diff /usr/ports/devel/powerpc64-gcc/
> Index: /usr/ports/devel/powerpc64-gcc/Makefile
> ===
> --- /usr/ports/devel/powerpc64-gcc/Makefile   (revision 415874)
> +++ /usr/ports/devel/powerpc64-gcc/Makefile   (working copy)
> @@ -43,6 +43,7 @@
>  CONFIGURE_ARGS+=--target=${GCC_TARGET} --disable-nls 
> --enable-languages=c,c++ \
>   --without-headers \
>   --with-gmp=${LOCALBASE} \
> + 
> --with-local-prefix=${LOCALBASE}/lib/gcc/${GCC_TARGET}/${PORTVERSION} \
>   --with-pkgversion="FreeBSD Ports Collection for 
> ${PKGNAMEPREFIX:C/-//g}" \
>   --with-system-zlib \
>   --with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \

which when rebuilt in a powerpc64 context shows up with:

--with-local-prefix=/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0

in the "Configured with" (from using -v):

> Target: powerpc64-portbld-freebsd11.0
> Configured with: 
> /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.3.0/configure 
> --target=powerpc64-portbld-freebsd11.0 --disable-nls --enable-languages=c,c++ 
> --without-headers --with-gmp=/usr/local 
> --with-local-prefix=/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0 
> --with-pkgversion='FreeBSD Ports Collection for powerpc64' --with-system-zlib 
> --with-as=/usr/local/bin/powerpc64-freebsd-as 
> --with-ld=/usr/local/bin/powerpc64-freebsd-ld --prefix=/usr/local 
> --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/ 
> --build=powerpc64-portbld-freebsd11.0

But /usr/local/include still shows up in the search list, for example:

> ignoring nonexistent directory 
> "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include"
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerpc64-portbld-freebsd11.0/include"
> ignoring duplicate directory 
> "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/src/lib/msun/powerpc
>  /usr/src/lib/msun/src
>  /usr/src/lib/libc/include
>  /usr/src/lib/libc/powerpc
>  /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include
>  /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include
>  /usr/local/include
>  /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed
> End of search list.

[Despite some prior mis-wording in other messages: The line match for 
--with-local-prefix= 's value with "/include" appended matches the line prior 
to /usr/local/include in the search list, not the following line.]

So far I'm unsuccessful at avoiding /usr/local/include being in the search 
list. I'm still at the stage of C_INCLUDE_PAPTH and CPLUS_INCLUDE_PATH being 
the best means that I've found to force /usr/include based paths to win when 
there are conflicts in /usr/local/include from ports that have been built.


So far I'm only doing the experiment with devel/powerpc64-gcc (used as the 
so-called "cross compiler" in my powerpc64 self-hosted context), not with the 
lang/gcc49 that I use as the system compiler. For lang/gcc49 I'm still using 
C_INCLUDE_PAPTH and CPLUS_INCLUDE_PATH to avoid /usr/local/include based paths 
from finding files. In part this is because I expect port building problems if 
I use lang/gcc49 to build ports without lang/gcc49 having /usr/local/include 
implicitly. I do not use devel/powerpc64-gcc to build ports.

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

On 2016-May-28, at 2:24 AM, Mark Millard  wrote:

> --with-local-prefix=/usr was insufficient to avoid /usr/local/include in the 
> search list in powerpc64-gcc:
> 
>> ignoring duplicate directory 
>> "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include"
>> ignoring nonexistent directory 
>> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerpc64-portbld-freebsd11.0/include"
>> ignoring duplicate directory 
>> "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>> /usr/src/gnu/lib/libssp/libssp_nonshared/..
>> /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp
>> /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include
>> /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include
>> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include
>> /usr/local/include
>> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed
>> End of search list.
> 
> Which came from (which shows the --with-local-prefix=/usr use):
> 
>> Configured with: 
>> /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.3.0/configure 
>>

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-05-27 Thread Mark Millard 
On 2016-May-27, at 7:04 PM, Mark Millard  wrote:

> FYI. . .
> 
> I expect that building gcc49 with:
> 
> + --with-local-prefix=/usr \
> 
> will help with system build activities via gcc49/g++49 by avoiding 
> /usr/local/include interfering.
> 
> But I also expect that various port builds based on that same gcc49/g++49 
> will have problems from not explicitly forcing /usr/local/include to be 
> looked at when appropriate/required --unless something else is in place to do 
> that separately. I expect some implicit /usr/local/include references to the 
> likes of some of the below list:
> 
>> # diff -qr /usr/include/ /usr/local/include/ | grep /local/ | more
>> Only in /usr/local/include/: apr-1
>> Files /usr/include/atf-c/defs.h and /usr/local/include/atf-c/defs.h differ
>> Only in /usr/local/include/: autosprintf.h
>> Only in /usr/local/include/: bfd.h
>> Only in /usr/local/include/: bfdlink.h
>> Only in /usr/local/include/: boost
>> Only in /usr/local/include/: curl
>> Only in /usr/local/include/: db5
>> Only in /usr/local/include/: dis-asm.h
>> Files /usr/include/dwarf.h and /usr/local/include/dwarf.h differ
>> Only in /usr/local/include/: editline
>> Only in /usr/local/include/: expat.h
>> Only in /usr/local/include/: expat_config.h
>> Only in /usr/local/include/: expat_external.h
>> Only in /usr/local/include/: ffi.h
>> Only in /usr/local/include/: ffitarget.h
>> Only in /usr/local/include/: gdbm.h
>> Only in /usr/local/include/: gettext-po.h
>> Only in /usr/local/include/: gmp.h
>> Only in /usr/local/include/: gmpxx.h
>> Only in /usr/local/include/: gnumake.h
>> Files /usr/include/histedit.h and /usr/local/include/histedit.h differ
>> Only in /usr/local/include/: idn-free.h
>> Only in /usr/local/include/: idn-int.h
>> Only in /usr/local/include/: idna.h
>> Only in /usr/local/include/: layout
>> Files /usr/include/libdwarf.h and /usr/local/include/libdwarf.h differ
>> Only in /usr/local/include/: libintl.h
>> Only in /usr/local/include/: lua52
>> Only in /usr/local/include/: lutok
>> Only in /usr/local/include/: mpc.h
>> Only in /usr/local/include/: mpf2mpfr.h
>> Only in /usr/local/include/: mpfr.h
>> Only in /usr/local/include/: pkg.h
>> Only in /usr/local/include/: plugin-api.h
>> Only in /usr/local/include/: pr29.h
>> Only in /usr/local/include/: punycode.h
>> Only in /usr/local/include/: python2.7
>> Only in /usr/local/include/: readline
>> Only in /usr/local/include/: ruby-2.2
>> Only in /usr/local/include/: serf-1
>> Only in /usr/local/include/: sqlite3.h
>> Only in /usr/local/include/: sqlite3ext.h
>> Only in /usr/local/include/: stringprep.h
>> Only in /usr/local/include/: subversion-1
>> Only in /usr/local/include/: sudo_plugin.h
>> Only in /usr/local/include/: symcat.h
>> Only in /usr/local/include/: tld.h
>> Only in /usr/local/include/: unicode
>> Only in /usr/local/include/: yaml.h
> 
> It might be that even gcc compilers built by the adjusted gcc49 would not 
> find, say, gmp.h or mpfr.h .
> 
> dwarfdump's build/install installs /usr/local/include/dwarf.h and 
> /usr/local/include/libdwarf.h to match its code. Such examples can need 
> careful control over which file is used (here dwarf.h and libdwarf.h in 
> /usr/include vs. /usr/local/include ).
> 
> (It will still be some time before I get to switch to this with-local-prefix 
> experiment.)
> 
> ===
> Mark Millard
> markmi at dsl-only.net

Given the above I may try using

+   --with-local-prefix=/usr \

only for building devel/powerpc64-gcc initially because I do not use 
devel/powerpc64-gcc to build ports, just for system-build activities. 
devel/powerpc64-gcc has the /usr/local/include problem for system build 
activities too.

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


On 2016-May-27, at 5:23 PM, Bryan Drewery  wrote:

> On 5/27/2016 5:15 PM, Mark Millard wrote:
>> +--with-local-prefix=/usr/include \
>> 
>> looks wrong to me. The default is not /usr/local/include but just /usr/local 
>> . Quoting https://gcc.gnu.org/install/configure.html :
>> 
>> --with-local-prefix=dirname
>> Specify the installation directory for local include files. The default is 
>> /usr/local. Specify this option if you want the compiler to search directory 
>> dirname/include for locally installed header files instead of 
>> /usr/local/include.
>> 
>> So your change would generate /usr/include/include for the overall include 
>> path from what I can tell.
>> 
>> Do you want:
>> 
>> +--with-local-prefix=/usr \
>> 
>> instead?
> 
> You're right, but it makes no real difference since it removes
> /usr/local/include:
> 
>> ignoring nonexistent directory 
>> "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/include"
>> ignoring duplicate directory 
>> "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../../../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include"
>> ignoring nonexistent directory

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-05-27 Thread Bryan Drewery 
On 3/31/2016 8:33 PM, Mark Millard wrote:
> I appears that C++ needs its own override for where to find C++ header before 
> looking in the gcc49 specific places.

Yes, the hacks for that are builtin already.  Passing C_INCLUDE_PATH and
others may break it.

> These sorts of odd, hard to avoid dependencies are part of why I asked if 
> there was a standard/recommend assignment to use for CC/XCC: I was hoping 
> there was a known-good way to compile that avoided the issues, possibly by 
> using powerpc64-gcc tools for CC/XCC as well.

You shouldn't need to pass any extra -I/-isystem or env vars for paths.
The problem in this thread was just the ports compiler using
/usr/local/include when not using a --sysroot.  This is only in the
early phase of the build.

Mind trying this patch?

https://people.freebsd.org/~bdrewery/patches/gcc-no-local-include.patch

I assume you are using that port, if not you can apply the same change
to whichever your ports gcc came from.

It removes the /usr/local/include path.  It is somewhat the wrong fix vs
"fixing the order", but the /usr/local/lib path is not in there now and
you must use -rpath with the ports gcc anyhow.  So the ports gcc is
already broken for /usr/local, it should be fully broken or fully fixed,
not half broken to the point of breaking other things.

I'm still just curious if it fixes the problems with "stage 3" finding
the wrong dwarf header, and if removing your own include path hacks
progresses the build further.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-04-03 Thread Mark Millard 
On 2016-Apr-2, at 3:59 PM, Mark Millard  wrote:

> [My testing for the likes of the below does not yet extend outside powerpc64 
> contexts.]
> 
> For the likes of self-hosted powerpc64-xtoolchain-gcc/powerpc64-gcc use with, 
> say, gcc49 materials as the so-called "host" compiler tools I have not yet 
> found a way around using the workaround:
> 
>> # ls -l /usr/lib/libstdc++.*
>> lrwxr-xr-x  1 root  wheel  17 Feb 23 00:09 /usr/lib/libstdc++.a -> 
>> /usr/lib/libc++.a
>> lrwxr-xr-x  1 root  wheel  18 Feb 23 00:09 /usr/lib/libstdc++.so -> 
>> /usr/lib/libc++.so
> 
> 
> 
> But I appear to now have a src.conf (or a family of them) that avoids needing 
> workarounds in /usr/local/include and /usr/local/lib for filename conflicts. 
> This is based on CC/CXX ("HOST") and XCC/XCXX ("CROSS") in src.conf being the 
> likes of:
> 
> "HOST" (CC/CXX):
>> CC=env C_INCLUDE_PATH=/usr/include /usr/local/bin/gcc49 -L/usr/lib
>> CXX=env C_INCLUDE_PATH=/usr/include CPLUS_INCLUDE_PATH=/usr/include/c++/v1 
>> /usr/local/bin/g++49 -std=c++11 -nostdinc++ -L/usr/lib
> 
> and. . .
> 
> "CROSS" (XCC/XCXX):
>> TO_TYPE=powerpc64
>> TOOLS_TO_TYPE=${TO_TYPE}
>> . . .
>> VERSION_CONTEXT=11.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++
> 
> In other words: CROSS use is already handled for /usr/local/. . . just given 
> the compiler paths but some special src.conf adjustments beyond compiler 
> paths were needed for HOST.
> 
> So far it appears that gcc49 materials can be used in "CROSS" and/or 
> powerpc64-gcc materials can be used in "HOST" via just appropriate 
> compiler-path editing. (I have jumped to testing -r297514 but am still doing 
> various build tests. So this aspect is subject to updates.) It appears to be 
> possible to use just one compiler/tool family --but in the 2 different ways-- 
> instead of using a mix of 2 compiler/tool families.
> 
> Historically I've not gotten gcc variants to make a working lib32 for 
> powerpc64 and I've yet to retest this: So no claims about the lib32 status 
> are implied here. (The problem was code in crtbeginS that arbitrarily used 
> R30 in a way that the context was not set up for and so crtbeginS code was 
> dereferencing arbitrary addresses.)

I probably knew this someplace in the back of my head but gcc49 does not handle 
-fformat-extensions (quoting the script log):

> --- accf_data.o ---
> env /usr/local/bin/gcc49 -isystem 
> /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include 
> -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib 
> --sysroot=/usr/obj/xtoolchain/powerpc.powerp
> c64/usr/src/tmp -B/usr/local/powerpc64-portbld-freebsd11.0/bin/ -O2 -pipe  
> -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
> -DHAVE_KERNEL_OPTION_HEADERS -include 
> /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG/opt_global.h
>  -I. -I/usr/src/sys -fno-common -g -mlongcall -fno-omit-frame-pointer 
> -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG  
> -MD  -MF.depend.accf_data.o -MTaccf_data.o -mno-altivec -ffreestanding 
> -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
> -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
> -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
> -Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  
> -Wno-error=inline -Wno-error=enum-compare -Wno-error=unused-but-set-variable  
> -Wno-error=aggressive-loop-optimizations -Wno-error=maybe-uninitialized  
> -Wno-error=array-bounds -Wno-error=address  -Wno-error=cast-qual 
> -Wno-error=sequence-point -Wno-error=attributes  -Wno-error=strict-overflow 
> -Wno-error=overflow  -v -finline-limit=15000 -fms-extensions --param 
> inline-unit-growth=100 --param large-function-growth=1000 -msoft-float 
> -mcall-aixdesc -std=iso9899:1999 -c 
> /usr/src/sys/modules/accf_data/../../netinet/accf_data.c -o accf_data.o
> Using built-in specs.
> COLLECT_GCC=/usr/local/bin/gcc49
> gcc49: error: unrecognized command line option '-fformat-extensions'
> Target: powerpc64-portbld-freebsd11.0
> Configured with: ./../gcc-4.9-20160210/configure --disable-multilib 
> --disable-bootstrap --disable-nls --enable-gnu-indirect-function 
> --libdir=/usr/local/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49 
> --program-suffix=49 --with-as=/usr/local/bin/as --with-gmp=/usr/local 
> --with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/ 
> --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' 
> --with-system-zlib --disable-libgcj --enable-languages=c,c++,objc,fortran 
> --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man 
> --infodir=/usr/local/info/gcc49 --build=powerpc64-portbld-freebsd11.0
> Thread model: posix
> gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection) 
> *** [accf_data.o] Error code 1

So my

> it appears that gcc49

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-04-01 Thread Warner Losh 
On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric  wrote:

> On 01 Apr 2016, at 00:44, Warner Losh  wrote:
> >
> >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery 
> wrote:
> >> I didn't realize the ports compiler was defaulting /usr/local/include
> >> into the search path now.  It does not have /usr/local/lib in the
> >> default library path as far as I can tell.  It's also broken for its
> >> -rpath (noted in its pkg-message).  So having a default
> >> /usr/local/include path seems odd.
> >
> > It has for a while now. It’s one of the maddening inconsistencies that
> abound in this
> > area. I took a poll a while ago and there seemed to be widespread
> support for adding
> > it to the base compiler.
>
> This was the main reason /usr/local/include was *not* included in the
> base compiler, otherwise it would unpredictably pick up headers in
> /usr/local/include during builds.  You can never know which conflicting
> headers a certain user has installed in /usr/local/include... :)


That's why it shouldn't be *FIRST*, not why it shouldn't be there
at all.

>> Adding -isystem /usr/include to fix this is probably possible but
> >> there's a risk someone will remove it as redundant.  In this case I wish
> >> /usr/include was first but I'm not sure what impact that would have on
> >> consumers expecting /usr/local/include (and /usr/local/lib) overrides to
> >> work, though they would need to pass a -L /usr/local/lib anyhow and
> >> would likely be passing -I /usr/local/lib too.
> >
> > /usr/include should be first. But it isn’t. That’s another inconsistency
> that was found
> > when we looked at /usr/local stuff. Someone recently added
> /usr/local/bin to the path,
> > if I recall correctly.
>
> Isn't that a bit of a bikeshed?  I guess some people would just as well
> prefer /usr/local/include to be first, just like some people prefer
> /usr/local/bin before /usr/bin in their PATH.
>

Sigh. No. /usr/local is moving into many different things in the base and
ports. We should
do it in a consistent way. What we have now is not consistent and somewhat
brittle.


> In any case, if such paths are added to external compilers, we better
> make sure almost everything in buildworld uses -nostdinc, and specifying
> exactly the include directories we need, and no others.  Cumbersome, but
> maybe for a good cause.


That's the non-brittle solution here. An over-reliance on defaults makes it
difficult to ensure other compilers will work, especially ones we don't
tightly control the defaults for.

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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-04-01 Thread Dimitry Andric 
On 01 Apr 2016, at 00:44, Warner Losh  wrote:
> 
>> On Mar 31, 2016, at 4:34 PM, Bryan Drewery  wrote:
>> I didn't realize the ports compiler was defaulting /usr/local/include
>> into the search path now.  It does not have /usr/local/lib in the
>> default library path as far as I can tell.  It's also broken for its
>> -rpath (noted in its pkg-message).  So having a default
>> /usr/local/include path seems odd.
> 
> It has for a while now. It’s one of the maddening inconsistencies that abound 
> in this
> area. I took a poll a while ago and there seemed to be widespread support for 
> adding
> it to the base compiler.

This was the main reason /usr/local/include was *not* included in the
base compiler, otherwise it would unpredictably pick up headers in
/usr/local/include during builds.  You can never know which conflicting
headers a certain user has installed in /usr/local/include... :)


>> Adding -isystem /usr/include to fix this is probably possible but
>> there's a risk someone will remove it as redundant.  In this case I wish
>> /usr/include was first but I'm not sure what impact that would have on
>> consumers expecting /usr/local/include (and /usr/local/lib) overrides to
>> work, though they would need to pass a -L /usr/local/lib anyhow and
>> would likely be passing -I /usr/local/lib too.
> 
> /usr/include should be first. But it isn’t. That’s another inconsistency that 
> was found
> when we looked at /usr/local stuff. Someone recently added /usr/local/bin to 
> the path,
> if I recall correctly.

Isn't that a bit of a bikeshed?  I guess some people would just as well
prefer /usr/local/include to be first, just like some people prefer
/usr/local/bin before /usr/bin in their PATH.

In any case, if such paths are added to external compilers, we better
make sure almost everything in buildworld uses -nostdinc, and specifying
exactly the include directories we need, and no others.  Cumbersome, but
maybe for a good cause.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Mark Millard 
On 2016-Mar-31, at 8:14 PM, Mark Millard  wrote:
> 
> On 2016-Mar-31, at 5:02 PM, Bryan Drewery  wrote:
> 
>> This should be fine with my fix too.
>> 
>> Trying add this to your make.conf for now:
>> 
>> CFLAGS.gcc+= -isystem /usr/include
> 
> [Context note: I normally use:
> 
>> WITHOUT_CROSS_COMPILER=
>> #
>> WITH_FAST_DEPEND=
>> WITH_LIBCPLUSPLUS=
>> WITH_BOOT=
>> WITH_CLANG=
>> WITH_CLANG_IS_CC=
>> WITH_CLANG_FULL=
>> WITH_LLDB=
> 
> 
> so clang is built by powerpc64-gcc's tools even though clang is not used for 
> the build.
> ]
> 
> The result was almost immediate build failure:
> 
>> --- _bootstrap-tools-lib/clang/libllvmsupport ---
>> --- APFloat.o ---
>> In file included from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/AlignOf.h:19:0,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/SmallVector.h:18,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Allocator.h:24,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/StringMap.h:18,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Host.h:17,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/Hashing.h:49,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/ArrayRef.h:13,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APInt.h:19,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APFloat.h:20,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15:
>> /usr/local/lib/gcc49/include/c++/cstddef:51:11: error: '::max_align_t' has 
>> not been declared
>>   using ::max_align_t;
>   ^
> 
> ===
> Mark Millard
> markmi at dsl-only.net

I added using -v in CFLAGS.gcc in order for it to report include search paths. 
The last one of reported in the script output looks like:

> ignoring nonexistent directory 
> "/usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/../../../../../powerpc64-portbld-freebsd11.0/include"
> ignoring duplicate directory "/usr/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
>  /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
>  /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support
>  .
>  
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
>  /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include
>  /usr/include
>  /usr/local/lib/gcc49/include/c++/
>  /usr/local/lib/gcc49/include/c++//powerpc64-portbld-freebsd11.0
>  /usr/local/lib/gcc49/include/c++//backward
>  /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include
>  /usr/local/include
>  /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed
> End of search list.

I appears that C++ needs its own override for where to find C++ header before 
looking in the gcc49 specific places.

These sorts of odd, hard to avoid dependencies are part of why I asked if there 
was a standard/recommend assignment to use for CC/XCC: I was hoping there was a 
known-good way to compile that avoided the issues, possibly by using 
powerpc64-gcc tools for CC/XCC as well.

FYI: The last C compile in this script output lists:

> ignoring nonexistent directory 
> "/usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/../../../../../powerpc64-portbld-freebsd11.0/include"
> ignoring duplicate directory "/usr/include"
> ignoring duplicate directory 
> "/usr/src/kerberos5/tools/make-roken/../../include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/src/kerberos5/tools/make-roken/../../include
>  /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include
>  /usr/include
>  /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include
>  /usr/local/include
>  /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed
> End of search list.


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


On 2016-Mar-31, at 5:02 PM, Bryan Drewery  wrote:

> On 3/31/16 4:42 PM, Mark Millard wrote:
>> On 2016-Mar-31, at 3:34 PM, Bryan Drewery  wrote:
 #include "..." search starts here:
 #include <...> search starts here:
 /usr/local/lib/gcc49/include/c++/
 /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
 /usr/local/lib/gcc49/include/c++//backward
 /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
 /usr/local/include
 /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
 /usr/include
 End of search list.
>> Beyond /usr/local/include is also the fun

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Mark Millard 
On 2016-Mar-31, at 5:02 PM, Bryan Drewery  wrote:

> This should be fine with my fix too.
> 
> Trying add this to your make.conf for now:
> 
> CFLAGS.gcc+= -isystem /usr/include

[Context note: I normally use:

> WITHOUT_CROSS_COMPILER=
> #
> WITH_FAST_DEPEND=
> WITH_LIBCPLUSPLUS=
> WITH_BOOT=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_LLDB=


so clang is built by powerpc64-gcc's tools even though clang is not used for 
the build.
]

The result was almost immediate build failure:

> --- _bootstrap-tools-lib/clang/libllvmsupport ---
> --- APFloat.o ---
> In file included from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/AlignOf.h:19:0,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/SmallVector.h:18,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Allocator.h:24,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/StringMap.h:18,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Host.h:17,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/Hashing.h:49,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/ArrayRef.h:13,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APInt.h:19,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APFloat.h:20,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15:
> /usr/local/lib/gcc49/include/c++/cstddef:51:11: error: '::max_align_t' has 
> not been declared
>using ::max_align_t;
   ^

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

On 2016-Mar-31, at 5:02 PM, Bryan Drewery  wrote:

> On 3/31/16 4:42 PM, Mark Millard wrote:
>> On 2016-Mar-31, at 3:34 PM, Bryan Drewery  wrote:
 #include "..." search starts here:
 #include <...> search starts here:
 /usr/local/lib/gcc49/include/c++/
 /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
 /usr/local/lib/gcc49/include/c++//backward
 /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
 /usr/local/include
 /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
 /usr/include
 End of search list.
>> Beyond /usr/local/include is also the fun of [ignoring C++ specific issues]:
>> (My quoting of a copy/paste)
>> 
 # ls /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include*
 /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include:
 altivec.h  iso646.hppc-asm.h   
 spu2vmx.h   stdatomic.h stdint-gcc.h
 unwind.h
 float.hobjcppu_intrinsics.h
 ssp stdbool.h   stdint.h
 varargs.h
 htmintrin.homp.h   si2vmx.h
 stdalign.h  stddef.hstdnoreturn.h   
 vec_types.h
 htmxlintrin.h  paired.hspe.h   
 stdarg.hstdfix.htgmath.h
 
 /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed:
 README libmilter   limits.hnetinet 
 stddef.hstdio.h stdlib.hsys 
 syslimits.h unistd.hwchar.h
>> But at least in recent times after WCHAR_TYPE was fixed for 
>> powerpc/powerpc64 I've not had troubles that traced to these for CC and CXX 
>> being based on gcc49 while XCC and XCXX were based on powerpc64-gcc for 
>> buildworld/buildkernel on a powerpc64 host.
>> 
>> I have had various examples of /usr/local/include/ files breaking builds 
>> depending on what ports were in place at the time. All along I've been doing 
>> renaming in that area to allow buildworld/buildkernel use.
> 
> This should be fine with my fix too.
> 
> Trying add this to your make.conf for now:
> 
> CFLAGS.gcc+= -isystem /usr/include
> 
-- 
Regards,
Bryan Drewery

___
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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Warner Losh 

> On Mar 31, 2016, at 4:34 PM, Bryan Drewery  wrote:
> I didn't realize the ports compiler was defaulting /usr/local/include
> into the search path now.  It does not have /usr/local/lib in the
> default library path as far as I can tell.  It's also broken for its
> -rpath (noted in its pkg-message).  So having a default
> /usr/local/include path seems odd.

It has for a while now. It’s one of the maddening inconsistencies that abound 
in this
area. I took a poll a while ago and there seemed to be widespread support for 
adding
it to the base compiler.

> Adding -isystem /usr/include to fix this is probably possible but
> there's a risk someone will remove it as redundant.  In this case I wish
> /usr/include was first but I'm not sure what impact that would have on
> consumers expecting /usr/local/include (and /usr/local/lib) overrides to
> work, though they would need to pass a -L /usr/local/lib anyhow and
> would likely be passing -I /usr/local/lib too.

/usr/include should be first. But it isn’t. That’s another inconsistency that 
was found
when we looked at /usr/local stuff. Someone recently added /usr/local/bin to 
the path,
if I recall correctly.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Bryan Drewery 
On 3/31/16 3:02 PM, Mark Millard wrote:
>> > We likely just need to prioritize /usr/include over /usr/local/include
>> > for these phases, which gcc49 may have backwards since it has its prefix
>> > set to /usr/local from the ports build.

Yup this is the problem with using the ports compiler as the "host"
compiler:

> # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null
> Using built-in specs.
> COLLECT_GCC=/usr/local/bin/gcc49
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/lto-wrapper
> Target: x86_64-portbld-freebsd11.0
> Configured with: ./../gcc-4.9-20160210/configure 
> --with-build-config=bootstrap-debug --disable-nls 
> --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc49 
> --libexecdir=/usr/local/libexec/gcc49 --program-suffix=49 
> --with-as=/usr/local/bin/as --with-gmp=/usr/local 
> --with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/ 
> --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' 
> --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar 
> --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local 
> --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc49 
> --build=x86_64-portbld-freebsd11.0
> Thread model: posix
> gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection)
> COLLECT_GCC_OPTIONS='-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
>  /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/cc1plus -quiet 
> -v - -quiet -dumpbase - -mtune=generic -march=x86-64 -auxbase - -version -o 
> /tmp//ccA75yFy.s
> GNU C++ (FreeBSD Ports Collection) version 4.9.4 20160210 (prerelease) 
> (x86_64-portbld-freebsd11.0)
> compiled by GNU C version 4.9.4 20160210 (prerelease), GMP version 
> 5.1.3, MPFR version 3.1.3, MPC version 1.0.3
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> ignoring nonexistent directory 
> "/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/lib/gcc49/include/c++/
>  /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
>  /usr/local/lib/gcc49/include/c++//backward
>  /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
>  /usr/local/include
>  /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
>  /usr/include
> End of search list.

Note the /usr/local/include and /usr/include order near the end.

Passing -isystem /usr/include seems to fix it:

> # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null -isystem /usr/include
> Using built-in specs.
> COLLECT_GCC=/usr/local/bin/gcc49
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/lto-wrapper
> Target: x86_64-portbld-freebsd11.0
> Configured with: ./../gcc-4.9-20160210/configure 
> --with-build-config=bootstrap-debug --disable-nls 
> --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc49 
> --libexecdir=/usr/local/libexec/gcc49 --program-suffix=49 
> --with-as=/usr/local/bin/as --with-gmp=/usr/local 
> --with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/ 
> --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' 
> --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar 
> --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local 
> --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc49 
> --build=x86_64-portbld-freebsd11.0
> Thread model: posix
> gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection)
> COLLECT_GCC_OPTIONS='-v' '-o' '/dev/null' '-isystem' '/usr/include' 
> '-mtune=generic' '-march=x86-64'
>  /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/cc1plus -quiet 
> -v -isystem /usr/include - -quiet -dumpbase - -mtune=generic -march=x86-64 
> -auxbase - -version -o /tmp//ccNh006Z.s
> GNU C++ (FreeBSD Ports Collection) version 4.9.4 20160210 (prerelease) 
> (x86_64-portbld-freebsd11.0)
> compiled by GNU C version 4.9.4 20160210 (prerelease), GMP version 
> 5.1.3, MPFR version 3.1.3, MPC version 1.0.3
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> ignoring nonexistent directory 
> "/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/include"
> ignoring duplicate directory "/usr/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/include
>  /usr/local/lib/gcc49/include/c++/
>  /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
>  /usr/local/lib/gcc49/include/c++//backward
>  /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
>  /usr/local/include
>  /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed

I didn't realize the ports compiler was defaulting /usr/local/include
into the search path now.  It does not have /usr/local/lib in the
default library path as far as I

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Mark Millard 

> On 2016-Mar-31, at 2:32 PM, Bryan Drewery  wrote:
> 
> On 3/31/16 2:23 PM, Mark Millard wrote:
>> I use the likes of:
>> 
 # diff -rq /usr/include /usr/local/include | grep "^Files "
>> to find what to rename for the duration of the system builds.
>> 
>> An example of what happens without the renames is below but I first note the 
>> use of the name dwarf_errmsg in /usr/include vs. in /usr/local/include 
>> (shown after the .h file rename but the build was with the normal file name):
>> 
> 
> Except for legacy, build-tools, bootstrap-tools, and cross-tools, none
> of /usr/include or /usr/local/include is supposed to be included.  In
> those phases though it is intended that /usr/include is used.  Not
> /usr/local/include though.
> 
> What package is providing /usr/local/include/libdwarf.h? 'pkg which
> /usr/local/include/libdwarf.h'  I ask so I can install it and recreate
> the issue and fix it.

Here is the list for the things I renamed, including for dwarf.h :

> # pkg which /usr/local/include/dwarf.h /usr/local/include/libdwarf.h 
> /usr/local/include/atf-c/defs.h /usr/local/include/iconv.h 
> /usr/local/include/histedit.h
> /usr/local/include/dwarf.h was installed by package libdwarf-20130207
> /usr/local/include/libdwarf.h was installed by package libdwarf-20130207
> /usr/local/include/atf-c/defs.h was installed by package atf-0.21
> /usr/local/include/iconv.h was not found in the database
> /usr/local/include/histedit.h was installed by package libedit-3.1.20150325_1

It looks like iconv.h is from something later removed but was not cleaned out 
at the time. I have /usr/local/include/readline/ material from the same time 
frame:

> # ls -lt /usr/local/include/
> .. . .
> -rw-r--r--   1 root  wheel   12733 Apr 22  2015 mpc.h
> -rw-r--r--   1 root  wheel9348 Mar 12  2015 renamed_iconv.h
> drwxr-xr-x   2 root  wheel 512 Mar 12  2015 readline
> # ls -lt /usr/local/include/readline
> total 80
> -rw-r--r--  1 root  wheel   3193 Mar 12  2015 rltypedefs.h
> -rw-r--r--  1 root  wheel   2438 Mar 12  2015 rlconf.h
> -rw-r--r--  1 root  wheel   1835 Mar 12  2015 rlstdc.h
> -rw-r--r--  1 root  wheel   3046 Mar 12  2015 tilde.h
> -rw-r--r--  1 root  wheel  10079 Mar 12  2015 history.h
> -rw-r--r--  1 root  wheel   3163 Mar 12  2015 keymaps.h
> -rw-r--r--  1 root  wheel   4577 Mar 12  2015 chardefs.h
> -rw-r--r--  1 root  wheel  37802 Mar 12  2015 readline.h

but "pkg which" reports those files as being from readline-6.3.8 .

I guess I can just delete would would normally have been 
/usr/local/include/iconv.h .

Back to quoting the earlier message:

> We likely just need to prioritize /usr/include over /usr/local/include
> for these phases, which gcc49 may have backwards since it has its prefix
> set to /usr/local from the ports build.
> 
 # find /usr/include/ -exec grep dwarf_errmsg {} \; -print
 #definedwarf_errmsg(error) dwarf_errmsg_()
 const char *dwarf_errmsg_(Dwarf_Error *);
 /usr/include/libdwarf.h
 # find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print
 char* dwarf_errmsg(Dwarf_Error/*error*/);
 /usr/local/include/renamed_libdwarf.h
 #
>> So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from 
>> /usr/include .
>> 
>> The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ --and 
>> dwarf_errmsg being undefined (dwarf_errno has similar issues):
>> 
 --
>> stage 3: cross tools
 --
 . . .
 --- ctfconvert.full ---
 /usr/local/bin/gcc49 -O2 -pipe 
 -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris 
 -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include
  -I/usr/src/cddl/usr.b
 in/ctfconvert/../../../cddl/contrib/opensolaris 
 -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris 
 -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head 
 -I/us
 r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common
>>> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt
>>> -I/usr/src/cddl/usr.bin/ctfconvert/.
 ./../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g 
 -std=gnu99 
 -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include  
 -static -L/usr/obj/xtoolchain/powerpc.power
 pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o 
 ctfconvert.o dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o 
 memory.o merge.o output.o st_parse.o stabs.o stack.o strtab.o symbol
 .o tdata.o traverse.o util.o   -ldwarf  -lelf  -lelf  -lz  -lpthread 
 -legacy
 dwarf.o: In function `die_off':
 /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:270:
  undefined reference to `dwarf_errmsg'
 dwarf.o:

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Bryan Drewery 
On 3/31/16 2:23 PM, Mark Millard wrote:
> I use the likes of:
> 
>> > # diff -rq /usr/include /usr/local/include | grep "^Files "
> to find what to rename for the duration of the system builds.
> 
> An example of what happens without the renames is below but I first note the 
> use of the name dwarf_errmsg in /usr/include vs. in /usr/local/include (shown 
> after the .h file rename but the build was with the normal file name):
> 

Except for legacy, build-tools, bootstrap-tools, and cross-tools, none
of /usr/include or /usr/local/include is supposed to be included.  In
those phases though it is intended that /usr/include is used.  Not
/usr/local/include though.

What package is providing /usr/local/include/libdwarf.h? 'pkg which
/usr/local/include/libdwarf.h'  I ask so I can install it and recreate
the issue and fix it.

We likely just need to prioritize /usr/include over /usr/local/include
for these phases, which gcc49 may have backwards since it has its prefix
set to /usr/local from the ports build.

>> > # find /usr/include/ -exec grep dwarf_errmsg {} \; -print
>> > #definedwarf_errmsg(error) dwarf_errmsg_()
>> > const char *dwarf_errmsg_(Dwarf_Error *);
>> > /usr/include/libdwarf.h
>> > # find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print
>> > char* dwarf_errmsg(Dwarf_Error/*error*/);
>> > /usr/local/include/renamed_libdwarf.h
>> > #
> So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from 
> /usr/include .
> 
> The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ --and 
> dwarf_errmsg being undefined (dwarf_errno has similar issues):
> 
>> > --
> > >>> stage 3: cross tools
>> > --
>> > . . .
>> > --- ctfconvert.full ---
>> > /usr/local/bin/gcc49 -O2 -pipe 
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris 
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include
>> >  -I/usr/src/cddl/usr.b
>> > in/ctfconvert/../../../cddl/contrib/opensolaris 
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris 
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head 
>> > -I/us
>> > r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common
>> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt
>> -I/usr/src/cddl/usr.bin/ctfconvert/.
>> > ./../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g 
>> > -std=gnu99 
>> > -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include  
>> > -static -L/usr/obj/xtoolchain/powerpc.power
>> > pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o 
>> > ctfconvert.o dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o 
>> > memory.o merge.o output.o st_parse.o stabs.o stack.o strtab.o symbol
>> > .o tdata.o traverse.o util.o   -ldwarf  -lelf  -lelf  -lz  -lpthread 
>> > -legacy
>> > dwarf.o: In function `die_off':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:270:
>> >  undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_sibling':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:288:
>> >  undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_child':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:305:
>> >  undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_tag':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:319:
>> >  undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_unsigned':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:370:
>> >  undefined reference to `dwarf_errmsg'
>> > dwarf.o:/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:418:
>> >  more undefined references to `dwarf_errmsg' follow
>> > dwarf.o: In function `dw_read':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1963:
>> >  undefined reference to `dwarf_errno'
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1971:
>> >  undefined reference to `dwarf_errmsg'
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1977:
>> >  undefined reference to `dwarf_errmsg'
>> > collect2: error: ld returned 1 exit status
>> > *** [ctfconvert.full] Error code 1
> 


-- 
Regards,
Bryan Drewery
___
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"

svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Mark Millard 
Recent changes have been trying to make things like 
powerpc64-xtoolchain-gcc/powerpc64-gcc work better for buildworld/buildkernel.

I happen to do this on a powerpc64 context so the "cross build" is actually 
self-hosted. No gcc 4.2.1 is present and clang 3.8.0 and before have code 
generation problems for powerpc64 and powerpc so I avoid it for system builds, 
including for stage 3. (Also, clang for powerpc64 does not support building 
libstand: no soft-float support.)

As of my last test (-r297465) buildworld's stage 3 failed from implicit use of 
/usr/local/include materials unless I renamed various files there. In part this 
is because of my using gcc49 tools for CC and for CXX while using the 
powerpc64-gcc tools only for XCC and XCXX.

Is there a standard or recommended way to configure things to avoid such 
issues? Should powerpc64-gcc use be forced for CC and CXX as well as XCC and 
XCXX?

Should there be xtoolchain usage notes about avoiding /usr/local/include name 
conflicts and/or about how to assign CC/CXX/XCC/XCXX?

As long as I use gcc49 tools for CC and CXX I still must do things like 
renaming files in /usr/local/include to avoid them interfering with system 
headers:

> # find /usr/local/include/ -name 'renamed*' -print
> /usr/local/include/renamed_dwarf.h
> /usr/local/include/atf-c/renamed_defs.h
> /usr/local/include/renamed_iconv.h
> /usr/local/include/renamed_libdwarf.h
> /usr/local/include/renamed_histedit.h

I use the likes of:

> # diff -rq /usr/include /usr/local/include | grep "^Files "

to find what to rename for the duration of the system builds.

An example of what happens without the renames is below but I first note the 
use of the name dwarf_errmsg in /usr/include vs. in /usr/local/include (shown 
after the .h file rename but the build was with the normal file name):

> # find /usr/include/ -exec grep dwarf_errmsg {} \; -print
> #define   dwarf_errmsg(error) dwarf_errmsg_()
> const char*dwarf_errmsg_(Dwarf_Error *);
> /usr/include/libdwarf.h
> # find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print

> char* dwarf_errmsg(Dwarf_Error/*error*/);
> /usr/local/include/renamed_libdwarf.h
> #

So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from 
/usr/include .

The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ --and 
dwarf_errmsg being undefined (dwarf_errno has similar issues):

> --
> >>> stage 3: cross tools
> --
> . . .
> --- ctfconvert.full ---
> /usr/local/bin/gcc49 -O2 -pipe 
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris 
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include 
> -I/usr/src/cddl/usr.b
> in/ctfconvert/../../../cddl/contrib/opensolaris 
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris 
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head 
> -I/us
> r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common
>  
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt
>  -I/usr/src/cddl/usr.bin/ctfconvert/.
> ./../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g 
> -std=gnu99 
> -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include  
> -static -L/usr/obj/xtoolchain/powerpc.power
> pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o ctfconvert.o 
> dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o memory.o merge.o 
> output.o st_parse.o stabs.o stack.o strtab.o symbol
> .o tdata.o traverse.o util.o   -ldwarf  -lelf  -lelf  -lz  -lpthread -legacy
> dwarf.o: In function `die_off':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:270:
>  undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_sibling':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:288:
>  undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_child':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:305:
>  undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_tag':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:319:
>  undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_unsigned':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:370:
>  undefined reference to `dwarf_errmsg'
> dwarf.o:/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:418:
>  more undefined references to `dwarf_errmsg' follow
> dwarf.o: In function `dw_read':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1963:
>  undefined reference to `dwarf_errno'
>

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Bryan Drewery 
On 3/31/16 2:23 PM, Mark Millard wrote:
> Should there be xtoolchain usage notes about avoiding /usr/local/include name 
> conflicts and/or about how to assign CC/CXX/XCC/XCXX?
> 
> As long as I use gcc49 tools for CC and CXX I still must do things like 
> renaming files in /usr/local/include to avoid them interfering with system 
> headers:

Try setting X_COMPILER_TYPE=gcc as well.

-- 
Regards,
Bryan Drewery
___
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"