Re: cross-compiling for arm with clang

On Jun 21, 2011, at 3:12 AM, Damjan Marion wrote: On Jun 17, 2011, at 9:16 PM, Warner Losh wrote: On Jun 17, 2011, at 12:38 PM, Damjan Marion wrote: Now, I'm back on my original problem, clang invokes /usr/bin/as which is i386 AS instead of ARM version in obj tree. That's a bogus

Re: ARM issue with old binutils

On Jun 25, 2011, at 9:16 AM, Gerald Pfeifer wrote: On Wed, 22 Jun 2011, Damjan Marion wrote: I see 3 options to fix this: 1. Ask clang folks to patch llvm to use old mnemonics (mov r0, r0, rrx instead of rrx r0,r0) 2. Maintain same patch for freebsd only 3. patch binutils to support

Re: [help] rebuild libc failed

You need to use buildworld or one of its sub-targets. Warner On Aug 4, 2011, at 2:38 AM, majia gm wrote: Hi, everyone. I'm building the libc code which derived from a current trunk mirror/freebsd/head under PCBSD 8.2 which contains FreeBSD 8.2 release. I'm trying to test the modified

Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported

We really need a 'SYSTEM_COMPILER={gcc,clang,xxx}' sort of knob. Warner On Aug 18, 2011, at 2:04 PM, Kostik Belousov wrote: On Thu, Aug 18, 2011 at 09:54:41PM +0200, Dimitry Andric wrote: The problem is in your make.conf. Effectively, you are doing: CC = clang CXX = clang++ which will

Re: [toolchain] disable -Wtautological-compare for clang

I'm all for leaving it on because things like char are signed on some architectures and unsigned on others. This leads to bugs that only appear on one architecture. This warning will, at least, flag those usages. On Oct 17, 2011, at 10:56 AM, Gerald Pfeifer wrote: On Mon, 17 Oct 2011,

Re: [poc] buildkernel + clang + -Werror

On Nov 6, 2011, at 1:58 PM, Alexander Best wrote: On Sun Nov 6 11, Dimitry Andric wrote: On 2011-11-06 21:33, Alexander Best wrote: ... the problem is, something like uint x; if (x 0) ... clang will warn about this, yet it is 100% valid code so my vote would be to make such an

Re: [poc] buildkernel + clang + -Werror

On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote: The only argument against this tautological check that I agree with is when the code is explicitly trying to be safe. If the developer checks for i 0 when indexing an array he/she is trying to guard against possible pitfalls in the future when

Re: [poc] buildkernel + clang + -Werror

On Nov 6, 2011, at 5:47 PM, Rui Paulo wrote: On Nov 6, 2011, at 4:36 PM, Warner Losh wrote: On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote: The only argument against this tautological check that I agree with is when the code is explicitly trying to be safe. If the developer checks for i 0

Re: setting CC/CXX/CPP unconditionally in src.conf

On Feb 26, 2012, at 2:37 PM, Alexander Best wrote: hi there, any chance support for setting CC/CXX/CPP unconditionally in src.conf could be added before the release of freebsd 10.0? the way it is done atm is really not intuitive. the rule should really be: - make.conf = applies globally

Re: gcc46 header search path

On Jul 6, 2012, at 1:11 PM, David Chisnall wrote: On 6 Jul 2012, at 17:54, Andriy Gapon wrote: Yeah. Honestly speaking I myself was not aware of what is written in that link and I thought that our gcc ports (from ports) added /usr/local/include to the default search path by some

Re: BSD archive file formats

Hi Pete, the best way to find out if support for archives are needed is to release it for testing. People find the craziest things when testing in a wider arena. Alternatively, see if can survive /usr/ports being thrown at it :) even clang can't do that yet (although it isn't always clang's

Re: Using non-standard linker

On Dec 13, 2012, at 6:18 AM, Erik Cederstrand wrote: Den 13/12/2012 kl. 14.10 skrev David Chisnall thera...@freebsd.org: Hi Eric, The easiest way of doing this is to make /usr/bin/ld (in the host system and in the bootstrap) into a symbolic link that points to whatever the selected

Re: Removing default build of gcc

On Jan 25, 2013, at 4:31 AM, Konstantin Belousov wrote: On Fri, Jan 25, 2013 at 08:41:11AM +, David Chisnall wrote: Hi All, In 10.0, the plan is not to ship any GPL'd code, so I'd like to start disconnecting things from the default build, starting with gcc. I've been running a

Re: Removing default build of gcc

On Jan 25, 2013, at 3:18 PM, Andriy Gapon wrote: on 25/01/2013 21:35 Warner Losh said the following: This has been talked about in a vague way for years. Warner, just a nitpick, couldn't resist - sorry, so for years we talked about the magic 10.x release to become GPL-free

Re: c89 broken on head?

On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote: On 2013-03-07 21:22, Tijl Coosemans wrote: ... Because it's the practical thing to do? Old code/makefiles can't possibly be expected to know about compilers of the future, while new code can be expected to add -std=c11. I am not sure I

Re: c89 broken on head?

On Mar 7, 2013, at 8:07 PM, Eitan Adler wrote: On 7 March 2013 18:03, Tijl Coosemans t...@coosemans.org wrote: On 2013-03-07 22:36, Warner Losh wrote: On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote: On 2013-03-07 21:22, Tijl Coosemans wrote: ... Because it's the practical thing to do

Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree

On May 7, 2013, at 9:42 PM, Garrett Cooper wrote: On Tue, May 7, 2013 at 2:26 PM, Garrett Cooper yaneg...@gmail.com wrote: On Tue, May 7, 2013 at 2:00 PM, Warner Losh i...@bsdimp.com wrote: On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: On May 7, 2013, at 1:39 PM, Brooks Davis

Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree

On May 7, 2013, at 11:41 PM, Simon J. Gerraty wrote: On Tue, 7 May 2013 21:25:37 -0600, Warner Losh writes: where does MAKEOBJDIRPREFIX come into play? I don't normally use it, it is a handy but rather crude implement. I normally use MAKEOBJDIR='${.CURDIR:S,${SRCTOP},${OBJTOP

Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)

On Aug 23, 2013, at 5:16 AM, Kurt Jaeger wrote: Hi! I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions

Re: patch to add AES intrinsics to gcc

On Aug 23, 2013, at 6:30 AM, Ian Lepore wrote: On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote: On 23 Aug 2013, at 11:42, Julian Elischer jul...@freebsd.org wrote: no, I believe we have said that 10 would ship with clang by default. NO mention was made about gcc being absent, and

Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)

On Aug 23, 2013, at 7:54 AM, David Chisnall wrote: On 23 Aug 2013, at 14:52, Warner Losh i...@bsdimp.com wrote: No. That breaks non x86 architecutres. gcc must remain in base for now, or there's no bootstrap ability. Nobody has done the lifting to cleanly integrate gcc as a port

Re: patch to add AES intrinsics to gcc

On Aug 23, 2013, at 4:01 PM, Alfred Perlstein wrote: On 8/23/13 3:35 AM, David Chisnall wrote: On 23 Aug 2013, at 10:58, Bernhard Fröhlich de...@freebsd.org wrote: I don't know if you are aware that IF you really do that we will have serious problems to ship packages for 10. USE_GCC=any

Re: patch to add AES intrinsics to gcc

On Aug 24, 2013, at 4:05 AM, David Chisnall wrote: On 23 Aug 2013, at 23:37, Warner Losh i...@bsdimp.com wrote: I'd dispute the 'and surely it seems like it does' part of this. Non x86 architectures will continue to use gcc because clang just isn't ready at this time for them. Some

Re: GCC withdraw

On Aug 24, 2013, at 6:11 AM, Sam Fourman Jr. wrote: In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Well, in this case, you would

Re: patch to add AES intrinsics to gcc

On Aug 25, 2013, at 7:12 PM, Gerald Pfeifer wrote: On Sat, 24 Aug 2013, Warner Losh wrote: If you push gcc out to a port, and you have the 'external compiler' toolchain support working correctly enough to build with this, why don't we just push clang out to a port, and be done

Re: patch to add AES intrinsics to gcc

Can all such ports be identified with a ports build run in a special chroot without FreeBSD's FCC installed? Sent from my iPad On Aug 25, 2013, at 7:41 PM, Gerald Pfeifer ger...@pfeifer.com wrote: On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: I object. Many ports that compiles perfectly on

Re: patch to add AES intrinsics to gcc

On Aug 27, 2013, at 8:46 AM, Nathan Whitehorn wrote: On 08/25/13 18:41, Gerald Pfeifer wrote: On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled with lang/gcc. I checked this once and the number of ports that require

Re: GCC withdraw

On Aug 29, 2013, at 8:57 AM, John Baldwin wrote: On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote: On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote: So I vote, let's not give ourselves the burden of lugging dead weight in base for another 5 years. (in 2017 do

Re: GCC withdraw

On Aug 29, 2013, at 11:02 AM, David Chisnall wrote: On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote: I have not seen any convincing argument as to why leaving GCC in the base for 10.x impedes anything. Because clang isn't sufficient for so many non-x86 platforms we can't

Re: GCC withdraw

I had a long, rambling reply to this that corrected many of the factual errors made in it. But why bother. You have your world view, it doesn't match what people are doing today and this mismatch is going to cause people pain and suffering in the embedded world far beyond what you think. And

Re: Best autoconf recipe to use for modern FreeBSD

On Sep 12, 2013, at 7:32 PM, Murray Stokely wrote: Some application software I use seems to prefer ancient gcc release or gcc46 from ports rather than clang. Is there a recommended autoconf recipe for third party software to use the right compilers across FreeBSD versions? I thought the

Re: Best autoconf recipe to use for modern FreeBSD

=FreeBSD # override configure preference for gcc since FreeBSD ships an ancient one. AC_PROG_CC(clang llvm-gcc gcc) AC_PROG_CXX(clang++ llvm-g++ g++) else AC_PROG_CC AC_PROG_CXX fi ? - Murray On Thu, Sep 12, 2013 at 6:56 PM, Warner Losh i...@bsdimp.com wrote

make xdev broken

In 9.2 stable on amd64, make xdev is broken. sudo make xdev XDEV=i386 XDEV_ARCH=i386 terminates with In file included from /imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:17:

Re: make xdev broken

On Nov 17, 2013, at 2:45 PM, Dimitry Andric wrote: On 17 Nov 2013, at 20:37, Warner Losh i...@bsdimp.com wrote: In 9.2 stable on amd64, make xdev is broken. sudo make xdev XDEV=i386 XDEV_ARCH=i386 terminates with In file included from /imp/svn/stable/9/lib/clang/libclanganalysis

Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).

On Nov 24, 2013, at 5:54 AM, David Chisnall wrote: On 23 Nov 2013, at 22:11, Pedro Giffuni p...@freebsd.org wrote: I have particular interest in -fwritable-strings and the block support, mostly with the idea of making our gcc somewhat more compatible to clang. I would absolutely love to

Re: More dangerous UB handling of clang (compared to gcc)

On Feb 28, 2014, at 8:06 AM, Dmitry Marakasov amd...@amdmi3.ru wrote: Hi! Another issue I wanted to mention: compared to gcc, clang handles some undefined behaviour cases more dangerously. It has the full right to do so as it's UB, however we may want to take extra steps to find and fix

Re: More dangerous UB handling of clang (compared to gcc)

On Mar 1, 2014, at 4:18 PM, Ahmed Charles achar...@outlook.com wrote: Subject: Re: More dangerous UB handling of clang (compared to gcc) From: bsd...@gmail.com Date: Fri, 28 Feb 2014 08:38:38 -0700 To: amd...@amdmi3.ru CC:

Re: Building clang in buildworld as part of the bootstrap process -- is it really necessary?

On Sep 5, 2014, at 8:21 PM, Garrett Cooper yaneurab...@gmail.com wrote: Hi all, One of the questions that came up from a co-worker is why do I need to build clang in buildworld if I already installed it from ports? I could see some valid reasons for doing this (one needs a

Re: Building clang in buildworld as part of the bootstrap process -- is it really necessary?

On Sep 6, 2014, at 5:32 AM, Dimitry Andric d...@freebsd.org wrote: On 06 Sep 2014, at 05:16, Warner Losh i...@bsdimp.com wrote: On Sep 5, 2014, at 8:21 PM, Garrett Cooper yaneurab...@gmail.com wrote: One of the questions that came up from a co-worker is why do I need to build clang

Re: Migration to dynamic libs for llvm and clang

On Dec 16, 2014, at 9:32 AM, Dimitry Andric d...@freebsd.org wrote: On 16 Dec 2014, at 17:15, David Chisnall thera...@freebsd.org wrote: On 16 Dec 2014, at 16:04, Dimitry Andric d...@freebsd.org wrote: This is precisely why the libs should go into /usr/lib/private, so as to avoid

Re: Migration to dynamic libs for llvm and clang

On Dec 16, 2014, at 10:44 AM, Ed Maste ema...@freebsd.org wrote: Fair enough, I'd definitely like to see fewer build-time knobs over time, not more. Until we stop using build-time knobs to control what’s in the final image as a poor man’s packaging scheme, I expect the number of knobs to

Re: RFT: Please help testing the llvm/clang 3.5.0 import

This is excellent news Dimitry! On Dec 16, 2014, at 12:36 PM, Dimitry Andric d...@freebsd.org wrote: On 28 Nov 2014, at 22:03, Dimitry Andric d...@freebsd.org wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On Dec 18, 2014, at 12:01 PM, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 15:47, Warner Losh i...@bsdimp.com wrote: ... * Mips will only have a chance with the upcoming clang 3.6.0, but that is way too late for this import. It will probably require external toolchain

armeb build of clang350-import

Thought I’d try to build armeb on clang350-import branch on my ad64 host, and found it failed to build because of a dependency on a machine include that doesn’t exist yet. % make buildworld TARGET=arm TARGET_ARCH=armeb -DWITHOUT_GCC{,_BOOTSTRAP} -DWITH_CLANG{,_BOOTSTRAP} ... === gnu/lib/libgcc

Re: Resurrecting clang external toolchain support in Makefile.inc

On Feb 10, 2015, at 7:32 PM, Peter Grehan gre...@freebsd.org wrote: Hi toolchain folk, I've recently tried using the base system clang as an external toolchain i.e. make CROSS_COMPILER_PREFIX=/usr/bin/ buildworld .. and found that this no longer works after r273755 which split

Re: Resurrecting clang external toolchain support in Makefile.inc

On Feb 11, 2015, at 5:02 PM, Peter Grehan gre...@freebsd.org wrote: Hi Bapt, In my opinion we should track down the last traces of XFLAGS and turn them into proper XCFLAGS and XCXXFLAGS, the intent was to get rid of XFLAGS because the name was confusing. so instead of adding XFLAGS

Re: Resurrecting clang external toolchain support in Makefile.inc

On Feb 11, 2015, at 7:14 PM, Peter Grehan gre...@freebsd.org wrote: Hi Warner, I like this patch better than the one I have. I’m not 100% sure the ‘else’ clause will work The else for CROSS_BINUTILS_PREFIX ? If so, yes, that appears to work: I'm building with in-tree binutils. Ok

Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists

On Mar 16, 2015, at 7:02 PM, Dimitry Andric d...@freebsd.org wrote: On 16 Mar 2015, at 09:02, Mark Millard mar...@dsl-only.net wrote: I found why gcc 4.2.1's cc1plus was getting -std=c++11 for the CROSS_TOOLCHAIN=powerpc64-gcc compiles that involve WITH_CLANG= . (WITHOUT_CLANG= does

Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists

-Mar-12, at 01:24 PM, Warner Losh imp at bsdimp.com wrote: Sorry to top post, but try adding WITH_CLANG=t Warner On Mar 13, 2015, at 4:18 AM, Mark Millard mar...@dsl-only.net wrote: Basic context: $ freebsd-version -ku; uname -a 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0

Re: powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue

On Mar 12, 2015, at 6:36 PM, Mark Millard mar...@dsl-only.net wrote: Basic context for the observation (powerpc64 example): # freebsd-version -ku; uname -a 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 19:23:14 PDT 2015

Re: Failed to build with external toolchain

On Mar 24, 2015, at 9:18 PM, Craig Rodrigues rodr...@freebsd.org wrote: On Sat, Mar 7, 2015 at 3:48 PM, Dimitry Andric d...@freebsd.org wrote: On 07 Mar 2015, at 21:12, Craig Rodrigues rodr...@freebsd.org wrote: I ran the build again and this time I am getting errors about undefined

Re: Fails to build sys/i386/boot2 with gcc 4.9

On Mar 29, 2015, at 6:37 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Mar 29, 2015, at 15:56, Warner Losh i...@bsdimp.com wrote: On Mar 29, 2015, at 2:29 PM, Craig Rodrigues rodr...@freebsd.org wrote: On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote: If we

Re: Kernel compilation failures with gcc 4.9

On Mar 31, 2015, at 4:53 PM, Rui Paulo rpa...@me.com wrote: On Mar 31, 2015, at 14:04, Craig Rodrigues rodr...@freebsd.org wrote: Hi, I put this in make.conf: NO_WERROR=yes WERROR= WITHOUT_BOOT=yes WITHOUT_RESCUE=yes and used this script to build:

Re: Fails to build sys/i386/boot2 with gcc 4.9

On Mar 29, 2015, at 2:27 AM, Roman Divacky rdiva...@freebsd.org wrote: I used this script to build with gcc 4.9: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh Buildling sys/i386/boot2 failed: ... output: fmt=bin size=21ef text=200 data=1fef org=0

Re: Fails to build sys/i386/boot2 with gcc 4.9

On Mar 29, 2015, at 2:29 PM, Craig Rodrigues rodr...@freebsd.org wrote: On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote: If we built a UFS1-only boot2, that would fit in the 7.5k we have left to play with. We could then build a UFS2-only boot2 that would easily fit

Re: Shorter report: powerpc64-xtoolchain-gcc use fails from powerpc (non-64)

On Apr 1, 2015, at 4:37 PM, Mark Millard mar...@dsl-only.net wrote: On 2015-Apr-1, at 02:49 PM, Warner Losh imp at bsdimp.com wrote: On Apr 1, 2015, at 2:44 PM, Mark Millard mar...@dsl-only.net wrote: Attempting to use CROSS_TOOLCHAIN=powerpc64-gcc on powerpc (non-64) 11.0-CURRENT

Re: Failed to build rescue with gcc 4.9

On Apr 3, 2015, at 10:58 AM, Craig Rodrigues rodr...@freebsd.org wrote: On Thu, Apr 2, 2015 at 8:27 AM, Craig Rodrigues rodr...@freebsd.org wrote: Actually, I am building on a 10.1-RELEASE box. I was able to get this successful build:

Re: External toolchain build failing due to missing --sysroot

On Mar 20, 2015, at 2:10 PM, Craig Rodrigues rodr...@freebsd.org wrote: Warner, I can't get the external toolchain build of CURRENT to work, because --sysroot seems to be missing in some places. I don’t believe that this has actually never worked, or if it did appear to work, it was only

Re: External toolchain build failing due to missing --sysroot

On May 18, 2015, at 2:02 PM, Craig Rodrigues rodr...@freebsd.org wrote: On Mon, May 18, 2015 at 12:30 PM, Warner Losh i...@bsdimp.com wrote: On Mar 20, 2015, at 2:10 PM, Craig Rodrigues rodr...@freebsd.org wrote: Warner, I can't get the external toolchain build of CURRENT to work

Re: Failed to build rescue with gcc 4.9

On Apr 2, 2015, at 8:27 AM, Craig Rodrigues rodr...@freebsd.org wrote: On Sat, Mar 28, 2015 at 2:34 PM, Craig Rodrigues rodr...@freebsd.org wrote: Hi, The build host VM that I used was FreeBSD 10.1-RELEASE, amd64. I took this patch for libc++ and applied it to my tree:

Re: clang confuses kgdb on static symbols

> On Oct 20, 2015, at 3:07 PM, Ed Maste wrote: > > On 20 October 2015 at 16:30, Konstantin Belousov wrote: >> >> Wouldn't this cause another outburst of 'works by default' discussion >> from some other place ? > > Ok, I'll hold off on this until we

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

On Tue, Jan 5, 2016 at 11:27 AM, Mark Millard wrote: > llvm.org's Bugzilla reports that clang trunk has been fixed and clang 3.8 > will contain the fixes: > > James Molloy changed bug 25958 > WhatRemoved Added > Status NEW RESOLVED > Resolution --- FIXED >

Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

So what happens if we actually fix the underlying bug? I see two ways of doing this. In findfp.c, we allocate an array of FILE * today like: g = (struct glue *)malloc(sizeof(*g) + ALIGNBYTES + n * sizeof(FILE)); but that assumes that FILE just has normal pointer alignment requirements.

Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

lang is layered on top of. Nor if there is just one > bad thing or many. > > Note: I had not yet tried buildworld/buildkernel for the context of the "-f" > option that I was experimenting with earlier. So I do not have a direct > compare and contrast at this point. > >

Re: 11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float)

On Wed, May 25, 2016 at 10:12 AM, Mark Millard wrote: > I'm not sure that Gerald or Brooks were CC'd on a report made to the arm > list about armv6 builds of gcc and llvm being broken now because of hard > float now being implicit: > (the first report listed below has more

Re: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts?

On Sun, Feb 14, 2016 at 12:21 PM, Mark Millard wrote: > Is buildworld supposed to use /usr/include's area for finding files by > default? (I'm not talking of ${WORLDTMP}/usr/include but of just > /usr/include.) > Yes, but only though the end of the bootstrap phase. > It

Re: make buildworld failed with error "relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'"

> On Jan 21, 2016, at 2:41 PM, Mark Millard wrote: > > On Thu Jan 21 13:11:03 UTC 2016 Andrew Turner andrew at fubar.geek.nz wrote" > >> I've disabled setting -mlong-calls on the clang libraries for now, >> however I expect we will need to enable it again when clang 3.8.0

Re: How to insist on only clang, for world/kernel?

Then you may be able to do make buildworld CC=clang (or whatever clang is compiled as. No guarantee, sine I've not played with 9.x in a while. Warner On Fri, Mar 11, 2016 at 8:20 AM, Chris H <bsd-li...@bsdforge.com> wrote: > On Thu, 10 Mar 2016 21:49:01 -0700 Warner Losh <i..

Re: How to insist on only clang, for world/kernel?

make buildworld WITH_CLANG=t WITH_CLANG_BOOTSTRAP=t WITHOUT_GCC=y WITHOUT_GCC_BOOTSTRAP=t WITH_CLANG_IS_CC=t make buildkernel But that's mostly default these days, so really most people get what you want by doing make buildworld buildkernel Warner On Thu, Mar 10, 2016 at 9:23 PM, Chris H

Re: CXXSTD=c++11

> On Mar 24, 2016, at 4:36 PM, Bryan Drewery wrote: > > Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds > now? We do this when using an external GCC since it doesn't default to > the c++11 standard quite yet. As far as I understand, we require

Re: CPUTYPE=armv7-a with CPUTYPE=soft (as an example)?

On Mar 23, 2016 9:57 PM, "Mark Millard" wrote: > > Between: > > > Q: But what if I need to build a system with soft float ABI under 11? > > > > You can still do that. CPUTYPE=soft has been created for this scenario, as well as to generate libraries for WITH_LIBSOFT. It's

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

On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric <d...@freebsd.org> wrote: > On 01 Apr 2016, at 00:44, Warner Losh <i...@bsdimp.com> wrote: > > > >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery <bdrew...@freebsd.org> > wrote: > >> I didn't realize the

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

> 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

Re: Update on using LLVM's lld linker in the FreeBSD base system

>> Generally, I like it though. My concerns are mostly with ports and gcc plans. >> Though it isn't coupled to gcc, I'd suggest that we want to have a joint plan >> for both before we get out the axes. Note this is purely a timing argument, >> not whether to get them out, just when :) > > Yes,

Re: Time to enable partial relro

On Thu, Aug 25, 2016 at 4:50 PM, Pedro Giffuni wrote: > Hello; > > GNU RELRO support was committed in r230784 (2012-01-30) but we never enabled > it by default. So what's the summary of why we'd want to do that? What benefit does it bring? Sure, other folks do it, but why?

Re: Time to enable partial relro

On Fri, Aug 26, 2016 at 8:36 AM, Ed Maste <ema...@freebsd.org> wrote: > On 26 August 2016 at 10:18, Warner Losh <i...@bsdimp.com> wrote: >> >> So what's the summary of why we'd want to do that? What benefit does it >> bring? >> Sure, other folks do it,

Re: Time to enable partial relro

> On Aug 26, 2016, at 9:14 AM, Pedro Giffuni <p...@freebsd.org> wrote: > > Hello; > > On 08/26/16 10:06, Warner Losh wrote: >> On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni <p...@freebsd.org> wrote: >>> >>> >>> On 08/26/16 05:56

Re: Time to enable partial relro

> On Aug 26, 2016, at 9:20 AM, Pedro Giffuni <p...@freebsd.org> wrote: > > > > On 08/26/16 10:08, Warner Losh wrote: >> On Fri, Aug 26, 2016 at 9:06 AM, Pedro Giffuni <p...@freebsd.org> wrote: >>> >>> >>> On 08/26/16 10:01, Warne

Re: Time to enable partial relro

On Fri, Aug 26, 2016 at 9:06 AM, Pedro Giffuni <p...@freebsd.org> wrote: > > > On 08/26/16 10:01, Warner Losh wrote: >> >> On Fri, Aug 26, 2016 at 8:36 AM, Ed Maste <ema...@freebsd.org> wrote: >>> >>> On 26 August 2016 at 10:18, Warner Los

Re: -r321371 amd64 -> powerpc64 cross build: lldb.full link fails with: c++: error: linker command failed with exit code 1, -B/usr/local/powerpc64-freebsd/bin/ in use

On Mon, Jul 24, 2017 at 1:33 AM, Mark Millard wrote: > [I forgot that linking lldb historically failed on armv6 > (cortex-a7) based on the historical system binutils.] > > On 2017-Jul-23, at 8:51 PM, Mark Millard wrote: > > > [Using WITH_LLDB= had no

Re: FCP-100: armv7 plan

On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich <jbe...@freebsd.org> wrote: > Warner Losh <i...@bsdimp.com> writes: > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich <jbe...@vfemail.net> wrote: > > > >> Warner Losh <i...@bsdimp.com> writes: > >&

Re: FCP-100: armv7 plan

On Sat, Sep 9, 2017 at 2:34 PM, Ian Lepore <i...@freebsd.org> wrote: > On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote: > > Warner Losh <i...@bsdimp.com> writes: > > > > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich <jbe...@vfemail.net>

Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard wrote: > When I attempted to use the result of: > > # cp -aRx /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi > /mnt/EFI/BOOT/ > > the pine64+ boot sequence got over and over > a sequence like: > > U-Boot 2017.07

Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

On Sun, Sep 10, 2017 at 3:18 PM, Mark Millard <mar...@dsl-only.net> wrote: > On 2017-Sep-10, at 1:17 PM, Warner Losh wrote: > > > On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard <mar...@dsl-only.net> > wrote: > > When I attempted to use the result of: > >

Re: svn commit: r322824 - in head: lib/clang share/mk usr.bin/clang

On Fri, Aug 25, 2017 at 12:27 PM, Ed Maste wrote: > On 25 August 2017 at 14:07, Ryan Libby wrote: > > On Wed, Aug 23, 2017 at 4:30 PM, John Baldwin wrote: > >> Author: jhb > >> Date: Wed Aug 23 23:30:25 2017 > >> New Revision: 322824 > >>

Re: Head build unsafe for /etc today

On Thu, Nov 2, 2017 at 8:41 PM, Bryan Drewery wrote: > > > > On Nov 2, 2017, at 19:23, Steve Kargl > wrote: > > > >> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote: > >> > >> > On Nov 2, 2017, at 18:49, Steve Kargl

Re: Migrating arm(v7) to LLD_BOOTSTRAP

On Tue, Jan 16, 2018 at 4:45 PM, Ed Maste wrote: > With the update to Clang/LLVM/lld 6.0.0 I believe lld is nearly ready > to be used as the system linker for armv7, and I plan to enable > LLD_BOOTSTRAP by default after a couple of WIP patches land and after > a little more

Re: Broken arm support in clang now?

On Sat, Aug 11, 2018 at 1:01 PM, Mark Millard < mark.mill...@nexustechnology.com> wrote: > On 2018-Aug-11, at 11:09 AM, Dimitry Andric wrote: > > > > On 11 Aug 2018, at 19:31, Warner Losh wrote: > >> > >> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andri

Re: Broken arm support in clang now?

On Thu, Aug 16, 2018 at 8:14 AM, Mark Millard wrote: > On 2018-Aug-16, at 6:38 AM, Ed Maste wrote: > > > On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain > > wrote: > >> > >> Is the link command itself available? (The .../sys/*/kernel.full.meta > >> likely has it if it is still

Broken arm support in clang now?

It looks like armv5 clang bogusly uses lld: >From a 'make buildkernel' of the RT1310 kernel config: cc -target arm-gnueabi-freebsd12.0 --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp -B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c -O -pipe -g -nostdinc -I.

Re: Broken arm support in clang now?

On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote: > On 11 Aug 2018, at 16:55, Warner Losh wrote: > > > > It looks like armv5 clang bogusly uses lld: > > > > From a 'make buildkernel' of the RT1310 kernel config: > > > > cc -target arm-gnueabi-freebsd1

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

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

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

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

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain < freebsd-toolchain@freebsd.org> wrote: > On 9/21/18 4:06 PM, Mark Johnston wrote: > > > > https://reviews.freebsd.org/D17279 for anyone else that would like to > > review. > > > Is that possibly related to the error I'm getting

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

s from the host as well, even though we rebuild them... Warner On Fri, Sep 21, 2018 at 9:38 PM Rebecca Cran wrote: > On 9/21/18 9:35 PM, Warner Losh wrote: > > > > I meant to add, can you give a few lines before the error is spewed > > here in email? My IRC computer died before

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran wrote: > On 9/21/18 9:09 PM, Warner Losh wrote: > > > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain < > > freebsd-toolchain@freebsd.org> wrote: > > > >> On 9/21/18 4:06 PM, Mark Johnston w

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On Fri, Sep 21, 2018 at 9:34 PM Warner Losh wrote: > > > On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran wrote: > >> On 9/21/18 9:09 PM, Warner Losh wrote: >> >> > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain < >> > freebsd-toolch

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On Fri, Sep 21, 2018 at 9:59 PM Rebecca Cran wrote: > On 9/21/18 9:57 PM, Warner Losh wrote: > > > Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say? > > > > They look good for me, but the only way you get this error is if they > > are wrong

Re: External GCC Update

On Fri, Feb 22, 2019, 5:09 PM John Baldwin wrote: > On 2/22/19 11:45 AM, Rodney W. Grimes wrote: > >> I was recently able to install base/binutils and base/gcc into an amd64 > VM > >> and do a self-hosted build and install. Some of the port patches have > been > >> committed from this, but I

Re: Is libc C99 compliant?

On Wed, Jan 30, 2019 at 11:33 PM Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > When building gcc file gcc/config/freebsd.c contains > > #define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function > > In targhook.c, one finds > > /* By default we assume that c99 functions are present at

  1   2   >