Re: Removing obsolete GDB 6.1.1 for FreeBSD 13

On Wed, Dec 2, 2020 at 10:44 AM Ed Maste wrote: > We currently have an obsolete version of GDB 6.1 installed as > /usr/libexec/gdb, kept only for use by crashinfo(8), which extracts > some basic information from a kernel core dump after a crash. If the > gdb port is installed crashinfo will use

Re: Remove ftime() interceptor defs from compiler-rt/FreeBSD

On Sat, Nov 21, 2020, 9:26 PM Kyle Evans wrote: > Hi, > > Can we remove the ftime() interceptor definitions that are FreeBSD > specific in compiler-rt? See: > https://people.freebsd.org/~kevans/intercept.diff -- the very act of > including sys/timeb.h adds build noise from the warning about it

Re: head -r357401 broke my powerpc/powerpc64 builds: I build with sc present [the added "static" caused the failures]

On Mon, Feb 3, 2020 at 3:33 AM Mark Millard wrote: > [Turns out to be the added "static".] > > On 2020-Feb-2, at 15:10, Mark Millard wrote: > > > [I forgot to send some context.] > > > > On 2020-Feb-2, at 14:51, Mark Millard wrote: > > > >> --- kernel.full --- > >> ld: error: undefined symbol:

Re: head -r357401 broke my powerpc/powerpc64 builds: I build with sc present

I'll take a look... that's likely my fault for fixing the bogus duplication that wasn't quite duplicated. On Mon, Feb 3, 2020 at 12:10 AM Mark Millard wrote: > [I forgot to send some context.] > > On 2020-Feb-2, at 14:51, Mark Millard wrote: > > > --- kernel.full --- > > ld: error: undefined

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

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

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

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

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

[Differential] [Accepted] D3175: ar: add -U (unique) option to disable -D (deterministic) mode

imp accepted this revision. imp added a reviewer: imp. This revision has a positive review. REVISION DETAIL https://reviews.freebsd.org/D3175 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: emaste, brooks, bapt, imp Cc: freebsd-toolchain-list

[Differential] [Commented On] D1932: Remove the non-standard CC alias for c++

imp added a comment. CC has been an alias for the default C++ compiler the entire life FreeBSD has had a C++ compiler. Sure, it isn't based on any standards but it is a very de-facto standard that many ports rely on. FreeBSD isn't the only system to do this. Sun did this for years, as did SGI,

[Differential] [Requested Changes To] D1932: Remove the non-standard CC alias for c++

imp requested changes to this revision. imp added a reviewer: imp. imp added a comment. This revision now requires changes to proceed. So it is icky likely isn't a good enough reason. Do a ports run w/o it causing any problems and prove me wrong... REPOSITORY rS FreeBSD src repository

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

[Differential] [Accepted] D2576: Update crunch bootstrapping test

imp accepted this revision. imp added a comment. This revision has a positive review. matches my memory, but I didn't verify the R numbers as correct. I assume Ed did, so I'm good with this in... REVISION DETAIL https://reviews.freebsd.org/D2576 EMAIL PREFERENCES

[Differential] [Accepted] D2408: Add ELF Tool Chain's c++filt to the build

imp added a subscriber: imp. imp accepted this revision. imp added a reviewer: imp. imp added a comment. I came to troll you for TOLO - YOLO, but brooks beat me to it... REVISION DETAIL https://reviews.freebsd.org/D2408 EMAIL PREFERENCES

[Differential] [Updated] D2305: Fix bootstraping of crunchide

imp added a comment. I think that we've stumbled on more stuff we can just kill :) INLINE COMMENTS Makefile.inc1:1469 I'd be inclined to promote it. Makefile.inc1:1470 Can you tell me where in the tree we define RELEASEDIR? Is it still even a thing? Makefile.inc1:1475 I'd love to know

[Differential] [Commented On] D2305: Fix bootstraping of crunchide

imp added inline comments. INLINE COMMENTS Makefile.inc1:1476 kgzip is actually old, detritus, so I removed it in D2313. REVISION DETAIL https://reviews.freebsd.org/D2305 To: rodrigc, imp, emaste Cc: freebsd-toolchain ___

[Differential] [Commented On] D2305: Fix bootstraping of crunchide

imp added inline comments. INLINE COMMENTS Makefile.inc1:1470 RELEASEDIR is detritus, so I removed it in D2313. It hasn't been a thing since FreeBSD 9's rewrite of the release process. REVISION DETAIL https://reviews.freebsd.org/D2305 To: rodrigc, imp, emaste Cc: freebsd-toolchain

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

[Differential] [Accepted] D2156: Switch to ELF toolchain readelf

imp accepted this revision. imp added a comment. This revision is now accepted and ready to land. Looks good REVISION DETAIL https://reviews.freebsd.org/D2156 To: emaste, imp Cc: freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list

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

[Differential] [Accepted] D2003: Do not strip crunched binary; it will be done by install

imp accepted this revision. imp added a comment. This revision is now accepted and ready to land. Looks good to me. REVISION DETAIL https://reviews.freebsd.org/D2003 To: emaste, andrew, imp Cc: freebsd-toolchain ___ freebsd-toolchain@freebsd.org

[Differential] [Accepted] D1819: libdwarf: Handle .rel relocations

imp accepted this revision. imp added a reviewer: imp. REVISION DETAIL https://reviews.freebsd.org/D1819 To: emaste, br, rpaulo, gnn, imp Cc: rpaulo, freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list

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

[Differential] [Accepted] D1722: Add -s option to config

imp accepted this revision. imp added a comment. This revision is now accepted and ready to land. Looks good to me. REVISION DETAIL https://reviews.freebsd.org/D1722 To: rodrigc, brooks, imp Cc: freebsd-toolchain ___ freebsd-toolchain@freebsd.org

[Differential] [Accepted] D1682: Preserve hard symbolic links when modifying source file

imp accepted this revision. imp added a reviewer: imp. REVISION DETAIL https://reviews.freebsd.org/D1682 To: emaste, rpaulo, imp Cc: freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list

[Differential] [Accepted] D1543: crunchide: Correct 64-bit section header offset

imp accepted this revision. imp added a reviewer: imp. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1543 To: emaste, pfg, imp Cc: freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list

[Differential] [Accepted] D1468: Fix the ARM build of compiler-rt

imp accepted this revision. imp added a reviewer: imp. This revision is now accepted and ready to land. BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D1468 To: andrew, loos, sbruno, rpaulo, ian, dim, imp Cc: freebsd-toolchain ___

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

[Differential] [Accepted] D1327: Do not strip all when stripping an explicit symbol

imp added a subscriber: imp. imp accepted this revision. imp added a reviewer: imp. imp added a comment. This revision is now accepted and ready to land. Looks good to me. REVISION DETAIL https://reviews.freebsd.org/D1327 To: emaste, imp Cc: imp, freebsd-toolchain

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

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

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

  1   2   >