Re: lang/gcc46: error when compiling with CLANG
Am 04/29/12 14:18, schrieb Dimitry Andric: On 2012-04-29 12:54, O. Hartmann wrote: On a FreeBSD 10-CURRENT/amd64 box the compilation/update of the port lang/gcc46 fails with the below shown error. Since the port compiles well on FreeBSD 9 and another FreeBSD 10 box (all amd64, CLANG built), I feel a bit confused since the setup is almost the same on all boxes. The machine in question is the most modern box, equipted with a Core i7-3930K: ... ... gmake[3]: *** [s-tm-texi] Segmentation fault: 11 (core dumped) gmake[3]: *** Waiting for unfinished jobs What happens if you simply repeat the build? If the segfault occurs at different stages every time, you might simply have bad RAM. Another possibility is that the build is out of memory, in that case you could try running it without multiple make jobs (e.g. set DISABLE_MAKE_JOBS). Repeating the build ends up at the same stage as it stopped when building on regular basis - for my understanding. I also disabled building with parallel make jobs as recommended - with no effect. Also, I tried to build lang/gcc46 with portmaster -f lang/gcc46, with the same result - bad. Maybe I should recompile texinfo or whatever this core-dumping *.texi triggers? Regards, Oliver [...] --no-split -I . -I .././../gcc-4.6-20120420/gcc/doc \ -I .././../gcc-4.6-20120420/gcc/doc/include -o doc/gcc.info .././../gcc-4.6-20120420/gcc/doc/gcc.texi; \ fi build/genhooks \ .././../gcc-4.6-20120420/gcc/doc/tm.texi.in tmp-tm.texi gmake[3]: *** [s-tm-texi] Segmentation fault: 11 (core dumped) gmake[3]: Leaving directory `/usr/ports/lang/gcc46/work/build/gcc' gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake: *** [bootstrap-lean] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc46. *** [build] Error code 1 Stop in /usr/ports/lang/gcc46. === make failed for lang/gcc46 === Aborting update signature.asc Description: OpenPGP digital signature
Re: New Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
Am 04/28/12 18:52, schrieb Dimitry Andric: On 2012-04-28 13:12, Volodymyr Kostyrko wrote: O. Hartmann wrote: Is there in official way to get this fixed with CLANG? I see that files folder in graphics/dri is missing, so none of the fixes for both the faulty source files I think the patch should go to graphics/libGL. cd /usr/ports/graphics/libGL/files fetch -rao - 'http://cgit.freedesktop.org/mesa/mesa/patch/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95' | sed -e 's|^--- a/src|--- src|' -e 's|^+++ b/src|+++ src|' patch-nouveau Should do. Please try this patch (lightly tested): http://www.andric.com/freebsd/clang/clangports-graphics-libGL-3.diff I'll give it a try as soon as possible. Ath the moment, things went perfect utilizing the initial hint by Volodymyr Kostyrko. signature.asc Description: OpenPGP digital signature
Re: compiling world fails with 9.0 and 10.0 from today (28.04)
Hi, after failing to compile 9.0 and 10.0 on a fresh 9.0 installation, I compiled both 9.0 and 10.0 on a 8.3 machine without any problem. I will test the new kernel on the 9.0 machine later today. I was not able to pinpoint what causes the failure on the 9.0 machine. Erich On Saturday 28 April 2012 08:59:15 David Wolfskill wrote: On Sat, Apr 28, 2012 at 08:50:47AM +0700, Erich Dollansky wrote: ... I use the following commands to do the compilation: cd /usr/src /usr/bin/nice -n 20 make buildworld OK. That should build the userland OK. Have you reviewed /usr/src/UPDATING? Near the end of that file, there is a list of commands to use to build from sources. Scan for COMMON ITEMS. Do you mean this one? make kernel-toolchain make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=YOUR_KERNEL_HERE make -DALWAYS_CHECK_MAKE installkernel KERNCONF=YOUR_KERNEL_HERE Isn't this the next step after building the world? No; I was referring to the part with the sub-heading To rebuild everything and install it on the current system. or To upgrade in-place from 8.x-stable to current depending on whether you're tring to update release/9.0 to stable/9 or release/9.0 to head (for example). ... I am currently downloading the 9.0 sources into an empty source tree on a 8.3 machine to see what happens there. Note that this is also an upgrade. Peace, david -- David H. Wolfskillda...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. ___ 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: www/firefox and mail/thunderbird fail to compile in FreeBSD 10-CUR/amd64 with CLANG
I realized that compiling mail/thunderbird and www/firefox on most recent FreeBSD 10-CURRENT/amd64 with CLANG/LLVM 3.1 doesn't work anymore. Compiling www/firefox and mail/thunderbird with gcc 4.6 works fine. Am 04/29/12 10:10, schrieb O. Hartmann: On my FreeBSD 10 boxes, all compiled with CLANG and using CLANG ( FreeBSD 10.0-CURRENT #0 r234500: Fri Apr 20 21:59:02 CEST 2012), compiling/updating Firefox to V12 and Thunderbird to V12 fails with the below shown error. Does someone have any clue what could trigger the problem? On FreeBSD 9-STABLE/amd64, also compiled with CLANG, there is no such problem. Thanks in advance, Oliver [...] In file included from /usr/ports/www/firefox/work/mozilla-release/js/src/jsalloc.cpp:40: In file included from ./jscntxt.h:50: ./jsapi.h:2102:1: error: 'JS_GetNaNValue' has C-linkage specified, but returns user-defined type 'jsval' (aka 'JS::Value') which is incompatible with C [-Werror,-Wreturn-type-c-linkage] JS_GetNaNValue(JSContext *cx); ^ ./jsapi.h:2105:1: error: 'JS_GetNegativeInfinityValue' has C-linkage specified, but returns user-defined type 'jsval' (aka 'JS::Value') which is incompatible with C [-Werror,-Wreturn-type-c-linkage] JS_GetNegativeInfinityValue(JSContext *cx); ^ ./jsapi.h:2108:1: error: 'JS_GetPositiveInfinityValue' has C-linkage specified, but returns user-defined type 'jsval' (aka 'JS::Value') which is incompatible with C [-Werror,-Wreturn-type-c-linkage] JS_GetPositiveInfinityValue(JSContext *cx); ^ ./jsapi.h:2111:1: error: 'JS_GetEmptyStringValue' has C-linkage specified, but returns user-defined type 'jsval' (aka 'JS::Value') which is incompatible with C [-Werror,-Wreturn-type-c-linkage] JS_GetEmptyStringValue(JSContext *cx); ^ ./jsapi.h:2819:1: error: 'JS_ComputeThis' has C-linkage specified, but returns user-defined type 'jsval' (aka 'JS::Value') which is incompatible with C [-Werror,-Wreturn-type-c-linkage] JS_ComputeThis(JSContext *cx, jsval *vp); ^ In file included from /usr/ports/www/firefox/work/mozilla-release/js/src/jsanalyze.cpp:40: In file included from ./jsanalyze.h:44: In file included from ./jscompartment.h:46: In file included from ./jscntxt.h:50: ./jsapi.h:2102:1: error: 'JS_GetNaNValue' has C-linkage specified, but returns user-defined type 'jsval' (aka 'JS::Value') which is incompatible with C [-Werror,-Wreturn-type-c-linkage] JS_GetNaNValue(JSContext *cx); ^ ./jsapi.h:2105:1: error: 'JS_GetNegativeInfinityValue' has C-linkage specified, but returns user-defined type 'jsval' (aka 'JS::Value') which is incompatible with C [-Werror,-Wreturn-type-c-linkage] -- O. Hartmann Freie Universität Berlin Institut fuer Geologische Wissenschaften Fachrichtung Planetologie und Fernerkundung Malteser-Str. 74--100/Haus D D-12249 Berlin Tel.: +49 (0) 30 838 70 508 FAX: +49 (0) 30 838 70 837 signature.asc Description: OpenPGP digital signature
Re: segfault in vfscanf(3): clang and __restrict usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.04.2012 00:01, Boris Samorodov wrote: I've rebuild the world (because I had to use gcc-built world for obvious reason) and now smartd works (can't test cupsd for now). BTW, the port devel/ORBit2 which segfaulted both with clang and gcc is built fine now. Thanks! I committed the patch to HEAD r234836. Thank you both for your feedback and sorry for the delay. - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+eePEACgkQa+xGJsFYOlMD5QCcDh/qLnHOysRjWjsR9o18FxHv oTkAnRoAXi4t3QCDk7tiQeVM7FDqB07c =1SPA -END PGP SIGNATURE- ___ 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: lang/gcc46: error when compiling with CLANG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30.04.2012 08:11, O. Hartmann wrote: Repeating the build ends up at the same stage as it stopped when building on regular basis - for my understanding. You say you have two boxes running 10-CURRENT: do they run the same SVN revision? A recent change (r234585, 2012-04-22) in libc causes several softwares to segfault if the libc is built with clang. I just committed to HEAD (r234836) a patch that fixes this. Maybe it's related to your problem, you may want to try it. - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+eexEACgkQa+xGJsFYOlNvQgCgmOVXZiH5zv5T+RdVL25rdome +zAAoLR/deC5HhWwZgNi/8yK8wcYJ0AS =RUSU -END PGP SIGNATURE- ___ 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: x220 notes
On Mon, 19 Mar 2012 12:03:13 -0700, matt wrote Hi Matt, I'll have to try again without the patch to see if it's Xorg/KMS or FreeBSD base that has changed. FYI, I've just tried suspend/resume with all.14.5.patch and sources from 2012/04/28, but I still get a black screen on resume :/ Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.FreeBSD.org ___ 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 from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19
On Saturday, April 28, 2012 1:20:22 pm Anton Shterenlikht wrote: On Fri, Apr 27, 2012 at 07:51:11AM -0400, John Baldwin wrote: On Thursday, April 26, 2012 6:42:15 pm Anton Shterenlikht wrote: I was updating from r231158 to 234465 (amd64 laptop Compaq 6715s), and I think I must've messed someting up in the kernel config. Now I get build error, panic of a loader error, depending on which kernel I build. * If I build GENERIC, I get: (transcribed by hand) mountroot: waiting for device /dev/ad4s1a Mounting from ufs:/dev/ad4s1a failed with error 19. mountroot ? List of GEOM managed disk devices: cd0 mountroot Hmm, so GENERIC is not finding ad4. Can you look in the dmesg (using scroll-lock) to see if GENERIC finds your ATA controller ok? I see only one line: ata0: ATA channel at channel 0 on atapci0 ata does not appear anywhere else. The device is certainly correct in r231158: BUZI df Filesystem 512-blocks UsedAvail Capacity Mounted on /dev/ad4s1a 101554068 46474368 4695537650%/ devfs220 100%/dev BUZI * If I add device atadisk to GENERIC, then I get this linking error: Yes, you aren't supposed to use 'atadisk' with ATA_CAM. See the UPDATING entry 20110424 for more details on that. However, can you obtain a verbose dmesg from your old kernel? Amazingly (for me) I can't! Twice I got a panic. The third time, and thereafter, I get the same error as with GENERIC: Mounting from ufs:/dev/ad4s1a failed with error 19. I also see: ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0exb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x1 Hmmm, I don't know how to grok these lines, but does your disk work at all now with any kernel? It may be that your disk has died (or a cable, etc.) and it just happened to coincide with your upgrade? -- John Baldwin ___ 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: [RFC] Un-staticise the toolchain
Den 26/04/2012 kl. 22.30 skrev Chris Rees: On 26 April 2012 20:15, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 26/04/2012 20:01, Chris Rees wrote: hydra# cd /usr/ports time make MAKE=~crees/bin/make-static index Generating INDEX-9 - please wait.. Done. 729.770u 120.841s 7:45.10 182.8%920+2676k 5251+116484io 7750pf+0w hydra# time make MAKE=~crees/bin/make-dynamic index Generating INDEX-9 - please wait.. Done. 771.320u 133.540s 8:07.83 185.4%609+2918k 474+116484io 570pf+0w We have a 10% slowdown (or 11% speedup, depending on your figures) when using a dynamically loaded make. I don't think you can validly conclude much from just one sample of each type. Try repeating those tests enough that you can do some decent statistics. Oh, and you should probably either discard the first few results, or else take pains to flush[*] the buffer cache between each run, so you end up measuring the same thing repeatably. Had I done the tests the other way around, I may agree with you, but the second test should benefit from any buffering, and it is *still* slower. Look, I know it's not a perfect benchmark, it was just some food for thought-- a difference of 10% is pretty significant, and I don't think you can blame that on a solar flare. Can anyone explain to me why the dynamically linked version is significantly slower? What are the extra steps involved compared to a statically linked binary? Thanks, Erik___ 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
RFC: jemalloc: qdbus sigsegv in malloc_init
Hi, the kde team is seeing some strange problems with the new version (4.8.1) of devel/dbus-qt4 with current. It does work with stable. I also suspect that the problem described below is affecting the experimental cinnamon port (an alternative to gnome3, possible replacement of gnome2). The problem happens with both i386 and amd64 with empty /etc/malloc.conf and simple /etc/make.conf. Everything compiled with base gcc (no clang). The kernel was compiled with no debug support, but it can enable if needed. There are reports from avi...@freebsd.org of the same behavior with clang compiled world and kernel and with MALLOC_PRODUCTION=yes. When qdbus starts, it segfauts. The backtrace of the problem with r234769 can be found here: http://pastebin.com/ryBXtqGF. When starting the qdbus daemon by hand in a X+twm session, we see it calls calloc many times and after a fixed number of times segfaults. We see it segfaults at rb_gen (a quite large macro defined at $SRC_BASE/contrib/jemalloc/include/jemalloc/internal/rb.h). If the daemon is started by hand, I'm able to skip all the calls qdbus makes to calloc till the one causing the segfault. At that point, at rb_gen, we don't exactly know what is going on or how to debug the macro. Ktrace are available, but we were unable to find anything new from them. With old versions of current before the jemalloc imports (as of March 30th) the daemon segfaulted at malloc.c:2426. With revisions during April 20 to 24th (can be more precise, it was during the jemalloc imports) the daemon segfaulted at malloc_init. Bts are available if needed, and if necessary I can go back to those revision and recompile world+kernel to see its behavior. Any help from freebsd-current@ (perhaps Jason Evans can help us) will be appreciated. Any additional info, like source revisions, can be provided. I would like to stress that the experimental devel/dbus-qt4 works fine with recent stable. ___ 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: RFC: jemalloc: qdbus sigsegv in malloc_init
Hi, Please install valgrind and run the program inside valgrind. See what kind of errors it generates. Adrian ___ 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
Upgrade Paths
Hello, Apologies for this question, but I am not clear on how I can upgrade from 9.0-CURRENT (July 2011) to 9.0-RELEASE? Must I use CVS or can I use the freebsd-upgrade pathway? freebsd-upgrade is giving me an error, so I suspect that either I cannot use it or I must change some setting prior to its use. # freebsd-update -r 9.0-RELEASE upgrade Looking up update.FreeBSD.org mirrors... 4 mirrors found. Fetching public key from update5.FreeBSD.org... failed. Fetching public key from update4.FreeBSD.org... failed. Fetching public key from update3.FreeBSD.org... failed. Fetching public key from update2.FreeBSD.org... failed. No mirrors remaining, giving up. Thanks very much for any suggestions. Aric ___ 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: Upgrade Paths
On Mon, Apr 30, 2012 at 11:10 AM, Aric Gregson aorc...@mac.com wrote: Hello, Apologies for this question, but I am not clear on how I can upgrade from 9.0-CURRENT (July 2011) to 9.0-RELEASE? Must I use CVS or can I use the freebsd-upgrade pathway? freebsd-upgrade is giving me an error, so I suspect that either I cannot use it or I must change some setting prior to its use. # freebsd-update -r 9.0-RELEASE upgrade Looking up update.FreeBSD.org mirrors... 4 mirrors found. Fetching public key from update5.FreeBSD.org... failed. Fetching public key from update4.FreeBSD.org... failed. Fetching public key from update3.FreeBSD.org... failed. Fetching public key from update2.FreeBSD.org... failed. No mirrors remaining, giving up. As freebsd-update depends on the existence of a system matching a release, it cannot be used when upgrading from any system that is not a RELEASE, so you will need to update your sources and follow the standard update procedure in /usr/src/UPDATING. You can update sources with svn, CVS or csup. The latter is probably the best choice if you don't update very often. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: Upgrade Paths
On Mon, 30 Apr 2012 11:43:16 -0700 Kevin Oberman kob6...@gmail.com wrote: [snip] You can update sources with svn, CVS or csup. The latter is probably the best choice if you don't update very often. Thank you for your reply. Aric ___ 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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On 29/04/2012 12:04 PM, Adrian Chadd wrote: .. and the output from the buildworld: .. skipped .. -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c jemalloc_jemalloc.c -o jemalloc_jemalloc.So jemalloc_jemalloc.c: In function 'calloc': jemalloc_jemalloc.c:1027: internal compiler error: in change_address_1, at emit-rtl.c:1784 Please submit a full bug report, with preprocessed source if appropriate. SeeURL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error This ICE was fixed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256 Unfortunately the fix is GPLv3-licensed, so we can't merge it back as-is. I tracked down the cause of the issue to contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h line 214. So possible workaround could be replacing this line to #if defined(JEMALLOC_DEBUG) || defined(__mips__) Ugly, yes, but good enough as a band-aid until we figure out what to do with the real issue ___ 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: RFC: jemalloc: qdbus sigsegv in malloc_init
On Apr 30, 2012, at 7:13 AM, Gustau Pérez i Querol wrote: the kde team is seeing some strange problems with the new version (4.8.1) of devel/dbus-qt4 with current. It does work with stable. I also suspect that the problem described below is affecting the experimental cinnamon port (an alternative to gnome3, possible replacement of gnome2). The problem happens with both i386 and amd64 with empty /etc/malloc.conf and simple /etc/make.conf. Everything compiled with base gcc (no clang). The kernel was compiled with no debug support, but it can enable if needed. There are reports from avi...@freebsd.org of the same behavior with clang compiled world and kernel and with MALLOC_PRODUCTION=yes. When qdbus starts, it segfauts. The backtrace of the problem with r234769 can be found here: http://pastebin.com/ryBXtqGF. When starting the qdbus daemon by hand in a X+twm session, we see it calls calloc many times and after a fixed number of times segfaults. We see it segfaults at rb_gen (a quite large macro defined at $SRC_BASE/contrib/jemalloc/include/jemalloc/internal/rb.h). If the daemon is started by hand, I'm able to skip all the calls qdbus makes to calloc till the one causing the segfault. At that point, at rb_gen, we don't exactly know what is going on or how to debug the macro. Ktrace are available, but we were unable to find anything new from them. With old versions of current before the jemalloc imports (as of March 30th) the daemon segfaulted at malloc.c:2426. With revisions during April 20 to 24th (can be more precise, it was during the jemalloc imports) the daemon segfaulted at malloc_init. Bts are available if needed, and if necessary I can go back to those revision and recompile world+kernel to see its behavior. Any help from freebsd-current@ (perhaps Jason Evans can help us) will be appreciated. Any additional info, like source revisions, can be provided. I would like to stress that the experimental devel/dbus-qt4 works fine with recent stable. The crash is happening in page run management, so there is some pretty bad memory corruption going on by the time of the crash. If I understand you correctly, you have reproduced the crash on a system that does *not* have MALLOC_PRODUCTION defined, which means that none of the assertions in jemalloc caught the problem. Adrian Chadd made the excellent suggestion of trying valgrind; it's likely to point out the problem almost immediately. If that doesn't work, the utrace functionality in malloc may help you figure out what activity has occurred by the time of the crash, and give you a better understanding of what happened to memory around the address that is involved in the crash. Jason___ 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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On 04/30/12 14:04, Oleksandr Tymoshenko wrote: On 29/04/2012 12:04 PM, Adrian Chadd wrote: .. and the output from the buildworld: .. skipped .. -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c jemalloc_jemalloc.c -o jemalloc_jemalloc.So jemalloc_jemalloc.c: In function 'calloc': jemalloc_jemalloc.c:1027: internal compiler error: in change_address_1, at emit-rtl.c:1784 Please submit a full bug report, with preprocessed source if appropriate. SeeURL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error This ICE was fixed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256 Unfortunately the fix is GPLv3-licensed, so we can't merge it back as-is. Actually.. the fix was merged to the gcc 4.1 branch so we can take it under GPLv2: http://gcc.gnu.org/viewcvs?view=revisionrevision=128198 best regards, Pedro. ___ 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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On 30/04/2012 1:52 PM, Pedro Giffuni wrote: On 04/30/12 14:04, Oleksandr Tymoshenko wrote: On 29/04/2012 12:04 PM, Adrian Chadd wrote: .. and the output from the buildworld: .. skipped .. -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c jemalloc_jemalloc.c -o jemalloc_jemalloc.So jemalloc_jemalloc.c: In function 'calloc': jemalloc_jemalloc.c:1027: internal compiler error: in change_address_1, at emit-rtl.c:1784 Please submit a full bug report, with preprocessed source if appropriate. SeeURL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error This ICE was fixed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256 Unfortunately the fix is GPLv3-licensed, so we can't merge it back as-is. Actually.. the fix was merged to the gcc 4.1 branch so we can take it under GPLv2: http://gcc.gnu.org/viewcvs?view=revisionrevision=128198 Thanks, Pedro! It's GPLv2 indeed. I missed it yesterday. Will commit. ___ 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: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
Feel free to import this change referencing this explicit gcc-4_1-branch revision as source and mentioning the GPLv2 license. -- Martin Matuška FreeBSD commiter http://blog.vx.sk Pedro Giffuni p...@freebsd.org wrote: On 04/30/12 14:04, Oleksandr Tymoshenko wrote: On 29/04/2012 12:04 PM, Adrian Chadd wrote: .. and the output from the buildworld: .. skipped .. -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c jemalloc_jemalloc.c -o jemalloc_jemalloc.So jemalloc_jemalloc.c: In function 'calloc': jemalloc_jemalloc.c:1027: internal compiler error: in change_address_1, at emit-rtl.c:1784 Please submit a full bug report, with preprocessed source if appropriate. SeeURL:http://gcc.gnu.org/bugs.html; for instructions. *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error This ICE was fixed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256 Unfortunately the fix is GPLv3-licensed, so we can't merge it back as-is. Actually.. the fix was merged to the gcc 4.1 branch so we can take it under GPLv2: http://gcc.gnu.org/viewcvs?view=revisionrevision=128198 best regards, Pedro. _ 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 ___ 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: [RFC] Un-staticise the toolchain
On Sat, Apr 28, 2012 at 11:03:17AM +0100, Bob Bishop wrote: Yes. You to have a statically linked /rescue/sh on board, so what's the point of /bin/sh being dynamic? While you and I agree on this, the primary reason we went with a dynamically linked root was for PAM and NSS support -- which are dlopen'ed. And thus requires using a shared libc. -- -- David (obr...@freebsd.org) ___ 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: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
On Tue, Apr 24, 2012 at 09:34:58PM +0300, Vladimir Sharun wrote: === usr.bin/file (all) ... file.o: In function `main': /usr/src/usr.bin/file/../../contrib/file/file.c:(.text+0x717): undefined reference to `magic_getpath' /usr/src/usr.bin/file/../../contrib/file/file.c:(.text+0x7df): undefined reference to `magic_list' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** [file] Error code 1 How are you building this? Did libmagic get [re]built first? r234657 $ svn info -r234657 svn info -r234657 svn://svn.freebsd.org/base/head Last Changed Date: 2012-04-24 10:51:36 -0700 (Tue, 24 Apr 2012) I do not believe that a 10-CURRENT system from 2012-04-24 has trouble building the new file(1). The issue that started this thread is due to a commit from 2009-02-27 -- which pre-dates 10-CURRENT. -- -- David (obr...@freebsd.org) ___ 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
Sparse option for makefs
Hi,
I have added a sparse option to makefs, where the tool does not fill
the file with zeros, before laying out the data on it. This is handy when
we are creating a VM image because,
1. It reduces the creation time significantly.
2. Copying around is less time consuming (Tools like rsync and cp can
deal efficiently with sparse files)
3. Easily fits the image into a CD without additional processing like
'cp
--sparse=Always' etc.
Please see if this can be made a part of main tree.
*** ../9/usr/src/usr.sbin/makefs/makefs.c 2012-01-02
19:25:41.0 -0800
--- usr/src/usr.sbin/makefs/makefs.c2012-04-22 22:38:49.0 -0700
***
*** 112,118
start_time.tv_sec = start.tv_sec;
start_time.tv_nsec = start.tv_usec * 1000;
! while ((ch = getopt(argc, argv, B:b:d:f:F:M:m:N:o:s:S:t:x)) !=
-1) {
switch (ch) {
case 'B':
--- 112,118
start_time.tv_sec = start.tv_sec;
start_time.tv_nsec = start.tv_usec * 1000;
! while ((ch = getopt(argc, argv, B:b:d:f:F:M:m:N:o:s:S:t:xp)) !=
-1) {
switch (ch) {
case 'B':
***
*** 224,230
case 'x':
fsoptions.onlyspec = 1;
break;
!
case '?':
default:
usage();
--- 224,232
case 'x':
fsoptions.onlyspec = 1;
break;
! case 'p':
! fsoptions.sparse = 1;
! break;
case '?':
default:
usage();
***
*** 335,341
fprintf(stderr,
usage: %s [-t fs-type] [-o fs-options] [-d debug-mask] [-B endian]\n
\t[-S sector-size] [-M minimum-size] [-m maximum-size] [-s
image-size]\n
! \t[-b free-blocks] [-f free-files] [-F mtree-specfile] [-x]\n
\t[-N userdb-dir] image-file directory | manifest\n,
prog);
exit(1);
--- 337,343
fprintf(stderr,
usage: %s [-t fs-type] [-o fs-options] [-d debug-mask] [-B endian]\n
\t[-S sector-size] [-M minimum-size] [-m maximum-size] [-s
image-size]\n
! \t[-b free-blocks] [-f free-files] [-F mtree-specfile] [-x] [-p
sparse]\n
\t[-N userdb-dir] image-file directory | manifest\n,
prog);
exit(1);
*** ../9/usr/src/usr.sbin/makefs/makefs.h 2012-01-02
19:25:41.0 -0800
--- usr/src/usr.sbin/makefs/makefs.h2012-04-22 22:49:25.0 -0700
***
*** 127,132
--- 127,133
int freeblockpc;/* free block % */
int needswap; /* non-zero if byte swapping needed */
int sectorsize; /* sector size */
+ int sparse; /* sparse image, don't fill it with zeros
*/
void*fs_specific; /* File system specific additions. */
} fsinfo_t;
*** ../9/usr/src/usr.sbin/makefs/ffs.c 2012-01-02 19:25:41.0 -0800
--- usr/src/usr.sbin/makefs/ffs.c 2012-04-30 16:06:01.715365000 -0700
***
*** 493,498
--- 493,508
bufsize = sfs.f_iosize;
#endif
bufrem = fsopts-size;
+
+ if (fsopts-sparse) {
+ if (lseek(fsopts-fd, bufrem - bufsize, SEEK_SET) == -1) {
+ printf (ERROR in lseek. Sparse option
disabled\n);
+ fsopts-sparse = 0;
+ } else {
+ bufrem = bufsize; /* Seek to end and write one
block */
+ }
+ }
+
if (debug DEBUG_FS_CREATE_IMAGE)
printf(
zero-ing image `%s', %lld sectors, using %d byte
chunks\n,
--
Thanks,
Shésha (uint64_t cache, uint16_t FOOD)
{ return 0XCODE; }
___
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
