Old Synopsis: CLang does not define __STDC_ISO_10646__, despite having Unicode
in wchar_t
New Synopsis: clang does not define __STDC_ISO_10646__, despite having Unicode
in wchar_t
Responsible-Changed-From-To: freebsd-bugs->freebsd-toolchain
Responsible-Changed-By: linimon
Responsible-Chan
On Tue, Sep 11, 2012 at 10:07:04AM +0100, David Chisnall wrote:
> There is some logic in the clang driver already for knowing when it is
> invoked as gcc. I'd be quite tempted to make gcc a symlink to clang
> and make clang default to gnu89 when invoked in that way.
And how then does a port say "
On Tue, Sep 11, 2012 at 11:27:50AM +0200, Lars Engels wrote:
> At the moment the ports maintainers don't give much about if their ports
> build with CLANG or not because they're not forced to.
I think this is a mis-representation.
Adding the requirement "your ports must work on clang" is adding a
On Wed, Sep 12, 2012 at 03:03:43PM +0200, Lars Engels wrote:
> two of the ports I maintain don't build with CLANG, yet. I
> just checked that on the wiki page [1].
To repeat myself, the ports I've listed on that page are the "big
problems". People need to look at the errorlogs URLs up at the
top
On Thu, Sep 13, 2012 at 08:21:31AM +0200, Pietro Cerutti wrote:
> On 2012-Sep-11, 23:29, Doug Barton wrote:
> > What we need to do is what I and others have been asking to do for
> > years. We need to designate a modern version of gcc (no less than 4.6)
> > as the official default ports compiler, a
On Fri, Jan 25, 2013 at 08:41:11AM +, David Chisnall wrote:
> I think all of the ports that don't build with clang are now explicitly
> depending on gcc.
Nope. We switched some of the most notorious failures, but hundreds
more remain -- mostly leaf ports.
Without the ability to run -exp buil
On Fri, Jan 25, 2013 at 03:36:15PM -0500, Pedro Giffuni wrote:
> I don't care much about gcc in current.
clang, even on -9, can't build the following:
- most of kde
- graphics/GraphicsMagick
- editors/emacs21
- www/libxul19
any one of which I would consider showstoppers for making a gcc-less
On Sat, Jan 26, 2013 at 05:24:27PM +0200, Konstantin Belousov wrote:
> Ports should use port-provided compiler, and be untangled from the base
> toolchain.
And when I get the use of the build cluster back, it's one of the bits
of code I intend to work on. But we're not going to be able to do that
On Fri, Aug 30, 2013 at 10:41:18AM -0400, John Baldwin wrote:
> So my take away from this is that you have no plans to support any platform
> that doesn't support clang as you just expect ia64 and sparc64 to die and
> not be present in 11.0. That may be the best path, but I've certainly not
> seen
On Tue, Nov 22, 2016 at 10:08:29AM +0200, clutton wrote:
> New www/chromium port (currently only on github) has problems building
> on 10.1 and 9x releases because of outdated libc++ [...] Are there
> any plans to update the port?
I'm not the person doing the work, so I can't say for sure, but ...
On Tue, Nov 22, 2016 at 10:27:25AM +0200, clutton wrote:
> but 10x pkg builders work on 10.1.
IIUC it's strictly "pkg builders work on the oldest supported release
on a given branch" which means they will get upgraded soon too.
In _theory_ 10.1 ports are supposed to work on 10.2 and 10.3, if ever
On Fri, Feb 17, 2017 at 12:14:42AM -0800, Mark Millard wrote:
> Are these R_AARCH64_ABS64 notices expected? Are they a problem?
Is the following post relevant?
https://lists.freebsd.org/pipermail/svn-ports-all/2017-February/144857.html
mcl
___
freebsd-
On Fri, Apr 14, 2017 at 08:27:29PM -0700, Mark Millard wrote:
> I've seen material quoted from a exp-run that reported
> that about 54(?) ports were then blocked by lang/gcc6-aux
> not building.
Although the first is an older run (the last complete run IIUC), there
were 50 and 51 respectively as o
On Fri, Apr 28, 2017 at 05:24:27PM -0700, Mark Millard wrote:
> BROKEN_powerpc64=Does not build
I'm attempting builds now. The message is from the last time it was tried,
many months ago.
mcl
___
freebsd-toolchain@freebsd.org mailing list
https://
On Fri, Apr 28, 2017 at 07:15:05PM -0700, Mark Millard wrote:
> The armv7 attempt at devel/amd64-gcc also got
> the "=a" problem, such as:
>
> /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/driver-i386.c:608:2:
> error: invalid output constraint '=a' in asm
>
On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote:
> It appears that qemu-ppc64-static and qemu-ppc-static from
> emulators/qemu-user-static are broken.
Correct, and known for some time. (fwiw sparc64 hangs as well.)
mcl
___
freebsd-toolchai
On Thu, May 23, 2019 at 10:33:35PM -0700, Mark Millard via freebsd-toolchain
wrote:
> That is no matter what the system compiler is for powerpc64.
>
> This lead to the below mixing of libstdc++.so.6 and libc++/libcxxrt . . .
Yeah. This is probably my fault.
We've baked the assumption into port
> devel/freebsd-gcc6
> devel/freebsd-gcc6@aarch64
These two ports are exactly equivalent.
I did not have enough time before the commit to puzzle out a way to
work around that. I have limited understanding of flavors.
The way it *should* work IMHO is for the former to refuse to build
with a mess
18 matches
Mail list logo
