The FreeBSD implementation here looks racy. If one thread dlcloses an object
while another thread is exiting, we can end up calling a function at an invalid
memory address. It also looks as if it may be possible to unload one library,
load another at the same address, and end up executing enti
On 23 Nov 2018, at 16:23, Ed Maste wrote:
>
> For some time we have been incrementally working to retire the use of
> obsolete GNU Binutils 2.17.50 tools. At present we still install three
> binutils by default:
>
> as
> ld.bfd
> objdump
We probably need to kill ld.bfd before 12.0. It predates
On 19/03/2019 00:01, Eric Joyner wrote:
On Sun, Mar 17, 2019 at 6:35 AM Hans Petter Selasky wrote:
See the freebsd-build utils package for Linux.
--HPS
Is there anything for Windows?
Your best bet on Windows is to use the Windows Subsystem for Linux
(WSL). This lets you install a Linux
On 29/04/2019 14:19, Lev Serebryakov wrote:
I'm not very interested in packetized base for "big servers" which
contains full FreeBSd installation
'Big servers' may have a full FreeBSD installation in the base system,
but they may also have hundreds of jails that want the absolute minimum
re
On 29/04/2019 21:12, Joe Maloney wrote:
With CFT version you chose to build, and package individual components such as
sendmail with a port option. That does entirely solve the problem of being
able to reinstall sendmail after the fact without a rebuild of the userland
(base) port but perhaps
On 19 May 2019, at 20:43, Igor Mozolevsky wrote:
>
> the best
> explanation of democracy I have ever heard was: "two wolves and a
> sheep deciding what to have for dinner!"
If you believe that this quote in any way supports your argument, then I would
suggest that you work through the game theo
On 15/08/2019 17:48, Konstantin Belousov wrote:
> Please look at https://reviews.freebsd.org/D21060
> I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
>
> It probably does not matter when all your software comes from ports or
> packages, but is actually very annoying when developin
On 16/08/2019 10:10, Konstantin Belousov wrote:
You did not read neither review summary nor followups.
This is needlessly insulting and this kind of attitude from you towards
people on the mailing lists is one of the main reasons that my
engagement with the FreeBSD project tends to be in br
There are a couple of similar issues currently. The other one that comes to
mind is that every X11 application that needs to use OpenGL (or similar) must
open /dev/dri/{something}, but the default permissions only permit root.
The correct solution is probably to ship a devfs.conf that puts thes
On 19 Oct 2014, at 23:09, Craig Rodrigues wrote:
> (2) Most devops engineers in web/mobile companies are familiar with
>Linux. Any differences between Linux and FreeBSD in
> command-line
>utilities are not show-stoppers, but they are annoyances.
>Anything
On 21 Oct 2014, at 00:15, Mason Loring Bliss wrote:
> The second thing that would be useful would be a series of cheat sheets for
> various things. This can either be equivalent commands or equivalent systems.
> Let new folks know that LUKS is GELI and that md-raid1 is gmirror and so
> forth. Sho
On 29 Oct 2014, at 03:11, Ed Maste wrote:
> /usr/lib/debug is the standard location for standalone debug data
> established by GDB, and seems like a decent enough location. I'll make
> sure to update the man page.
Do gdb and lldb also look in /usr/local/lib/debug? If not, it would be great
if
On 11 Nov 2014, at 03:35, Allan Jude wrote:
> jkh@ mentioned this specifically when he gave his talk at EuroBSDCon and
> MeetBSD, about how Apple solved this in LaunchD, because apparently
> originally libc DID check /etc/localtime constantly.
Darwin also has the notify(3) interface, which allow
On 15 Nov 2014, at 18:56, Alfred Perlstein wrote:
> git clone --config remote.origin.fetch='+refs/notes/*:refs/notes/*'
> https://github.com/freebsd/freebsd.git
You might want to add --depth 2000 (where 2000 is a guess at how many commits
there have been since when it broke and now), to avoid
Fir the clang 3.4 import, I had some patches (that never got applied), which
used clang -O0 and then opt with some custom optimisation order to get a
reasonable size saving. It might be worth trying that, so that future changes
to the default optimisation order don't make things worse again.
D
On 2 Jan 2015, at 05:00, Ed Maste wrote:
>
> It's a variable length array in a struct / union. Other than being
> confusing and now triggering a warning after the clang update it
> should be fine.
>
> Most likely we need to build asr with -Werror disabled for that
> warning, perhaps -Wno-error-a
On 5 Feb 2015, at 07:48, Luigi Rizzo wrote:
>
> Rather than depending on a compiler option, wouldn't it be better/more
> robust to change ticks to unsigned, which has specified wrapping behavior?
Especially if we want to extend support for external toolchains. gcc and clang
support -fwrapv (th
On 12 Feb 2015, at 04:49, Glen Barber wrote:
>
> I would like to see it enabled by default for 11.0-RELEASE.
For everyone concerned about size, remember that the goal for 11.0-RELEASE is
to use pkg for the base system, which makes it much easier to:
- Install some debug info later, on demand.
On 1 Mar 2015, at 18:49, Harrison Grundy
wrote:
>
> That does seem useful, but I'm not sure I see the reasoning behind
> putting into base, over a port or package, since processing XML in base
> is a pain, and it can't serve up JSON or HTML without additional
> utilities anyway.
How would it be
On 1 Mar 2015, at 21:29, Rui Paulo wrote:
>
> On Mar 1, 2015, at 11:11, David Chisnall wrote:
>> How would it be in a port? It involves modifying core utilities (some of
>> which, like ifconfig, rely on kernel APIs that change between releases) to
>> emit structured
On 2 Mar 2015, at 09:16, Julian Elischer wrote:
>
> if we develop a suitable post processor with pluggable grammars, we save a
> lot of work.
> given enough examples you could almost have automatically generated grammars.
This decoupled approach is problematic. A large part of the point of lib
On 2 Mar 2015, at 09:24, Harrison Grundy
wrote:
>
> It would seem like the libxo stuff runs the risk of becoming this same
> API.
Why? The 'API' in the case of an libxo-ised program is a stream on stdout that
is then consumed by a JSON or XML parser. XML and JSON are intrinsically
extensible
On 3 Mar 2015, at 01:32, Andrey Chernov wrote:
>
> So, why you ever need to modify wc? Just load wc inside your
> json/xml/etc writer, replacing its printf at the ld-elf.so level.
You can't get structured output from printf() because printf() takes
unstructured input. It's a string with some v
On 22 Mar 2015, at 22:01, Craig Rodrigues wrote:
>
>> Volatile is not the solution, it is completely orthogonal. The correct
>> way would be to use unsigned integers, for which wrapping is defined,
>> then convert those back and forth when presenting the results to the
>> user.
>>
>
> OK, conv
On 28 Mar 2015, at 13:54, Julian Elischer wrote:
>
> the point is that clang will do this anywhere it can, because it isn't taking
> into account the
> side effects, just the speed of the commands themselves.
This is also something that is not going to decrease. Clang now enables the
SLP vect
On 1 Apr 2015, at 05:03, Rui Paulo wrote:
>
> That is expected. WITH_PKG=devel is a make(1) option that only affects ports
> (non-binary pkgs).
Are you sure? I have it in make.conf on one of my systems where I never build
ports manually (and don't even have a ports tree installed) and there
On 23 Apr 2015, at 00:12, Craig Rodrigues wrote:
>
> While not as smooth as clicking a merge button in GitHub,
> this is a valid way to accept patches submitted via GitHub pull requests,
> and integrate them in our FreeBSD Subversion repo.
The merge button on GitHub does the wrong thing anyway (
On 11 May 2015, at 17:27, Jos Backus wrote:
>
> I didn't miss anything. My point is that debating to update one piece of
> obsolete software with another is silly, and that FreeBSD should try to
> move forward in this area. But that's hard, as your response indicates.
Steve is correct, and you a
On 13 May 2015, at 09:03, John-Mark Gurney wrote:
>
> Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
>>
>> In message <20150512032307.gp37...@funkthat.com>, John-Mark Gurney writes:
>>
>>> Also, you'd probably see even better performance by increasing the
>>>
On 13 May 2015, at 17:05, Pedro Giffuni wrote:
>
> Hello;
>
> I am looking at the cdefs in other BSDs hoping to avoid adopting the
> same definitions with incompatible names and I noticed NetBSD is using
> a new __builtin_unreachable (void) function from gcc 4.6:
>
> https://gcc.gnu.org/onlined
On 14 May 2015, at 01:02, Baptiste Daroussin wrote:
>
> - it is partially CDDL partially BSD license.
We currently have a WITHOUT_CDDL knob that some people use. If we don’t build
the CDDL parts, what will break?
David
___
freebsd-current@freebsd.o
On 14 May 2015, at 09:59, Baptiste Daroussin wrote:
>
> On Thu, May 14, 2015 at 09:55:19AM +0100, David Chisnall wrote:
>> On 14 May 2015, at 01:02, Baptiste Daroussin wrote:
>>>
>>> - it is partially CDDL partially BSD license.
>>
>> We currently hav
On 14 May 2015, at 10:24, Baptiste Daroussin wrote:
>
> On Thu, May 14, 2015 at 10:13:18AM +0100, David Chisnall wrote:
>> On 14 May 2015, at 09:59, Baptiste Daroussin wrote:
>>>
>>> On Thu, May 14, 2015 at 09:55:19AM +0100, David Chisnall wrote:
>>&
On 9 Jul 2015, at 10:17, NGie Cooper wrote:
>
> I agree that this is less applicable for FreeBSD than NetBSD. Please
> keep in mind that contrib/netbsd-tests came from NetBSD, not FreeBSD.
> Peter Holm and I tried our best to vet out the issues with the test
> suite before integrating it in, but
On 27 Jul 2015, at 20:49, Slawa Olhovchenkov wrote:
>
> No idea.
> May be someone know about current status swap in file on UFS.
> This is work for me some time ago.
It sounds as if the swap was working (as the build took a long time, it didn’t
run out of memory). My guess would be that, befor
On 28 Jul 2015, at 18:23, Adrian Chadd wrote:
>
> (What would be nice is having kqueue know about conditionals, so we
> can sleep on a cond as well as a kqueue fd+queue, but I can't have
> everything I want..)
I recently came across a need to do something like this. Being able to add
condvar /
On 28 Jul 2015, at 18:33, Adrian Chadd wrote:
>
> Windows has had this for years. It makes async network programming
> with thread worker queues significantly less abusive.
Can you do the same with Solaris completion ports? It might be a good source
of inspiration for a good API if so.
David
On 20 Aug 2015, at 17:44, Justin Hibbits wrote:
>
> There was a working group at BSDCan this year on power management, and
> what we need to / can do to bring it up to par with the modern world.
> Unfortunately, I haven't had any time lately to work on it, but you
> can read the notes at
> https:
On 17 Sep 2015, at 10:55, Lundberg, Johannes
wrote:
>
> Looking at those pages it seems like development has basically been
> standing still for the last couple of years.
I’m not sure why you’d have that impression. The Haswell entry on that page
links here:
https://wiki.freebsd.org/Graphics
On 17 Sep 2015, at 11:31, Lundberg, Johannes
wrote:
>
> Anyway, I wish the foundation would support the graphics team by sponsoring
> this development…
The Foundation did fund a lot of this work, and likely will again. The problem
is not willingness of the Foundation to fund it, nor availabi
On 17 Sep 2015, at 14:41, Lundberg, Johannes
wrote:
>
> However, the problem now is not the driver right? But the whole graphics
> stack which has to be rewritten to work with new generation graphics like
> KMS, Wayland, etc?
There are lots of different components here that you’re conflating:
On 23 Oct 2015, at 17:40, Ian Lepore wrote:
>
> Don't cc me. I looked at the in-tree dtc code once and decided it's
> too flawed to try to maintain, and it supports only a subset of the
> full dts syntax. That's why we switched back to using the gnu dtc for
> buildkernel. But I just discovered
On 24 Oct 2015, at 11:07, David Chisnall wrote:
>
> On 23 Oct 2015, at 17:40, Ian Lepore wrote:
>>
>> Don't cc me. I looked at the in-tree dtc code once and decided it's
>> too flawed to try to maintain, and it supports only a subset of the
>> full dts
On 25 Oct 2015, at 00:07, George Abdelmalik wrote:
>
> You've beaten me to it with the fix before I could lodge the bug report :)
>
> In your repo I've seen that the mmap(2) call now takes the MAP_PRIVATE flag. I
> applied that change locally to my source tree and that has fixed the problem.
> I
On 1 Nov 2015, at 21:30, Baptiste Daroussin wrote:
>
> All issues reported has been fixed, except if more issues are reported, this
> will be merged into head next saturday: November 7th
That’s really excellent news! Thanks for doing this. Are there any good
potential sources for the regex st
On 5 Nov 2015, at 16:55, Mateusz Guzik wrote:
>
>> Will that cause problems, especially for code inside a loop
>> where the compiler may decide to shuffle things around?
>>
>
> Lock value is volatile, so the compiler should not screw us up.
Note: volatile means do not reorder loads/stores *to
On 8 Nov 2015, at 02:32, Ulrich Spörlein wrote:
>
>
> Git commit hashes *might* change in the future. I really don't
> see how this is a big deal anyway. It happened once and I'm trying to
> have it never happen again. But why are people afraid of this
> happening? Every "official" git commit i
On 15 Nov 2015, at 19:12, Simon J. Gerraty wrote:
>
> Garrett Cooper wrote:
>> We lack a [dtd/json] spec for tools, so programming for xo'ification
>> doesn't seems like the best idea in the world to me from a end-user
>> sysadmin/developer perspective.
>
> A dtd etc is good for sure, and we (J
On 16 Nov 2015, at 17:09, Elizabeth Myers wrote:
>
> It seems to boil down to the golden rule: he who has the gold, makes the
> rules. Juniper wanted it, they're a non-trivial donor to the FreeBSD
> foundation and employ many devs, so they got their way.
>
> That's all there is to it.
I think t
On 16 Nov 2015, at 21:04, Garance A Drosehn wrote:
>
> First let me say that I wish I had more time to contribute to the project,
> but I seem to be caught in variety of long drawn-out hassles in real-life.
> Otherwise I would already know the answer to this question:
>
> Is there some specifica
The gdb in the base system doesn’t support DWARF4. Use gdb791 or lldb-devel
from ports (I believe gdb791 is probably a better bet on ARM, currently).
David
> On 8 Dec 2015, at 09:02, Ray Newman wrote:
>
> Hi,
>
> Compiled using gcc (FreeBSD Ports Collection) 4.8.5 on arm (Raspberry Pi -
> s
On 31 Dec 2015, at 11:59, Yuri wrote:
>
> Would it be the right way of solving the problem if I submitted an update of
> contrib/gcc and contrib/gcclibs from the gcc-5.3.0 tree?
No.
> Any pitfalls with this?
The newer versions of GCC are GPLv3 and so are unacceptable for the FreeBSD
base sy
On 21 Jan 2016, at 16:02, Ed Maste wrote:
>
> I found that lang/polyml uses PTHREAD_STACK_MIN for a trivial signal
> handler thread it creates[1]. They found it was too small and
> implemented a 4K minimum bound to fix polyml on FreeBSD[2]. Even if
> this isn't really the intended use of PTHREAD_
On 23 Jan 2016, at 08:58, Maxim Sobolev wrote:
>
> For what it's worth, I agree with David. This looks like definite misuse of
> the constant. If app X requires min size of stack of Y, it's fullish of it if
> to expect our PTHREAD_STACK_MIN somehow accommodate that. It should be really
> using
On 28 Jan 2016, at 17:45, NGie Cooper wrote:
>
> Also, consider that you're going to be allowing upgrades from older RELEASE
> versions of the OS which might be using a fixed copy of pkgng -- how are you
> going to support that?
I believe that the plan is to promote the pkg tool somewhat close
On 8 Mar 2016, at 13:19, Miroslav Lachman <000.f...@quip.cz> wrote:
>
> It would be really nice if somebody can bring better support for FreeBSD's
> SMB/CIFS mount. Maybe through FreeBSD Foundation projects.
Indeed. Both Solaris and OS X have SMB2 implementations. If anyone is
interested in w
On 8 Mar 2016, at 15:14, Slawa Olhovchenkov wrote:
>
> Yes, I undertund this. But what profit of this? Addtional size is
> small, many small packages is bad. We already have expirense with
> spliting Xorg to many small packages -- no profit of this.
The X.org case is similar, but not quite the s
On 8 Mar 2016, at 17:59, Kurt Jaeger wrote:
>
>> Indeed. Both Solaris and OS X have SMB2 implementations. If
>> anyone is interested in working on this, then the Apple implementation
>> may provide some inspiration:
>>
>> http://www.opensource.apple.com/source/smb/
>
> Is there any way to dow
Hi,
I’d slightly question the assertion that Mach-O is a well-designed format. For
example, it has a hard limit of 16 section types, doesn’t support COMDATs and
so on. OS X uses a load of magic section names to work around these
limitations.
Note that a Mach-O image activator is relatively e
On 24 Mar 2016, at 12:05, mokhi wrote:
>
> Hi.
>
> I'm agreed with point you told about improvements we can do for fat
> format (or more).
> And I'm ready to do them (with your helps, sure :D).
>
> But we need short steps and more of them (a local proverb :D) IMO.
> If we completely do this ima
On 24 Mar 2016, at 13:42, Damjan Jovanovic wrote:
>
> ELF itself is a disaster. Symbol lookup in ELF is process scoped, not
> library scoped like Windows's PE and Mac's Mach-O, so same named
> symbols from different libraries in the same process (loaded through
> any number of levels of indirecti
On 5 Apr 2016, at 10:07, Gergely Czuczy wrote:
>
> Also, quite often entries from the base system are changed manually, think of
> root's/toor's password. Are such cases going to be dealt with properly
> between upgrades, including self-built-and-packaged base systems? Currently
> it can be a
On 19 Apr 2016, at 08:44, Julian Elischer wrote:
>
>> All this can be done by meta-packages which depend on larger package groups.
> Currently Metapackage is a way to make 10 packages look like 11 packages.
> The framework needs to understand to hide the 10 internal packages if they
> are part
On 20 Apr 2016, at 06:06, Julian Elischer wrote:
>
> my problem with 400 packages is that is is hard to decide what you are
> actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453?
> you have no way to tell exactly what you have without comparing all the
> packages to a known list.
On 20 Apr 2016, at 15:53, Paul Mather wrote:
>
> Arguably, a packaged base will make it easier to help people, because it
> makes more explicit the dependencies of different parts of the system. It's
> been my experience that the interactions and impact of the various
> /etc/src.conf settings
On 21 Apr 2016, at 21:48, Dan Partelly wrote:
>
> Yes, you are right it misses the media change handler in devd.conf.
> maybe it should bementioned somewhere in a man page if it is not
> already there. Thanks for the pointer.
>
> Anyway, if I would have written the system, what I would have do
On 25 Apr 2016, at 06:48, Gerrit Kühn wrote:
>
>> Yes. It will be replaced by 'pkg upgrade' -- as far as I know, that's
>> the plan for 11.0-RELEASE.
>
> Hm... I never had any troubles with freebsd-update, it always "just
> worked" for me. OTOH, I remember having several issues with pkg, requir
If this paper is the one that I think it is, then I was one of the reviewers.
Their attack is neat, but it depends quite a lot on being able to
deterministically trigger deduplication. Their proof-of-concept exploit was on
Windows (and JavaScript attack was really fun) and I’m not convinced th
On 13 Jul 2016, at 10:17, O. Hartmann wrote:
>
> A CD is still a used media, but it starts getting squeezy on it as certain
> software starts to grow - as CLANG/LLVM does. Maybe it is time to have also
> CDs
> as "miniboot" and DVDs for a more complete installation media?
I completely agree. I
On 20 Jul 2016, at 05:48, Warner Losh wrote:
>
> My concern with this is overlay support. Overlay support for "shields" or
> "badges" is going into upstream GPL dtc shortly. The patches have been
> kicking around for a while and are almost ready to go in. We need this feature
> and I'd planned on
On 20 Jul 2016, at 16:46, Warner Losh wrote:
>
> I've been trying to get the final spec for it. Right now it's a
> disorganized series
> of patches, some of which have been merge some that haven't. I'll send you a
> copy when I can find something better than "here's the code."
Thanks. From the
On 22 Jul 2016, at 03:40, Warner Losh wrote:
>
> On Wed, Jul 20, 2016 at 9:51 AM, David Chisnall wrote:
>> On 20 Jul 2016, at 16:46, Warner Losh wrote:
>>>
>>> I've been trying to get the final spec for it. Right now it's a
>>> disorganized ser
On 23 Jul 2016, at 05:16, Warner Losh wrote:
>
> On Fri, Jul 22, 2016 at 1:03 AM, David Chisnall wrote:
>> On 22 Jul 2016, at 03:40, Warner Losh wrote:
>>>
>>> On Wed, Jul 20, 2016 at 9:51 AM, David Chisnall
>>> wrote:
>>>> On 20 Jul 20
Thanks,
On 19 Jul 2016, at 20:49, Emmanuel Vadot wrote:
>
>
> Hello,
>
> I've just tried bsd dtc on all arm dts that we have.
> It doesn't seems to handle multiple include directories.
> Here is how to reproduce :
>
> $ export SRCROOT=/path/to/fbsd/src
> $ export MACHINE=arm
> $ cd $SRCROOT/s
On 27 Jul 2016, at 23:55, Shawn Webb wrote:
>
> I'm interested in getting SafeStack working in FreeBSD base. Below is a
> link to a simplistic (maybe too simplistic?) patch to enable SafeStack.
> The patch applies against HardenedBSD's hardened/current/master branch.
> Given how simple the patch
On 12 Aug 2016, at 00:18, Lundberg, Johannes
wrote:
>
> Currently by default evdev create /dev/input/eventX devices with 600
> permission. These need to be accessible for non-root users. What is the
> best solution? Should we create a "input" group similar to "video" group is
> being used for ri
On 24 Jul 2016, at 12:42, David Chisnall wrote:
>
> I’ve now fixed both of these in the version here:
>
> https://github.com/davidchisnall/dtc
Andy filed a number of issues on GitHub, which are now all fixed. In
particular, /include/ should now work everywhere and /delete-nod
On 3 Nov 2016, at 19:34, Rodney W. Grimes
wrote:
>
> Depressing fact: The i18n directory alone is larger than
> a full 386BSD 0.1+sources+patchkit install.
Is the depressing thing here that even something as recent as 386BSD 0.1
assumed that ASCII was enough for the whole world?
David
smi
On 23 Nov 2016, at 18:11, A. Wilcox wrote:
>
> Or you could just, I don't know, email the diff as a patch using git
> send-email like normal people instead of using GitHub's walled garden.
> That way, people without GitHub accounts can still comment on it.
GitHub pull requests are branches in th
On 5 Dec 2016, at 19:31, Kevin P. Neal wrote:
>
>> Is there any emulator like linuxator to run Mac OS X binaries, or
>> is ther any licensing problem?
>
> It may be possible to make an emulator for Darwin (the OS that Mac OS sits
> on top of), but an emulator for Mac OS would probably require a
On 13 Jan 2017, at 01:00, Ernie Luzar wrote:
>
> VT should have had better testing before becoming the default in 11.0.
The choice was VT or no acceleration in X11, because all of the new DRI drivers
depend on KMS, which requires VT. We only got VT in a useable state (and
therefore useable ac
On 20 Jan 2017, at 14:06, Christian Schwarz wrote:
>
> I know clang is no longer built and installed as part of buildworld in
> the FreeBSDDesktop repo,
> but why isn't libstd++ present?
>
> …
>
> clang39 # now run clang, won't work, see below
> Shared object "libc++.so.1" not found, require
On 16 May 2017, at 07:42, Johannes Lundberg wrote:
>
> Gonna answer myself here. Think I found a way.
>
> Add CFLAGS=-fcolor-diagnostics to env or /etc/src.conf
> Do clean build, that is no -DNO_CLEAN,KERNFAST, etc.
>
> Makes it a lot easier to find the errors in a 16 threads build output...
>
On 7 Jun 2017, at 10:33, blubee blubeeme wrote:
>
> Hi
>
> I'm sure I was reading yesterday on a different machine about the linker
> flag -ld which has something to do with gnu dlopen and how it's ok to
> remove those from your Makefile since FreeBSD handles dlopen and a few
> other things from
On 9 Jul 2017, at 14:25, Stefan Ehmann wrote:
>
> Don't why the structs are not compatible, maybe because:
> "The process ID cmcred_pid should not be looked up (such as via the
> KERN_PROC_PID sysctl) for making security decisions. The sending process
> could have exited and its process ID alre
On 23 Jul 2017, at 23:54, Mark Millard wrote:
>
>>c++ -isystem ${OUTDIR}/tmp/usr/include/c++/v1 -std=c++11 -nostdinc++
>> -isystem ${OUTDIR}/tmp/usr/include -L${OUTDIR}/tmp/usr/lib
>> -B${OUTDIR}/tmp/usr/lib --sysroot=${OUTDIR}/tmp -B${OUTDIR}/tmp/usr/bin -O
>> -pipe -G0 -EB -mabi=32 -ms
On 1 Aug 2017, at 12:36, Michael Zhilin wrote:
>
> Hi Ed, freebsd-current,
>
> I want to add C++ demangling into sysutils/pstack. In man pages I've found
> eltfc_demangle, exact what I need. This function belongs to libelftc. "make
> installworld" installs man pages and include files, but there
On 19 Aug 2017, at 17:54, Cy Schubert wrote:
>
>> 3. should total swap be 1x 2x or some other multiple of RAM these days?
>
> Depends. If you're running some kind of database server or OLTP
> application. Some vendors recommend no swap whatsoever while others
> recommend some. What does your a
On 25 Aug 2017, at 07:32, Mark Millard wrote:
>
> As I remember _Static_assert is from C11, not
> the older C99.
In pre-C11 dialects of C, _Static_assert is an identifier reserved for the
implementation. sys/cdefs.h defines it to generate a zero-length array if the
condition is true or a nega
On 3 Sep 2017, at 06:31, Cy Schubert wrote:
>
> Thanks for the heads up Johannes. I currently have three machines that each
> run ATI r128, mach64 and the last one an mga card. I normally use my i945
> and i915 laptops (mostly the former) but on occasion I may fire up X on one
> of the other t
On 22 Nov 2011, at 00:21, Michael Butler wrote:
> #0 0x283eb243 in fprintf () from /lib/libc.so.7
This looks suspicious. uselocale() does not call fprintf(). In fact, nothing
in xlocale.c does - fprintf() accesses the current locale, so calling it from
anywhere in the setlocale() path is lik
It's entirely possible - please can you compile libc with debug symbols? The
back trace isn't very informative...
David
On 22 Nov 2011, at 00:21, Michael Butler wrote:
> VLC (multimedia/vlc) on my -current now crashes leaving a trace like this ..
>
> imb@toshi:/home/imb> gdb `which vlc` vlc.c
On 22 Nov 2011, at 14:00, Michael Butler wrote:
> On 11/22/11 08:52, David Chisnall wrote:
>> Please can you try this patch?
...
> That works :-)
>
> Thanks!
Fixed in head (r227818), thanks for the report!
David
___
freebsd-c
Hi,
I've just imported libc++[1] and libcxxrt[2] to head. libc++ is UUIC licensed,
libcxxrt is 2-clause BSDL. The former implements the C++ standard template
library, and provides all of the programmer-visible parts. The latter provides
an implementation of the ARM and Itanium ABI specificat
On 26 Nov 2011, at 23:09, Niclas Zeising wrote:
> This is great news! Thank you very much for undertaking this work. Just
> a question, is there a wiki page with these instructions, or a wiki page
> related to this work where these instructions can be added? If they're
> not on the wiki, I can d
On 27 Nov 2011, at 15:26, O. Hartmann wrote:
> Why is the knob
> WITH_LIBCPLUSPLUS=yes
> located in /etc/make.conf and not in /etc/src.conf?
Sorry, it is in src.conf, I was thinking about enabling clang. Or possibly not
thinking at all. It's Sunday, so thinking is optional...
David___
On 30 Dec 2011, at 13:06, Dimitry Andric wrote:
> sys/gnu/fs/xfs/xfs_dir2_block.c:1149:17: warning: array index of '1' indexes
> past the end of an array (that contains 1 element) [-Warray-bounds]
I recall some discussion of this warning on the clang list a few months ago,
and I believe that i
On 5 Sep 2012, at 10:31, Dimitry Andric wrote:
> These are just the default FreeBSD optimization flags for building
> clang, which are probably used by the majority of users out there.
> This is the case that I was interested in particularly. The
> -fno-strict-aliasing is not really my ch
On 6 Sep 2012, at 09:43, Roman Divacky wrote:
> Was this compiled as amd64 or i386? Also, can you send me the test case?
> So that we can explore the difference. The working theory now is SSE vs FPU
> mathematics, but it would be nice to see the testcase.
There may also be a difference in whether
I'd add one more thing that needs fixing:
Clang should default to c89 mode when invoked as cc. I had a patch to do this,
but I seem to have misplaced it. I'll try to find or rewrite it in the next
couple of days.
A lot of the ports failures I saw were due to ports using cc as the default C
1 - 100 of 317 matches
Mail list logo
