Re: HEADS-UP: OpenSSL 1.1.1 in 12.0
On 10/10/18 8:04 am, Glen Barber wrote: > OpenSSL has been updated to version 1.1.1 as of r339270. > > It is important to rebuild third-party packages before running: > > # make -C /usr/src delete-old && make -C /usr/src delete-old-libs > > Thank you for your patience while this work was in progress, and thank > you to all involved for their hard work in getting things ready for this > update. > > Glen > I have a host running 11-stable and use bhyve to run current for testing, zfs says the volume for this bhyve was created 12/2016 Within the bhyve host - base and poudriere jails are built to r339301 Installed ports have been manually re-built in ports tree poudriere runs and builds ports OK but at the end it fails to create pkg repo with failing to load cert. This is the cert I have been using for my pkg repos for some years, do these pkg certs need to be updated after this update? It does work if I disable the signing key. [00:01:43] Creating pkg repository Creating repository in /tmp/packages: 100% Packing files for repository: 0% pkg-static: can't load key from /tmp/repo.key Packing files for repository: 100% [00:01:44] Cleaning up [00:01:44] Unmounting file systems -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: debugging a run of poudriere-bulk
On 3/10/18 9:11 pm, Matthias Apitz wrote: > > Hello, > > > I'm trying to nail down PR 231532 of a port which fails to build in > poudriere. In the last phase of the ports build, while creating the pkg > of the built port with pkg-static, this crashes: > > # tail > /usr/local/poudriere/data/logs/bulk/freebsd-r338641-ports-20180920/2018-10-03_11h32m17s/logs/kde-workspace-kde4-4.11.22_26.log > Child process pid=85086 terminated abnormally: Segmentation fault > *** Error code 1 > > Stop. > make: stopped in /usr/ports/x11/kde-workspace-kde4 > =>> Cleaning up wrkdir > > # grep 85086 /var/log/messages > Oct 3 11:44:01 jet kernel: pid 85086 (pkg-static), uid 65534: exited on > signal 11 > > > How can I enter the jail interactively in the moment after the crash to rerun > and > debug pkg-static? Using poudriere testport -j -p -i -o will drop you into the jail after the build stops, you then rerun make manually, check build logs... Logging out will then continue on and clean up the jail. You can also use -I instead of -i and it leaves the jail in place so you can manually connect to and stop the jail. Note that poudriere uses a clean jail with only deps listed for the port, you can add extra BUILD_DEPENDS to get extra ports (gdb valgrind) installed with the test build. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory
On 28/9/18 7:31 am, Rebecca Cran wrote: > I'm running 12.0-ALPHA5 on a laptop which has 32GB RAM and 2GB swap. > I've found it running out of memory when building ports via synth: I > think I've also seen it when running a buildworld. Johannes on > FreeBSDDesktop suggested it might be related to ZFS, and setting > vfs.zfs.arc_max to 8GB *does* appear to have resolved the problem. > > > Shortly after running out of memory (with |"swap_pager_getswapspace(32): > failed" messages)|, the first few lines of 'top' were: I believe the default arc settings are wrong, arc_max defaults to 1G less than ram, with arc being wired this collides with other ram that may be wired, by default the kernel is allowed to wire 30% of ram which is in addition of any arc allocation. So arc should remain less than 70% of ram. I submitted bug 229764 with this. Also consider any bhyve usage, the -S option will wire guest ram, which one of the bhyve tools enables as default. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sharing compiled builds between multiple 12-CURRENT boxes.
On 19/8/18 5:31 pm, Matthew Seaman wrote: > On 19/08/2018 01:55, Shane Ambler wrote: >>> I run 12-CURRENT on few machines, some more powerful that other (all >>> of them x86_64, march varies). > >> You can use freebsd-update by setting up your own update server >> https://www.freebsd.org/doc/en/articles/freebsd-update-server > > freebsd-upgrade(8) only works for releases, and not 12-CURRENT as the OP > specified. While I haven't used it to make releases from current, I would be surprised if it doesn't work for current. The default config for release.sh is to checkout and build HEAD, so without setup, current would be used when building for the update server. I do expect an incremental numbering scheme would need to be used to differentiate each build, patch level builds should fit that. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sharing compiled builds between multiple 12-CURRENT boxes.
On 19/8/18 8:04 am, Dhananjay Balan wrote: > Hi, > > I run 12-CURRENT on few machines, some more powerful that other (all > of them x86_64, march varies). > > Is there is a way to avoid building CURRENT on all machines? Rather > than building everywhere, can I just build it on the big server that I > have and copy and update my laptop? You can use freebsd-update by setting up your own update server https://www.freebsd.org/doc/en/articles/freebsd-update-server This can then be paired with poudriere for pkgs - see handbook 4.6 Also be careful setting the CPUTYPE, it has to be the lowest denominator so that no cpu features are used on a machine without them. This is more important with poudriere as many ports will configure to the current cpu features, I think base always targets the lowest cpu specs. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD elf_machine_id
On 12/8/18 11:32 pm, blubee blubeeme wrote: > On Sun, Aug 12, 2018 at 9:59 PM blubee blubeeme wrote: > >> >> >> On Sun, Aug 12, 2018 at 7:43 PM Dimitry Andric wrote: >> >>> On 12 Aug 2018, at 13:21, blubee blubeeme wrote: >>>> >>>> What's the elf_machine_id for FreeBSD amd64 systems? >>>> >>>> How can I find this info? >>> >>> There isn't any FreeBSD-specific machine ID, just a machine ID for >>> x86-64 (aka amd64) in general: >>> >>> $ grep x86-64 /usr/include/sys/elf_common.h >>> #define EM_X86_64 62 /* Advanced Micro Devices x86-64 */ >>> #define EM_AMD64EM_X86_64 /* Advanced Micro Devices x86-64 >>> (compat) */ >>> >>> -Dimitry >>> >>> Thank you for the clarification. >> >> I think in this case I was looking for 62. >> >> Best, >> Owen >> > Actually I had another quick question along these lines. > > if x86_64 is already defined should I bother changing those to amd64 or > just use x86_64 and make FreeBSD modifications where Linux specifics are > defined? As I understand it, AMD designed the 64bit extensions and early adopters referred to it as amd64, then when Intel adopted it they needed a more generic term, so x86_64 was started, now usually both __X86_64__ and __amd64__ are compiler defined based on the target. So it may depend on why you are asking for the elf_machine_id. For general C/C++ programming - #if defined(__x86_64__) // 64bit code #else // 32 bit code #endif or to be safe you can check all variations #if defined(__X86_64__) || defined(__amd64__) For freebsd specific changes - #if defined(__FreeBSD__) #include #if __FreeBSD_version < 1101000 // version specific see porters handbook for version list #endif #endif If you want to see all the compiler defined environment macros run clang++ -dM -E -x c /dev/null or clang++ -dM -E -x c++ /dev/null or for a 32bit env clang++ -dM -E -m32 -x c++ /dev/null works for clang and gcc. I believe when multiple variations exist, the __xx__ macros are most common eg use __x86_64__ not __x86_64 -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Changes to sysctl values
I use devel/py-sysctl in some scripts to get values, using a recent
12-current (r336728) I see at least two values that get a different
value type than on 11-stable. Same version of python and port.
I have 12-current running in a bhyve on an 11-stable host.
Is there a recent change to sysctl calls that would cause this?
or is this bhyve related?
On 11-stable I get long int values that I expect
Python 2.7.15 (default, Jun 8 2018, 08:54:38)
[GCC 4.2.1 Compatible FreeBSD Clang 6.0.0 (tags/RELEASE_600/final
326565)] on freebsd11
Type "help", "copyright", "credits" or "license" for more information.
>>> sysctl.filter('vm.stats.vm.v_wire_count')[0].value
1061486L
>>> sysctl.filter('vm.stats.vm.v_free_count')[0].value
77217L
On 12-current I get the same sysctls as a bytearray
Python 2.7.15 (default, Jul 26 2018, 10:32:28)
[GCC 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final
335540)] on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> sysctl.filter('vm.stats.vm.v_wire_count')[0].value
bytearray(b"\'R\x12\x00")
>>> sysctl.filter('vm.stats.vm.v_free_count')[0].value
bytearray(b'\x06\\\x08\x00')
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: numa involved in instability and swap usage despite RAM free?
On 27/06/2018 07:52, Steve Kargl wrote: > On Tue, Jun 26, 2018 at 02:39:27PM -0700, Adrian Chadd wrote: >> On Mon, 25 Jun 2018 at 11:23, Steve Kargl >> wrote: >>> >>> On Sun, Jun 24, 2018 at 12:03:29PM +0200, Alexander Leidinger wrote: >>>> >>>> I don't have hard evidence, but there is enough "smell" to open up a >>>> discussion... >>>> >>>> Short: >>>> Can it be that enabling numa in the kernel is the reason why some >>>> people see instability with zfs and usage of swap while a lot of free >>>> RAM is available? >>> >>> Interesting observation. I do have NUMA in my kernel, and swap >>> seems to be used instead of recycling freeing inactive memory. >>> Top shows >>> >>> Mem: 506M Active, 27G Inact, 98M Laundry, 2735M Wired, 1474M Buf, 1536M Free >>> Swap: 16G Total, 120M Used, 16G Free >From someone that has had memory issues since 10.1 (bug 194654), I have recently realised something that seems to make some sense to me. The arc_max setting is a limit of zfs arc and this ram gets wired to prevent it swapping, this makes sense. The vm.max_wired is a value that I had thought was ignored but now I see that these are two values of wired memory which are not connected. max_wired appears to default to 30% of kmem_size. Both of these values are added together to be reported in vm.stats.vm.v_wire_count which is the wired value shown by top. This appears to be the reason that I can see 9G wired when max_wired is at 5G The implications of this is that together (arc_max + max_wired) can be set to more than the physical installed ram. I can verify that with 8G installed and the two values add up to more than 7G you get no choice but a hard reset. Since upgrading to 16G I have been more vigilant and not allowed more than 10G to be wired so haven't had that problem in a year and a half. With the default arc_max usually set to ram minus 1G and max_wired at 5G it is easy to see that the current defaults are dangerous. I have not seen max_wired mentioned in relation to zfs but it seems that it should be considered when setting arc_max to prevent over wiring ram. Close to three weeks ago I applied review D7538 to my everyday desktop running stable/11. Until a few days ago I had no swap usage which is now at 9M. In the last few years of monitoring wired usage to try and find a solution I have not seen less than 1G of swap usage after an hour of uptime. If nothing else D7538 makes arc more willing to be released. -- FreeBSD - the place to B...Storing Data Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ``make buildkernel'' fails when /usr/obj is empty
On 01/06/2018 03:41, Warner Losh wrote: > On Thu, May 31, 2018 at 11:47 AM, Dimitry Andric wrote: > >> On 31 May 2018, at 18:04, Benjamin Kaduk wrote: >>> >>> On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn wrote: >>>> On Thu, 31 May 2018 09:52:22 +0200 >>>> Gary Jennejohn wrote: >>>> >>>>> There's something totally screwy about trying to build a kernel when >>>>> /usr/obj is not populated. >>>>> >>>>> I ran ``make clean'' in /usr/src and then ``make buildkernel''. This >>>>> fails with >>>>> make[2]: "/usr/src/sys/conf/kern.pre.mk" line 125: amd64 kernel >>>>> requires linker ifunc support >>>>> >>>>> This is total BS because >>>>> >>>>> /usr/bin/ld --version >>>>> LLD 6.0.0 (FreeBSD 326565-122) (compatible with GNU linkers) >>>>> >>>>> which is exactly what bsd.linker.mk is looking for to set ifunc. >>>>> >>>>> If I do this: >>>>> >>>>> mkdir -p /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin >>>>> cp /usr/bin/ld /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin >>>>> >>>>> the buildkernel then succeeds. >>>>> >>>>> Considering that (reformatted output from make) >>>>> >>>>> PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin: >>>>> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin: >>>>> /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin: >>>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/sbin: >>>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin: >>>>> /sbin:/bin:/usr/sbin:/usr/bin >>>>> >>>>> it seems like /usr/bin/ld should be found by bsd.linker.mk and no >>>>> error should be reported. >>>>> >>>> >>>> OK, it seems that ``make clean'' does not remove the contents of >>>> /usr/obj/usr/src/amd64.amd64/tmp/legacy. If I delete everything >>>> under /usr/obj then ``make buildkernel'' works. >>>> >>>> Still, it seems pretty strange to me to make building a kernel >>>> depend on some random junk which is left laying around under >>>> /usr/obj. >>> >>> Whatever happened to the "run buildworld or kernel-toolchain before >>> buildkernel" requirement? >> >> That is still a requirement, yes. Otherwise, you might have outdated >> toolchain components are in your /usr/obj. >> > > Usually you can get away without doing that, and now that clang is the > toolchain that's rebuilt (and that's not fast) people try to get away with > it more and more... There is WITH_SYSTEM_COMPILER to not bootstrap if possible. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How to find CPU microcode version ?
On 18/02/2018 21:11, Kurt Jaeger wrote: > Hi! > Around the 14th, processes started to be killed for out of swapspace, > even if the box had almost no load at all. > > pid 1056 (mutt), uid 104, was killed: out of swap space > pid 536 (devd), uid 0, was killed: out of swap space > pid 15093 (exim), uid 26, was killed: out of swap space > pid 91868 (mutt), uid 104, was killed: out of swap space > pid 1086 (sshd), uid 104, was killed: out of swap space > > Reboot of the box and waiting a few hours and the problem re-occured. > > The box has 32 GB RAM and 34 GB swap, which never was utilized > beyond a few hundred MBs. One situation that can cause out of swap errors is large amounts of wired ram. Wired ram is memory that can't be swapped out. When you get around 80 or 90% of physical ram wired you start seeing those errors. You can see the amount of wired displayed in top or sysctl vm.stats.vm.v_wire_count then times that by hw.pagesize There is a vm.max_wired but it doesn't appear to be an enforced limit. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How to avoid building of all llvm/clang-related stuff on recent CURRENT?
On 30/01/2018 09:33, Dimitry Andric wrote: > On 29 Jan 2018, at 20:56, Lev Serebryakov wrote: >> >> I have these lines in my nanobsd config: >> >> WITHOUT_CROSS_COMPILER=yes >> WITH_SYSTEM_COMPILER=yes >> WITHOUT_CLANG=yes >> WITHOUT_CLANG_EXTRAS=yes >> WITHOUT_CLANG_BOOTSTRAP=yes >> WITHOUT_BINUTILS=yes >> WITHOUT_BINUTILS_BOOTSTRAP=yes >> WITHOUT_ELFTOOLCHAIN=yes >> WITHOUT_ELFTOOLCHAIN_TOOLS=yes >> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=yes >> WITHOUT_LLD=yes >> XCC=/usr/bin/cc >> XCXX=/usr/bin/c++ >> XCPP=/usr/bin/cpp >> XAS=/usr/bin/as >> XAR=/usr/bin/ar >> XLD=/usr/bin/ld >> XNM=/usr/bin/nm >> XOBJDUMP=/usr/bin/objdump >> XRANLIB=/usr/bin/ranlib >> XSTRINGS=/usr/bin/strings >> XSTRIPBIN=/usr/bin/strip >> COMPILER_TYPE=clang >> >> And it worked some time ago. But now "buildworld" with these setting >> build libllvm and other cross-tools anyway. >> >> Host and target are the same (amd64) and nanobsd sources are the same >> as sources used to build host system. >> >> How to disable llvm & clang build completely? > > I think you also need WITHOUT_LLD_BOOTSTRAP now, if you are building for > amd64 or aarch64. You may also (soon) need WITHOUT_LLD_IS_LD, there are plans to enable LLD by default. Looking at man src.conf on current, WITHOUT_CROSS_COMPILER enforces - WITHOUT_BINUTILS_BOOTSTRAP WITHOUT_CLANG_BOOTSTRAP WITHOUT_ELFTOOLCHAIN_BOOTSTRAP WITHOUT_GCC_BOOTSTRAP I think WITHOUT_LLD_BOOTSTRAP might belong in that list. There is also a WITHOUT_TOOLCHAIN which enforces - WITHOUT_BINUTILS WITHOUT_CLANG WITHOUT_CLANG_EXTRAS WITHOUT_CLANG_FULL WITHOUT_GCC WITHOUT_GDB WITHOUT_INCLUDES WITHOUT_LLD WITHOUT_LLDB which WITHOUT_LLD_IS_LD might also belong to, there is no mention of other options enforcing it. Shouldn't nanobsd disable these by default? -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel names
On 14/12/2017 16:21, Allan Jude wrote: > On 12/14/2017 00:47, blubee blubeeme wrote: >> When you boot into FreeBSD and you can select kernels, there's only 2 >> options: >> default and kernel.old >> >> Is there a way to have better output and support multiple kernels without >> having to login to the system and running uname -v or something like that? >> >> Would it be possible to add options for more kernels from that boot menu? > > The list is controlled by the /boot/loader.conf variable kernels= > which defaults to "kernel kernel.old" > > I have a patch almost ready to land that will search all subdirectories > of /boot for a file named 'kernel' and add the names of those > directories to the list, such that the list will basically be autogenerated. > > It currently contains too much copy/pasted code, and I just need to > clean it up a bit: https://reviews.freebsd.org/D11886 > > It was originally designed as part of my contributions towards packaged > base, where pkg will keep the last N (default to 5 I think) kernel > packages you have installed around, incase an upgrade goes bad. > > This feature will work on any filesystem supported by the loader. > Thanks Allen, that's much better than manually setting the list. A nice addition to this would be having make installkernel automatically install multiple kernels. Currently we can add KERNCONF to make.conf and have multiple kernels build with one buildkernel command. Then we have to manually run installkernel for each kernel by setting KERNCONF and KODIR for each one. Maybe the kernel config file can have a kodir variable that specifies the kernel name that it should be installed into, unless overridden by KODIR in the installkernel command. Another option might be to have KODIR in make.conf, where each item provides a KODIR for each KERNCONF Normally I build and install two kernels with each system update, one is GENERIC, the other is a debug kernel with things like WITNESS and INVARIANTS enabled. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Extra Clang Tools
On 16/09/2017 11:59, blubee blubeeme wrote: FreeBSD switched to clang as it's compiler some time ago; was clang extra tools: http://clang.llvm.org/extra/index.html ever ported over? If yes, where is it located? You will find them included in the llvm ports with EXTRAS enabled clang-tidy is in llvm 3.8+ clang-include-fixer is in llvm 3.9+ modularize is in llvm 3.8+ pp-trace doesn't appear to exist clang-rename is in llvm 3.8+ clangd is in llvm-devel (5.0) Note that llvm ports append the version to the app name - they can be found in /usr/local/bin and /usr/local/llvm-/bin/ Building base WITH_CLANG_EXTRAS offers a different set of extras which are also in the llvm ports. As listed in 11-STABLE from /usr/src/usr.bin/clang/Makefile bugpoint clang-format llc lli llvm-ar llvm-as llvm-bcanalyzer llvm-cov llvm-cxxdump llvm-cxxfilt llvm-diff llvm-dis llvm-dwarfdump llvm-extract llvm-link llvm-lto llvm-lto2 llvm-mc llvm-modextract llvm-nm llvm-pdbdump llvm-profdata llvm-rtdyld llvm-symbolizer llvm-xray opt -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: i386 build fail
On 26/07/2017 17:00, Ngie Cooper wrote: Hi Shane, On Jul 25, 2017, at 23:25, Shane Ambler wrote: Having just updated my testing bhyve system to 12-current r321405M I then started updating my poudriere 12-current jails, the amd64 jail built fine at r321457 and then building i386 (should have got r321457 as well) failed with the following errors - Please update to r321486--I accidentally introduced some build errors that I finally fixed on that revision. Thanks, -Ngie Just for the record, I built r321518 and it's OK again. Thanks -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
i386 build fail
Having just updated my testing bhyve system to 12-current r321405M I
then started updating my poudriere 12-current jails, the amd64 jail
built fine at r321457 and then building i386 (should have got r321457
as well) failed with the following errors -
In file included from
/usr/local/poudriere/jails/12i386/usr/src/lib/msun/tests/exponential_test.c:41:
In file included from
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/ieeefp.h:13:
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/machine/ieeefp.h:111:9:
error: '__fldcw' macro redefined [-Werror,-Wmacro-redefined]
#define __fldcw(addr) __asm __volatile("fldcw %0" : : "m" (*(addr)))
^
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/fenv.h:98:9:
note: previous definition is here
#define __fldcw(__cw) __asm __volatile("fldcw %0" : : "m" (__cw))
^
In file included from
/usr/local/poudriere/jails/12i386/usr/src/lib/msun/tests/exponential_test.c:41:
In file included from
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/ieeefp.h:13:
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/machine/ieeefp.h:112:9:
error: '__fldenv' macro redefined [-Werror,-Wmacro-redefined]
#define __fldenv(addr) __asm __volatile("fldenv %0" : : "m" (*(addr)))
^
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/fenv.h:99:9:
note: previous definition is here
#define __fldenv(__env) __asm __volatile("fldenv %0" : : "m"
(__env))
^
In file included from
/usr/local/poudriere/jails/12i386/usr/src/lib/msun/tests/exponential_test.c:41:
In file included from
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/ieeefp.h:13:
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/machine/ieeefp.h:114:9:
error: '__fnstcw' macro redefined [-Werror,-Wmacro-redefined]
#define __fnstcw(addr) __asm __volatile("fnstcw %0" : "=m" (*(addr)))
^
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/fenv.h:105:9:
note: previous definition is here
#define __fnstcw(__cw) __asm __volatile("fnstcw %0" : "=m"
(*(__cw)))
^
In file included from
/usr/local/poudriere/jails/12i386/usr/src/lib/msun/tests/exponential_test.c:41:
In file included from
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/ieeefp.h:13:
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/machine/ieeefp.h:115:9:
error: '__fnstenv' macro redefined [-Werror,-Wmacro-redefined]
#define __fnstenv(addr) __asm __volatile("fnstenv %0" : "=m" (*(addr)))
^
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/fenv.h:104:9:
note: previous definition is here
#define __fnstenv(__env)__asm __volatile("fnstenv %0" : "=m"
(*(__env)))
^
In file included from
/usr/local/poudriere/jails/12i386/usr/src/lib/msun/tests/exponential_test.c:41:
In file included from
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/ieeefp.h:13:
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/machine/ieeefp.h:116:9:
error: '__fnstsw' macro redefined [-Werror,-Wmacro-redefined]
#define __fnstsw(addr) __asm __volatile("fnstsw %0" : "=m" (*(addr)))
^
/usr/obj/i386.i386/usr/local/poudriere/jails/12i386/usr/src/tmp/usr/include/fenv.h:106:9:
note: previous definition is here
#define __fnstsw(__sw) __asm __volatile("fnstsw %0" : "=am"
(*(__sw)))
^
I retried again to get a full build log, svn server is at r321463
This is a default build with no src.conf settings.
The full 20MB build log can be found here
http://shaneware.biz/freebsddebugdata/poudriere_log_2017-07-26-06-35.log
Shane
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFLAGS for certain ports
On 04/03/2017 02:17, Julian Elischer wrote:
On 2/3/17 8:58 pm, Dimitry Andric wrote:
On 2 Mar 2017, at 12:02, Mingo Rrubioer wrote:
I would like to see how well FreeBSD does as a workstation OS in the
HPC world due to its stability and reliability, as well as LLVM/clang.
I would like to know if FreeBSD has something similar to Gentoo's
/etc/portage/make.conf file and /etc/portage/package.use/* files in
order to compile certain ports with certain compiler flags.
It doesn't, though it would certainly be nice to have something like it
at some point. The current idiom is to put something similar to the
following in your /etc/make.conf:
.if ${.CURDIR:M/usr/ports/foo/bar}
CFLAGS+= [... flags for the foo/bar port ...]
.endif
.if ${.CURDIR:M/usr/ports/what/ever}
CFLAGS+= [... flags for the what/ever port ...]
.endif
We can also put a Makefile.local in the port directory. There can also
be arch and system specific makefiles.
See /usr/ports/Mk/bsd.port.mk from about line 1211
https://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?view=markup#l1211
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sluggish performance on head r311648
On 11/01/2017 15:32, Ultima wrote: I'v been noticing lately sluggish performance, maybe zfs? First noticed this a few days ago right after upgrading on Jan 7th to r311648 and the last upgrade before that was around dec 30-jan 1 (not sure of rev). Decided to upgrade again today. I usually build and install head every week or two, but I have been extremely busy the past couple months. FreeBSD U1 12.0-CURRENT FreeBSD 12.0-CURRENT #16 r311903: Tue Jan 10 17:20:11 EST 2017 amd64 Normally when one of my services scans a few directories it takes about 15 seconds tops, it has been taking several minutes. I want to note that this Just to eliminate the simple - is the zpool capacity high? When a pool gets into the 80-90% capacity, performance drops. -- FreeBSD - the place to B...Storing Data Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is there possible run a MacOS X binary
On 08/12/2016 09:15, Nilton Jose Rizzo wrote: Thankx for all comments. I know and understood all difficult. I'll have to spend my money on the purchase a Machintosh machine. Now that bhyve has gui support can OSX be started as a bhyve guest? Has anyone tried to get an openfirmware loader running? Do current macs still use openfirmware? For info regarding a compat layer for anyone wanting to work on that - cocotron.org is an mit licensed project similar to GNUStep - it has mostly focused on windows compatibility with Foundation usable on *nix flavours. There is apparently X11 support in AppKit but it needs a lot of work. -- FreeBSD - the place to B...Sharing Devices Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: a dirty trick: i386 nanobsd ports on amd64
On 21/11/2016 04:44, Poul-Henning Kamp wrote: I ran into a interesting problem, and want to share the solution, in case anybody else can use it. I'm upgrading a system which used to be i386 to amd64, but part of its job is to compile i386 nanobsd images. That's a solved problem, but I also needed a couple of ports installed, which for reasons of paperwork, must be compiled from source. Cross-compiling ports is not something I wanted to get into, but happily amd64 cpus can run in i386 mode these days: That is something poudriere is designed to do. i386 on amd64 is straight forward, you can also use qemu to cross compile for other archs Using poudriere you can also setup a pkg repo with the ports you build, just setup a http server then set pkg on your nano machine to use something like http://mypkgbuilder/packages/11i386 as the url for it's packages. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
On 12/07/2016 06:54, Conrad Meyer wrote: DVD-R dates to 1997; cheap USB flash devices are now pervasive. Maybe it's time to move on from CD. +1 on dropping CD images. I haven't burnt a CD in over 10 years and I don't believe I have seen a CD only drive in that time. Even with a CD size image I have burnt them to DVD, I first started this because transfer speeds of DVD's are faster and nowadays it costs almost the same to burn a DVD. So I see zero benefit to using CD's and that's before thinking of reusable USB devices. I do think there is a benefit to keeping the small boot only image available that can be used to start/recover a machine that can then download any data to be installed. -- FreeBSD - the place to B...Storing Data Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Issue mentioned on questions list
I'm not expecting a reply to this, it was something that come up discussing building custom kernels. Just wondering if someone may be interested in looking at the possibility of changing username length to a sysctl. As the number of people using computers is increasing, it is now common for web sites/mail servers to use your full email as your username, keeping that consistent through all username usage doesn't seem like an unreasonable request. I would expect a username length sysctl value would only be allowed to be set in the loader.conf at boot time, similar to zfs.arc_max Forwarded Message Subject: Re: Custom kernel for NAT and PF ? Date: Sat, 14 May 2016 13:58:56 +0930 From: Shane Ambler To: Doug McIntyre , FreeBSD Questions On 14/05/2016 04:40, Doug McIntyre wrote: On Fri, May 13, 2016 at 02:04:55PM +0930, Shane Ambler wrote: Now you only need to compile a custom kernel if you want to use newer features. ... Unfortunately, I have two situations where that isn't true. For the first, I wish that just loading the PPS drivers enabled the PPS_SYNC option in the kernel, but it doesn't seem to. (if there is a way to enable 'option PPS_SYNC' with a generic kernel I'd like to know, but my experients didn't lead me that working. I still have to compile the kernel for my GPS connected NTP servers. Which makes me wonder why the PPS drivers are a kernel loadable object. I would report that as a bug and see if it can be improved. The second is that the username handling is still limited to 32-bytes, which really cramps my logins for 'billyjoebobu...@somesillydomainname.com' so I have to build a custom kernel with longer usernames patched for the systems that need to deal with system logins like that. While I don't have that issue, it does sound like an old time limitation that should be considered for rework. Maybe it could be made into an adjustable sysctl. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FYI: SVN to GIT converter currently broken, github is falling behind
On 08/11/2015 21:36, Ulrich Spörlein wrote: Here's the same commit, and the difference between 1.8 and 1.9: % git cat-file commit 803795d tree 7fc83aba022834da5c218114b09ad4640735bcc0 parent c96fb0418e545a569b5975b4d878a30a948c29d5 author olgeni 1437203525 + committer olgeni 1437203525 + Upgrade to version 0.4.1. % git cat-file commit 61ca43b tree 7fc83aba022834da5c218114b09ad4640735bcc0 parent c96fb0418e545a569b5975b4d878a30a948c29d5 author olgeni 1437203529 + committer olgeni 1437203529 + Upgrade to version 0.4.1. In case you don't see it, there's a 4s difference in the timestamps for authoring and committing. Here's the original: % svn log -vc392405 svn://svn.freebsd.org/ports r392405 | olgeni | 2015-07-18 09:12:05 +0200 (Sat, 18 Jul 2015) | 2 lines Changed paths: M /head/www/elixir-maru/Makefile M /head/www/elixir-maru/distinfo Upgrade to version 0.4.1. So yeah, svn 1.9 returned a timestamp that was off by 4s. WTF? 4 seconds?? There have been 4 leap seconds added this century. Did 1.9 add timestamp corrections relating to leap seconds? Did the developer not use leapsecs when the svn server does? -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wrong temperature with AMD and amdtemp.ko
On 04/10/2015 20:10, Willem Jan Withagen wrote: On 4-10-2015 03:26, Shane Ambler wrote: On 03/10/2015 20:12, Willem Jan Withagen wrote: On 2-10-2015 23:32, Don Lewis wrote: On 2 Oct, Willem Jan Withagen wrote: Hi 10.2-STABLE FreeBSD 10.2-STABLE #0 r287102: Mon Aug 24 Processor: Opteron 6812, in Supermicro H8SGL Thusfar I have not been able to locate the "Power and Thermal Datasheet" for the family 15h Perhaps need to disassemble the bios, or check other tools or OSes on how they do this. According to Supermicro the H8SGL supports FreeBSD 8.0 but not 9.1 I see this as an omission on the website. I've never been bothered by FreeBSD compatibility in the 15+ years I'm using Supermicro. Maybe you could approach Supermicro support and ask for assistance in updating FreeBSD support - maybe for other boards as well. Another approach is asking iXSystems, I'm pretty sure they sell re-badged Supermicro machines. Turns out it has nothing to do with the Motherboard, but more on the temperature management hardware in the CPU. So asking either iXSstems or Supermicro does not really help. But supermicro would have access to the bios source and can tell quickly how it is done there. As a MB manufacturer they would also have the chance to ask AMD for info not easily found in docs. If supermicro doesn't provide info to oss developers then iXsystems could ask supermicro for info as they sell the hardware as their own and need to write drivers to support it and as a supporter of FreeBSD they may be interested in writing the update themselves. At the minimum one of them could tell you how the bios calculates the temperature so you can match it. Would save a lot of experiments on your part. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wrong temperature with AMD and amdtemp.ko
On 03/10/2015 20:12, Willem Jan Withagen wrote: On 2-10-2015 23:32, Don Lewis wrote: On 2 Oct, Willem Jan Withagen wrote: Hi 10.2-STABLE FreeBSD 10.2-STABLE #0 r287102: Mon Aug 24 Processor: Opteron 6812, in Supermicro H8SGL Thusfar I have not been able to locate the "Power and Thermal Datasheet" for the family 15h Perhaps need to disassemble the bios, or check other tools or OSes on how they do this. According to Supermicro the H8SGL supports FreeBSD 8.0 but not 9.1 Maybe you could approach Supermicro support and ask for assistance in updating FreeBSD support - maybe for other boards as well. Another approach is asking iXSystems, I'm pretty sure they sell re-badged Supermicro machines. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel Haswell support - Any updates?
On 18/09/2015 02:51, Shawn Webb wrote: On Thu, Sep 17, 2015 at 07:00:15PM +0200, Jean-S??bastien P??dron wrote: Hi everyone! I'm very sorry I didn't communicate at all on the i915 update project. So here is a status update: since this morning, the driver builds fine. I'm currently attending the XDC (X.Org Developers Conference) and don't have an Intel laptop to test with me. However, Johannes Dieterich (also attending the conference) offerred his help, so we will do that today. Obviously, do not expect something stable in the coming couple days. Thank you for your patience :) First of all, I want to say (nay, YELL!) "THANK YOU!" You're doing a +1 Now about other related tasks: o A Mesa update will be committed Real Soon Now?. It will unlock GLAMOR and OpenCL support. OpenCL on FreeBSD would be stupendously amazing! A little off-topic but has anyone tried to get nvidia to return libcuda to our drivers? While it was there a few years ago it was removed yet again. From what I could tell we had to use the linux sdk to compile cuda kernels which probably hindered freebsd using it so the sdk may need porting to freebsd as well. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is a high witness refcount indicative of a missing unlock?
sr/src/sys/kern/vfs_subr.c:2157 Mar 24 00:24:25 leader kernel: KDB: stack backtrace: Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe022df6e460 Mar 24 00:24:25 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe022df6e510 Mar 24 00:24:25 leader kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe022df6e5a0 Mar 24 00:24:25 leader kernel: __lockmgr_args() at __lockmgr_args+0x9ea/frame 0xfe022df6e6e0 Mar 24 00:24:25 leader kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xfe022df6e700 Mar 24 00:24:25 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe022df6e730 Mar 24 00:24:25 leader kernel: _vn_lock() at _vn_lock+0xaa/frame 0xfe022df6e7a0 Mar 24 00:24:25 leader kernel: vget() at vget+0x67/frame 0xfe022df6e7e0 Mar 24 00:24:25 leader kernel: devfs_allocv() at devfs_allocv+0xfd/frame 0xfe022df6e830 Mar 24 00:24:25 leader kernel: devfs_root() at devfs_root+0x43/frame 0xfe022df6e860 Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x345/frame 0xfe022df6e8e0 Mar 24 00:24:25 leader kernel: vfs_unmountall() at vfs_unmountall+0x61/frame 0xfe022df6e910 Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffe6d8, rbp = 0x7fffe7d0 --- Mar 24 00:24:25 leader kernel: Uptime: 12m42s -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: default pager (csh)
On 20/02/2015 01:22, RW wrote: On Wed, 18 Feb 2015 19:16:59 -0600 Mike Karels wrote: Trivia: the version of more on BSD systems actually is derived from less, not the original version of more. Actually, more is less $ md5 -r `which less ` `which more ` 50404f1beaa4e1261407190a88494b59 /usr/bin/less 50404f1beaa4e1261407190a88494b59 /usr/bin/more Yes more has been less for some time, trouble is it is programmed to behave differently based on the name used to call it so they aren't the same. Try this - echo "test data" > testfile more testfile less testfile So the debate over which is better continues Like everything, if you don't like the way it works you find a setting to make it work the way you want. Whether you ask on a mailing list or google it you will find a way to configure it your way. As long as it works, the default is of little concern to most. I don't even remember what year I set my pager to more, till I just looked I would have guessed I was using the default. Whatever intro I got started with used more as a pager and I have just used it since. I just think '| more' not '| less' -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Modify bsdinstall to set the default locale?
On 01/09/2014 02:11, Allan Jude wrote: > On 2014-08-31 12:36, Craig Rodrigues wrote: >> Hi, >> >> I recently did a fresh install of FreeBSD-10.stable on a new machine. >> >> If I run the 'locale', I get this: >> >> LANG= >> LC_CTYPE="C" >> LC_COLLATE="C" >> LC_TIME="C" >> LC_NUMERIC="C" >> LC_MONETARY="C" >> LC_MESSAGES="C" >> LC_ALL= >> >> Can we add something to bsdinstall/bsdconfig for setting the default locale? >> >> We already have stuff in the installer for setting the keyboard and timezone. >> -- >> Craig > > That would seem to make sense. Where do these settings actually get > stored? Where would I find a list of the possible settings to create the > dialog? > > I've never tried to use any of the alternative locales > They are environment variables - we can set manually in ~/.cshrc Any unset will equal the LANG setting - empty just falls to "C". Handbook Chapter 22 on localisation shows setting it in /etc/login.conf which currently only has a lang setting for Russian accounts. It also notes that Chinese, Japanese, and Korean will need to set more than just lang. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: android bsd connectivity tools etc ?
On 14/08/2014 09:17, Julian H. Stacey wrote: > Hi, > Any tips for Android / FreeBSD BSD tools for connectivity etc ? > > I just got a Samsung Galaxy Note 3, with Android 4.4.2 kernel 3.4.0 > I'll build a current from a 10.0-RELEASE partition, > but now looking with 9.2-RELEASE I see: > > /dev/ > lrwxr-xr-x 1 root wheel9 Aug 14 00:01 ugen1.5@ -> usb/1.5.0 > crw--- 1 root operator 0x7a Aug 14 00:00 usb/1.5.0 > crw--- 1 root operator 0x8f Aug 14 00:00 usb/1.5.1 > crw--- 1 root operator 0x90 Aug 14 00:00 usb/1.5.2 > I have a cheap Huawei phone running 2.3.6 When I plug in the usb cable to charge it, it shows up as 3 devices da0 at umass-sim1 bus 1 scbus5 target 0 lun 0 da0: < Android Adapter 0100> Removable Direct Access SCSI-2 device cd1 at umass-sim1 bus 1 scbus5 target 0 lun 1 cd1: < Android Adapter 0100> Removable CD-ROM SCSI-2 device da1 at umass-sim1 bus 1 scbus5 target 0 lun 2 da1: < Android Adapter 0100> Removable Direct Access SCSI-2 device On the phone I get a message to turn on usb mass storage after which I can mount_msdosfs /dev/da0s1 and get access to the sdcard in the phone. It looks like mass storage was hidden in 4.0 and maybe removed after 4.2. Try searching the android app store for usb mass storage. Online storage like google drive? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: updating standard headers to meet c++11 standard
On 20/05/2014 21:26, David Chisnall wrote:
> Hi,
>
> I thought I'd already fixed this a year or so ago. Looking at my system, I
> see this in cdefs.h:
>
> /* C++11 exposes a load of C99 stuff */
> #if defined(__cplusplus) && __cplusplus >= 201103L
> #define __LONG_LONG_SUPPORTED
> #ifndef __STDC_LIMIT_MACROS
> #define __STDC_LIMIT_MACROS
> #endif
> #ifndef __STDC_CONSTANT_MACROS
> #define __STDC_CONSTANT_MACROS
> #endif
> #endif
>
> So, if you're compiling C++ and the C++ standard is C++11 or later,
> we define the __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS macros. If
> it's C++98, you can define them yourself.
>
> Do you have a test case where this doesn't work?
>
I don't believe the standard used is specified so it must default to
C++98 leaving it manually defined. The changes made to glibc and osx
made these macros always defined without testing __STDC_LIMIT_MACROS
or __cplusplus
I guess we are technically correct but it also appears that we are the
odd one out. Which would depend on what you consider the default standard.
I have just been updating graphics/openimageio to 1.4.7
Larry is adding the following to fix compile on several targets
https://github.com/OpenImageIO/oiio/pull/858/files
This includes adding add_definitions ("-D__STDC_LIMIT_MACROS") to cover
the entire project. On FreeBSD I had issue when compiling
array_view_test.cpp which is fixed with the global addition.
The first change to src/include/OpenImageIO/image_view.h of adding
#define __STDC_LIMIT_MACROS before #include wasn't
sufficient to get the macros defined.
This will fall down to any project using image_view from oiio libs to
also define the standard or the macro.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
updating standard headers to meet c++11 standard
When including stdint.h in c++ we can #define __STDC_LIMIT_MACROS so that we get macros like INT32_MAX defined. Also related is __STDC_CONSTANT_MACROS I have recently found that the need for these has been removed within the c++11 standard. This year old bug report was to update glibc to this end - https://sourceware.org/bugzilla/show_bug.cgi?id=15366 Also of note is that Apple removed the use of this macro from OSX with the release of 10.9 over a year ago http://www.opensource.apple.com/source/xnu/xnu-2422.1.72/EXTERNAL_HEADERS/stdint.h I believe as we push to use llvm's libc++ and support for c++11 we should also make sure the rest of our sources are kept up to date as well. Are there any other changes within c++11 or c++14 that we should be looking to update? Shane ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ports broken in current
I have just updated my 11-CURRENT tinderbox machine and found an issue that breaks ports building. make: "/usr/share/mk/bsd.port.mk" line 15: Could not find bsd.own.mk This is highlighted as tinderbox creates a clean build environment while the base system kept working with the old file being left behind - make delete-old doesn't remove bsd.own.mk from base but a clean system doesn't get it installed. In r265420 /head/share/mk/Makefile removed reference to bsd.own.mk and replaced it with src.opts.mk bsd.port.mk was left unaltered still including bsd.own.mk which now doesn't get installed but is still in svn, breaking ports building. Should bsd.port.mk include src.opts.mk instead of bsd.own.mk or should bsd.own.mk be re-added to the install list? This appears to carry on from the yesterdays build fails with src.opts.mk not being found. Shane ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PACKAGESITE spam
On 22/12/2013 09:34, Steve Kargl wrote: > On Sat, Dec 21, 2013 at 11:14:39PM +0100, Baptiste Daroussin wrote: >> >> this has been done and activated for reason, first for lot of companies, > > companies can turn it on it they want it. Generally the more secure option is default, you can turn off security options as you choose. >> secondly I receive tons of request to actiavte on by default while >> you are the first to request it off by default > > I certainly can't refute 'tons of [private] requests'. There is > no discussing of such logging in freebsd-current, freebsd-hackers, > or freebsd-ports lists. > > Other than the noise in /var/log/message, what does this provide > that 'pkg info' doesn't! Please turn of this feature by default. > Isn't this "noise" the same as we had with the old package system? So really nothing has changed, well now we can turn it off which I don't think we could before. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn && ports, or the hen && egg
On 19/12/2013 08:04, Freddie Cash wrote: > On Wed, Dec 18, 2013 at 1:09 PM, Matthias Apitz wrote: >> Ok, thanks; but see this: >> >> $ uname -a >> FreeBSD tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 >> 12:10:57 CEST 2013 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC/i386 >> $ svnlite >> Type 'svn help' for usage. >> $ svn help >> svn: not found >> > > ​And ... if you type "svnlite help" what happens? The name of the command > is svnlite, not svn, so you may have to mentally swap the terms in terminal > messages. :)​ > > That would work once you know you need to use svnlite. Most people will try svn and after that fails look for a way to install it, rather than looking for a renamed substitute. Maybe a /bin/svn script could test if svn exists and exec it or svnlite or display a message that svnlite is available until svn is installed. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: P4 question. not really a freebsd but using with freebsd
On 13/12/2013 06:00, Julian Elischer wrote: > so I have a freebsd tree checked into perforce. > one particular subdirectory has been heavily modified to teh extent > that it's not really hte same thing any more and I want to move it out > to a separate place, and then replace it with the original contents so I > can update the tree and get changes to that original directory. > > I can think of two ways to do this: > # move the modified one out > p4 open > p4 move //depot/Freebsd/src1/sys/netatalk/... > //depot/Freebsd/src1/sys/netmumble/... > followed by: > # bring back the original version by copying it from before changes > started. > p4 integrate //depot/Freebsd/src1/sys/netatalk/...@original_import > //depot/Freebsd/src1/sys/netmumble/... > p4 resolve > p4 submit > > > Or, a second alternative: not quite sure how to do this if there are > deletions and additions on the tree > #copy out the modified version. > #revert the directory in question to exactly how it was before the > changes started > files in netmumble should see all their history even when they were in > netatalk, > and files now in netatalk should see history from before the changes > started, > and MAYBE from when they were modified (optional). Personally, using svn I would use the second approach mv netatalk netmumble rm -R netmumble/.svn svn co netatalk diff -ru netatalk netmumble or cp then svn revert would give the same result. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On 13/11/2013 07:49, Tijl Coosemans wrote:
> On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote:
>> On Tue, Nov 12, 2013 at 09:55:56AM -0800, Steve Kargl wrote:
>>> On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote:
On 12 Nov 2013, at 17:54, Steve Kargl
wrote:
>
> struct Entry {
>time_t date;
>Severity severity;
>std::deque messages;
>std::string message;
>bool is_child;
>Entry() : is_child(false) { }
> };
I think the problem is that the code tries to use std::deque as a
member of struct Entry, before it is completely defined. This is not
allowed by the standard, although some libraries (e.g. GNU libstdc++)
apparently permit it for some container types.
> There's a similar problem with graphics/blender. There's a class
> TreeElement which links to its parent TreeElement like this:
>
> std::map::const_iterator parent;
>
> Works with libstdc++, fails with libc++. If the standard doesn't
> specify this it would still be a very convenient extension.
>
A possible solution I found looking into this is to wrap the Entry
reference in a std::unique_ptr - so changing -
std::deque messages;
to -
std::deque> messages;
This turns messages into a pointer so you need to change
messages.date into messages->date
This got blender compiling past that issue but I haven't got the rest
of it compiling to test that it runs.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make buildworld
On 23/10/2013 11:50, Saul A. Peebsen wrote: > Never wanted to run CURRENT, but had no choice, STABLE wouldn't boot. > is there anything else I need to modify to move from > 10-CURRENT to BETA and ultimately to RELEASE? > I believe HEAD has been renamed to 11-CURRENT stable/10 was created 12 days ago which is 10-BEATA Was it stable/9 or stable/10 that wouldn't boot? With 10.0 to be released shortly you may wait a while for 11.0 release ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Continuous timeout messages from 10.0 alpha4
Resending to current This is a regression between alpha2 and alpha4. I first setup a disk to boot 10 just after alpha2 was tagged. A few days ago I updated to alpha4 and started getting timeout messages, I have just built alpha5 r256098 and still get them. I just had 10 running for a few hours and 3 of the messages log archives which syslog rotates each hour due to size contain 3370 2508 and 3162 timeout messages over 3 hours uptime. each entry is similar to -- Oct 7 19:00:02 leader kernel: ahcich1: Timeout on slot 15 port 0 Oct 7 19:00:02 leader kernel: ahcich1: is 4001 cs 8000 ss rs 8000 tfd 2451 serr cmd 4f17 With slot x cycling from 0-31 but not always in sequence. MB is ASUS P8H61M LE/USB3 - corei5 - 8MB - nvidia GT520 ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xfb305000-0xfb3057ff irq 20 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported With the following connected to ahcich1 (LG blu-ray burner) cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device Most relevant dmesg info would be (full dmesg/logs available) -- ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xfb305000-0xfb3057ff irq 20 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ahciem0: on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich4 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad8 ada2 at ahcich5 bus 0 scbus3 target 0 lun 0 ada2: ATA-6 SATA 2.x device ada2: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 512bytes) ada2: 76324MB (156312576 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad10 ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
