On Sat, 13 Nov 2021, Konstantin Belousov wrote:
>> --
>> commit 160b4b922b6
>> Author: Konstantin Belousov
>> Date: Sat Oct 23 00:17:21 2021
>>
>> Add real sched.h
>>
>> It is required by IEEE Std 1003.1-2008 AKA POSIX
Hi everyone,
just a heads-up that...
On Sun, 5 Nov 2017, Gerald Pfeifer wrote:
> I should have gcc8-devel updated in the next 24 hours, gcc7-devel
> and gcc6-devel over the week as new snapshots are released.
:
> Once the respective -devel ports are updated, I'll take
On Sun, 5 Nov 2017, Andreas Tobler wrote:
> Pushed on all active branches, 8/7/6.
Saw that, thank you. Very well done, Andreas!
I should have gcc8-devel updated in the next 24 hours, gcc7-devel
and gcc6-devel over the week as new snapshots are released.
> If you could do the gcc* branches, yes
On Wed, 1 Nov 2017, Tijl Coosemans wrote:
> Please commit it to the ports tree as well, because there are reports
> that ftp/curl can trigger the problem.
What Andreas and me usually are doing is that he commits fixes
upstream (from HEAD down to release branches), I pick them up when
updating th
On Tue, 31 Oct 2017, Andreas Tobler wrote:
> Do we, FreeBSD'ers, want to have gcc unwind support on older than
> FreeBSD 9.3 releases? I think the gcc folks do not care, but we are the
> ones who might have an need for such a support?
> @Gerald, do you have an opinion?
Yes. No. :-)
Those possib
On Sun, 8 Nov 2015, Pedro Giffuni wrote:
> Great! We already worked around the issue by disabling
> stack-protector-strong for gcc48 though.
Yep - it still felt like the right thing to also address this in the port.
> What looks somewhat strange to me is that lang/gcc is an independent
> port
On Tue, 13 Oct 2015, Justin Hibbits wrote:
> As Antoine mentioned, the problem is that lang/gcc does not have this
> patch. USE_GCC uses lang/gcc, not lang/gcc48. So lang/gcc needs to
> be updated.
I have (finally) managed to steal the team, kicked off testing,
and plan on committing the patches
On Mon, 26 Aug 2013, Claude Buisson wrote:
> Perhaps you could have a look at the fact that lang/gcc is at 4.6.3,
> and lang/gcc46 is no more a snapshot but a true release 4.6.4.
I am aware of that. Owed to a strongly voiced desire by users,
I am triggering a rebuild of lang/gcc as rarely as pos
On Fri, 23 Aug 2013, Bernhard Fröhlich wrote:
> A possible hack could be to add a check for USE_GCC=any to behave like
> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc
> from ports for a lot of people on HEAD I suppose.
I am planning to work on this a bit more once the two
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 with it?"
> This is a stupid idea. It kills the tightly inte
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 strictly gcc 4.2.1 was bigger for me then number of
> ports that can't be compiled with clang b
On Fri, 23 Aug 2013, Bernhard Fröhlich wrote:
> lang/gcc42 is on the list of ports that have USE_GCC=any. So you would
> need to fix it first to be able to compile it with clang 3.3 from base.
I don't think so. :-)
You can install lang/gcc which builds just fine with clang, and
then use lang/gcc
On Tue, 11 Sep 2012, Erik Cederstrand wrote:
> So can we do a sweep on the ports tree and mark the 2232 ports with
> USE_GCC=4.2 until they can actually build with clang? This could allow
> the clang switch to proceed. Hopefully, waiting for GCC to compile just
> to install some tiny port will b
eally need to check for the FreeBSD version? I had understood
that simply reading from the device should work on 4.x, old 5.x, and
-CURRENT. Søren, Kris?
Gerald
--
Gerald Pfeifer (Jerry) [EMAIL PROTECTED] http://www.pfeifer.com/gerald/
___
[EMAIL PROT
On Tue, 8 Jul 2003, Julian Elischer wrote:
> I'm looking at this and I think that my interpretation is that
> WINE, under FreeBSD, blindly allocates LDT entries starting at location 17,
> without looking to see if they are in use already..
Do you think that's a bug in Wine, or just a Linuxism? In
On Fri, 8 Nov 2002, Pierre Beyssac wrote:
> Fine, but if included "as is" in Wine because, it will break
> compatibility with Net/OpenBSD because DBREG_DRX is a FreeBSDism...
> that's why I surrounded my patch with a #ifdef DBREG_DRX (which
> seems cleaner than a #ifdef __FreeBSD__).
Sheesh.
PHK,
On Fri, 8 Nov 2002, Pierre Beyssac wrote:
>> As for source compatibility, just use the DBREG_DRX macro, which exists
>> in both -STABLE and -CURRENT (it was merged into -STABLE two years ago).
> It's too bad source compatibility hasn't been preserved.
Indeed.
> Argument d is not properly parenthe
On Wed, 30 Oct 2002, Krzysztof [iso-8859-2] Jêdruczyk wrote:
> Yesterday I tried to upgrade wine on my FreeBSD-current box. It didn't
> compile until I changed following in server/context_i386.c (looks like
> this is because of commit of 1.28 version of src/sys/i386/include/reg.h)
Thanks for the h
This *is* a regression (even if it may be hard to fix on the release
branch), so I'm raising it's priority.
Gerald
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, 16 Oct 2000, Szilveszter Adam wrote:
> Also, since 2.96 has not even been released yet, I assume the
> maintainer (bruce, AFAIK) just makes sure that it builds and compiles
> stuff OK and so by the time 5.0 will be released and hopefully 2.96
> too, we just have to push the button and it w
On Wed, 23 Feb 2000, Victor A. Salaman wrote:
> Anyways, after sending email to marcel and peter with the patches, I haven't
> even received a reply. :-(
>
> So therefore, I'm posting them here, in case anyone wants to commit
> them at all. I feel 4.0 shouldn't go out with a known broken linux
> e
On Thu, 8 Jul 1999, The Hermit Hacker wrote:
> Three weeks ago, I, and a few other INN administrators, posted about
> FreeBSD -STABLE's inability to run the newest INN code, due to MMAP() race
> conditions...essentially, after X hours of run time, on a heavily loaded
> INN server, the whole thing
I'm only subscribed to freebsd-stable, so I missed the original thread,
but reading the lines below, a question arises:
On Wed, 21 Apr 1999, Matthew Dillon wrote:
> Well, you already see a lot of the pure bug fixes being backported.
> What you don't see in -stable are the bug fixes that also depen
23 matches
Mail list logo
