Re: Binary packages for LibreOffice 3.5 or 3.4
On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: > on 07/05/2012 01:58 Baptiste Daroussin said the following: > > Well for libreoffice on freebsd clang is the official compiler, because > > 4.2.1 is just too old for libreoffice, and I never managed to make it built > > (the 3.5) with gcc from ports. > > What problem are you running into? > I am able to build the latest libreoffice with gcc46. Really with no modification on the ports? Are you sure you are not building it with clang which is forced by default? regards, Bapt pgpblqAHkv5xJ.pgp Description: PGP signature
Re: Binary packages for LibreOffice 3.5 or 3.4
On 05/07/12 11:35, Baptiste Daroussin wrote: > On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: >> on 07/05/2012 01:58 Baptiste Daroussin said the following: >>> Well for libreoffice on freebsd clang is the official compiler, because >>> 4.2.1 is just too old for libreoffice, and I never managed to make it built >>> (the 3.5) with gcc from ports. >> >> What problem are you running into? >> I am able to build the latest libreoffice with gcc46. > > Really with no modification on the ports? > > Are you sure you are not building it with clang which is forced by default? > > regards, > Bapt I realized very late that LibreOffice is unwilling to compile with gcc4.6. The error I faced was introduced by the port net/libcmis, which in my case was built via gcc 4.6 (and doesn't build with CLANG). After building libcmis with legacy gcc 4.2.1, I was able to build editors/libreoffice without problems (as far as the selected options concern). Regards, Oliver ___ 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: Binary packages for LibreOffice 3.5 or 3.4
On Mon, May 07, 2012 at 12:22:21PM +0200, Hartmann, O. wrote: > On 05/07/12 11:35, Baptiste Daroussin wrote: > > On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: > >> on 07/05/2012 01:58 Baptiste Daroussin said the following: > >>> Well for libreoffice on freebsd clang is the official compiler, because > >>> 4.2.1 is just too old for libreoffice, and I never managed to make it > >>> built > >>> (the 3.5) with gcc from ports. > >> > >> What problem are you running into? > >> I am able to build the latest libreoffice with gcc46. > > > > Really with no modification on the ports? > > > > Are you sure you are not building it with clang which is forced by default? > > > > regards, > > Bapt > > > I realized very late that LibreOffice is unwilling to compile with gcc4.6. > > The error I faced was introduced by the port net/libcmis, which in my > case was built via gcc 4.6 (and doesn't build with CLANG). After > building libcmis with legacy gcc 4.2.1, I was able to build > editors/libreoffice without problems (as far as the selected options > concern). > Nice to hear. FYI if avg managed to build libreoffice with 4.6 should be because his whole system should be built (at least the C++ libraries) using gcc 4.6. regards, Bapt pgpUgc4Tk6Nm5.pgp Description: PGP signature
Re: Binary packages for LibreOffice 3.5 or 3.4
2012/5/7 Baptiste Daroussin > On Mon, May 07, 2012 at 12:22:21PM +0200, Hartmann, O. wrote: > > On 05/07/12 11:35, Baptiste Daroussin wrote: > > > On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: > > >> on 07/05/2012 01:58 Baptiste Daroussin said the following: > > >>> Well for libreoffice on freebsd clang is the official compiler, > because > > >>> 4.2.1 is just too old for libreoffice, and I never managed to make > it built > > >>> (the 3.5) with gcc from ports. > > >> > > >> What problem are you running into? > > >> I am able to build the latest libreoffice with gcc46. > > > > > > Really with no modification on the ports? > > > > > > Are you sure you are not building it with clang which is forced by > default? > > > > > > regards, > > > Bapt > > > > > > I realized very late that LibreOffice is unwilling to compile with > gcc4.6. > > > > The error I faced was introduced by the port net/libcmis, which in my > > case was built via gcc 4.6 (and doesn't build with CLANG). After > > building libcmis with legacy gcc 4.2.1, I was able to build > > editors/libreoffice without problems (as far as the selected options > > concern). > > > > Nice to hear. > > FYI if avg managed to build libreoffice with 4.6 should be because his > whole > system should be built (at least the C++ libraries) using gcc 4.6. > > regards, > Bapt > With FreeBSD 9.0-STABLE #140 r229960M I built libreoffice-3.5.2_2 with no problems. Port worked fine. ed ___ 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"
Add GEOM_RAID to GENERIC?
I installed 9.0 on a new desktop that used Intel's on-board RAID yesterday and it worked great. One nit though is I had to remember to kldload geom_raid manually from the shell before starting the install, and to load it from the loader on the first boot after install. The old ataraid(4) was present in GENERIC, so I think it would be fine for GEOM_RAID to be present in GENERIC now (certainly on x86). What do you think? -- 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: ctfmerge core dump
> On 2012/5/6 5:08, b. f. wrote: >> On 5/5/12, Steve Wills wrote: >>> Thanks for the info. I took a look at the dump and see this: >>> >>> % sudo gdb /usr/bin/ctfmerge ctfmerge.core >>> [GDB will not be able to debug user-mode threads: Undefined symbol >>> "td_thr_getxmmregs"] > > Hmm, is the thread debugging broken on amd64 now ? td_thr_getxmmregs > resides > in libthread_db and /usr/src/gnu/usr.bin/gdb/libgdb is complaining about > the missing > symbol. > Maybe or maybe I have done something wrong on my system. FWIW, I do all my builds with debugging enabled. BTW, just to confirm, I was able to work around the original issue once I updated past r235068. I had to disable DTrace build and build and install a new libthr, then was able to re-enable DTrace and everything was fine. Thanks, Steve ___ 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: Add GEOM_RAID to GENERIC?
The only argument that stopped me is that GEOM_RAID is more active in probing for metadata then ataraid. Now it tastes all 6 formats on every provider in system. ataraid tasted only first level and subset of formats depending on controller vendor. While it is possible to do the same, I am not sure it should be done. But may be that all is not really a problem. Most users won't notice few extra requests unless something happen like disk failure, that can make boot to take much longer. 07.05.2012 16:24 пользователь "John Baldwin" написал: > > I installed 9.0 on a new desktop that used Intel's on-board RAID yesterday and > it worked great. One nit though is I had to remember to kldload geom_raid > manually from the shell before starting the install, and to load it from the > loader on the first boot after install. The old ataraid(4) was present in > GENERIC, so I think it would be fine for GEOM_RAID to be present in GENERIC > now (certainly on x86). What do you think? > > -- > 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"
does anyone care about periodic scripts?
Hi all. It seems that patches to periodic scripts have hard time coming into the tree. I personally filed http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/165817 and still there's no move despite change is purely cosmetical and just fixes "right way of things". And this is not just one and only case, pr's are numerous and get minimal to no attention at all: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/165956 http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/30938 How can I assist with this pr's? Whom should I bug to get some answer about them? -- Sphinx of black quartz judge my vow. ___ 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 Friday, May 04, 2012 4:07:24 pm Anton Shterenlikht wrote:
> On Fri, May 04, 2012 at 11:07:59AM -0400, John Baldwin wrote:
> > On Friday, May 04, 2012 7:51:33 am Anton Shterenlikht wrote:
> > > On Thu, May 03, 2012 at 02:46:18PM -0400, John Baldwin wrote:
> > > > On Thursday, May 03, 2012 11:35:19 am Anton Shterenlikht wrote:
> > > > > On Tue, May 01, 2012 at 12:35:26PM +0100, Anton Shterenlikht wrote:
> > > > > > On Mon, Apr 30, 2012 at 08:43:14AM -0400, John Baldwin wrote:
> > > > > > > >
> > > > > > > > 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?
> > > > > >
> > > > > > I reverted back to r231158, built world and generic
> > > > > > kernel (minus all modules, i.e. "option MODULES_OVERRIDE=").
> > > > > > This works, see the verbose boot dmesg at the end.
> > > > > >
> > > > > > I think I'll just do a binary search.
> > > > >
> > > > > I traced it to r233677.
> > > > > The only change from 233676 to 233677 is
> > > > > in /sys/dev/pci/pci.c
> > > > >
> > > > > My kernel is GENERIC with no modules
> > > > > and with various bits removed, e.g. all raid devices
> > > > > and PCI network devices, which I definitely
> > > > > haven't got on this laptop.
> > > > >
> > > > > Below is the verbose boot with r233676.
> > > > > Apparently at the beginning there's also
> > > > > the previous unsuccessful boot with r233677.
> > > > > Is this a new feature? I didn't know the
> > > > > previous dmesg is preserved after a reboot.
> > > > > Anyway, you can see clearly the error with r233677.
> > > > >
> > > > > I guess this is something to do with
> > > > > ata -> ada change?
> > > >
> > > > I don't think so.
> > > >
> > > > Please try just this change:
> > > >
> > > > Index: pci.c
> > > > ===
> > > > --- pci.c (revision 234928)
> > > > +++ pci.c (working copy)
> > > > @@ -2822,10 +2822,14 @@ pci_add_map(device_t bus, device_t dev, int
> > > > reg, s
> > > > * from the parent.
> > > > */
> > > > resource_list_delete(rl, type, reg);
> > > > - } else {
> > > > + start = 0;
> > > > + device_printf(bus,
> > > > + "pci%d:%d:%d:%d bar %#x failed to allocate",
> > > > + pci_get_domain(dev), pci_get_bus(dev),
> > > > pci_get_slot(dev),
> > > > + pci_get_function(dev), reg);
> > > > + } else
> > > > start = rman_get_start(res);
> > > > - pci_write_bar(dev, pm, start);
> > > > - }
> > > > + pci_write_bar(dev, pm, start);
> > > > return (barlen);
> > > > }
> > > >
> > >
> > > That helped, thank you.
> >
> > Bizarre, can you get a regular dmesg with that change applied?
>
Hmm, I missed a newline at the end. :) Looks like this happened twice.
I've added the relevant verbose boot messages from your earlier kernel
below each one:
> pci0: on pcib0
> pci0: pci0:0:20:2 bar 0x10 failed to allocate
> pcib1: at device 1.0 on pci0
found-> vendor=0x1002, dev=0x4383, revid=0x00
domain=0, bus=0, slot=20, func=2
class=04-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords)
lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=10
powerspec 2 supports D0 D3 current D0
map[10]: type Memory, range 64, base 0xcc408000, size 14, enabled
pcib0: matched entry for 0.20.INTA
pcib0: slot 20 INTA hardwired to IRQ 16
> pcib4: at device 20.4 on pci0
> pcib4: failed to allocate initial memory window: 0xcc10-0xcc1f
> pci2: on pcib4
> pci2: pci0:2:4:0 bar 0x10 failed to allocate
> cbb0: irq 20 at device 4.0 on pci2
found-> vendor=0x1180, dev=0x0476, revid=0xb6
domain=0, bus=2, slot=4, func=0
class=06-07-00, hdrtype=0x02, mfdev=1
cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords)
lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x07 (1750 ns)
intpin=a, irq=10
powerspec 2 supports D0 D1 D2 D3 current D0
map[10]: type Memory, range 32, base 0xcc10, size 12, enabled
pcib4: failed to allocate initial memory window (0xcc10-0xcc1f,0x10)
pcib4: matched entry for 2.4.INTA
pcib4: slot 4 INTA hardwired to IRQ 20
cbb0: irq 20 at device 4.0 on pci2
pcib0: allocated type 3 (0xcc50-0xcc5f) for rid 20 of pcib4
pcib4: allocated initial memory window of 0xcc50-0xcc5f
pcib4: allocated memory range (0xcc5
Re: Binary packages for LibreOffice 3.5 or 3.4
On 2012-05-07 12:22, Hartmann, O. wrote:
...
> The error I faced was introduced by the port net/libcmis, which in my
> case was built via gcc 4.6 (and doesn't build with CLANG). After
> building libcmis with legacy gcc 4.2.1, I was able to build
> editors/libreoffice without problems (as far as the selected options
> concern).
Here's a diff for the net/libcmis port, to make it compile with clang.
Can someone from ports please apply this?
The software has some very basic C++ problems, such as non-virtual
destructors, and tends to compile everything with -Werror -Wall
-pedantic, so some errors are expected. :)
Another approach, which takes less modifications, is to just run its
configure script with --disable-error.
Index: net/libcmis/files/patch-configure
===
RCS file: net/libcmis/files/patch-configure
diff -N net/libcmis/files/patch-configure
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/libcmis/files/patch-configure 7 May 2012 18:11:21 -
@@ -0,0 +1,42 @@
+--- configure.orig 2011-10-04 10:45:11.0 +0200
configure 2012-05-07 20:03:00.0 +0200
+@@ -3178,19 +3178,6 @@ else
+
+ fi
+
+-if test x"$enable_werror" != "xno"; then :
+-
+- CFLAGS="$CFLAGS -Werror"
+- CXXFLAGS="$CXXFLAGS -Werror"
+-
+-fi
+-if test x"$GCC" = xyes; then :
+-
+- # Be tough with warnings and produce less careless code
+- CFLAGS="$CFLAGS -Wall -pedantic"
+- CXXFLAGS="$CXXFLAGS -Wall -pedantic"
+-
+-fi
+
+ LIBCMIS_API_VERSION=0.2
+
+@@ -15971,6 +15958,19 @@ fi
+
+ ac_config_files="$ac_config_files Makefile libcmis.pc src/Makefile src/libcmis/Makefile"
+
++if test x"$enable_werror" != "xno"; then :
++
++ CFLAGS="$CFLAGS -Werror"
++ CXXFLAGS="$CXXFLAGS -Werror"
++
++fi
++if test x"$GCC" = xyes; then :
++
++ # Be tough with warnings and produce less careless code
++ CFLAGS="$CFLAGS -Wall -pedantic"
++ CXXFLAGS="$CXXFLAGS -Wall -pedantic"
++
++fi
+ cat >confcache <<\_ACEOF
+ # This file is a shell script that caches the results of configure
+ # tests run on this system so they can be shared between configure
Index: net/libcmis/files/patch-src__libcmis__atom-document.hxx
===
RCS file: net/libcmis/files/patch-src__libcmis__atom-document.hxx
diff -N net/libcmis/files/patch-src__libcmis__atom-document.hxx
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/libcmis/files/patch-src__libcmis__atom-document.hxx 7 May 2012 18:11:21 -
@@ -0,0 +1,11 @@
+--- src/libcmis/atom-document.hxx.orig 2011-10-01 14:26:15.0 +0200
src/libcmis/atom-document.hxx 2012-05-07 20:06:51.0 +0200
+@@ -44,7 +44,7 @@ class AtomDocument : public libcmis::Doc
+ public:
+ AtomDocument( AtomPubSession* session, std::string url );
+ AtomDocument( AtomPubSession* session, xmlNodePtr entryNd );
+-~AtomDocument( );
++virtual ~AtomDocument( );
+
+ // Override content methods
+ virtual FILE* getContent( const char* path = NULL );
Index: net/libcmis/files/patch-src__libcmis__atom-folder.hxx
===
RCS file: net/libcmis/files/patch-src__libcmis__atom-folder.hxx
diff -N net/libcmis/files/patch-src__libcmis__atom-folder.hxx
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/libcmis/files/patch-src__libcmis__atom-folder.hxx 7 May 2012 18:11:21 -
@@ -0,0 +1,11 @@
+--- src/libcmis/atom-folder.hxx.orig 2011-09-30 20:52:01.0 +0200
src/libcmis/atom-folder.hxx 2012-05-07 20:06:29.0 +0200
+@@ -42,7 +42,7 @@ class AtomFolder : public libcmis::Folde
+ public:
+ AtomFolder( AtomPubSession* session, std::string url );
+ AtomFolder( AtomPubSession* session, xmlNodePtr entryNd );
+-~AtomFolder( );
++virtual ~AtomFolder( );
+
+ // virtual pure methods from Folder
+ virtual std::vector< libcmis::CmisObjectPtr > getChildren( );
Index: net/libcmis/files/patch-src__libcmis__session.hxx
===
RCS file: net/libcmis/files/patch-src__libcmis__session.hxx
diff -N net/libcmis/files/patch-src__libcmis__session.hxx
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/libcmis/files/patch-src__libcmis__session.hxx 7 May 2012 18:11:21 -
@@ -0,0 +1,10 @@
+--- src/libcmis/session.hxx.orig 2011-09-30 20:38:39.0 +0200
src/libcmis/session.hxx 2012-05-07 19:23:43.0 +0200
+@@ -36,6 +36,7 @@ namespace libcmis
+ class Session
+ {
+ public:
++virtual ~Session( ) { }
+
+ /** Get the Root folder of the repository
+ */
___
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_arena.c:182: Failed assertion: "p[i] == 0"
> On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
>> After applying Dimitry Andric's patches to contrib/jemalloc and
>> replacing
>> /usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
>> head as of 234536:
>>
>> FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797
>> 234536M: Sat Apr 21 10:23:33 PDT 2012
>> r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
>>
>> However, as I was copying a /usr/obj hierarchy via tar -- e.g.:
>>
>> root@freebeast:/common/home/david # (cd /var/tmp && rm -fr obj && mkdir
>> obj) && (cd /usr && tar cpf - obj) | (cd /var/tmp && tar xpf -)
>>
>> it ran for a while, then:
>>
>> : jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
>> Abort (core dumped)
>> root@freebeast:/common/home/david # echo $?
>> 134
>> root@freebeast:/common/home/david # ls -lTio *.core
>> ls: No match.
>> root@freebeast:/common/home/david #
>>
>> So ... no core file, apparently.
>>
>> freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
>> jemalloc_arena.c
>> freebeast(10.0-C)[3]
>>
>> No file named "jemalloc_arena.c", either.
>>
>> But contrib/jemalloc/src/arena.c contains a function,
>> arena_chunk_validate_zeroed():
>>
>>175 static inline void
>>176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
>>177 {
>>178 size_t i;
>>179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind
>> << LG_PAGE));
>>180
>>181 for (i = 0; i < PAGE / sizeof(size_t); i++)
>>182 assert(p[i] == 0);
>>183 }
>>
>> Thoughts?
>
> I received a similar report yesterday in the context of filezilla, but
> didn't get as far as reproducing it. I think the problem is in
> chunk_alloc_dss(), which dangerously claims that newly allocated memory is
> zeroed. It looks like I formalized this bad assumption in early 2010,
> though the bug existed before that. It's a bigger deal now because sbrk()
> is preferred over mmap(), so the bug has languished for a couple of years.
> I'll get a fix committed today (and revert the order of preference
> between sbrk() and mmap()).
>
> By the way, I wonder why not everyone hits this (I don't).
>
I just now hit the same issue while using ports tinderbox. It was calling
tar during the "makeJail" tinderbox subcommand and gave the same error as
in the subject. Funny thing is I had run the same command (on a different
"jail") right before this and didn't get the error. What's the status of
this? Should I set MALLOC_PRODUCTION=yes in /etc/make.conf, rebuild world
and forget about it?
Steve
___
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: panic, seems related to r234386
On 05/06/2012 15:19, Sergey Kandaurov wrote:
> On 7 May 2012 01:54, Doug Barton wrote:
>> I got this with today's current, previous (working) kernel is r232719.
>>
>> panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx
>> @ /frontier/svn/head/sys/kern/vfs_subr.c:4595
...
> Please try this patch.
>
> Index: fs/ext2fs/ext2_vfsops.c
> ===
> --- fs/ext2fs/ext2_vfsops.c (revision 235108)
> +++ fs/ext2fs/ext2_vfsops.c (working copy)
> @@ -830,7 +830,6 @@
> /*
> * Write back each (modified) inode.
> */
> - MNT_ILOCK(mp);
> loop:
> MNT_VNODE_FOREACH_ALL(vp, mp, mvp) {
> if (vp->v_type == VNON) {
>
Didn't help, sorry. I put 234385 through some pretty heavy load
yesterday, and everything was fine. As soon as I move up to 234386, the
panic triggered again. So I cleaned everything up, applied your patch,
built a kernel from scratch, and rebooted. It was Ok for a few seconds
after boot, then panic'ed again, I think in a different place, but I'm
not sure because subsequent attempts to fsck the file systems caused new
panics which overwrote the old ones before they could be saved.
I'd like to see this changed backed out until the proponents can
thoroughly regression test all of the file systems that it affects.
FWIW, the thing that seems to be triggering the panic is that I have the
following setup:
/dev/ad0s2a on / (ufs, local)
/dev/ad3s2 on /home (ext2fs, local)
/etc/namedb is a symlink to /home/named/etc/namedb. When I booted 234386
named failed to start because the symlink was corrupted. When I
recreated the symlink and then started named, it panic'ed.
hth,
Doug
--
This .signature sanitized for your protection
___
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: Binary packages for LibreOffice 3.5 or 3.4
On Mon, May 07, 2012 at 08:22:16PM +0200, Dimitry Andric wrote: > On 2012-05-07 12:22, Hartmann, O. wrote: > ... > > The error I faced was introduced by the port net/libcmis, which in my > > case was built via gcc 4.6 (and doesn't build with CLANG). After > > building libcmis with legacy gcc 4.2.1, I was able to build > > editors/libreoffice without problems (as far as the selected options > > concern). > > Here's a diff for the net/libcmis port, to make it compile with clang. > Can someone from ports please apply this? > > The software has some very basic C++ problems, such as non-virtual > destructors, and tends to compile everything with -Werror -Wall > -pedantic, so some errors are expected. :) > > Another approach, which takes less modifications, is to just run its > configure script with --disable-error. Thanks for the patch, your patch break the build with gcc 4.2.1, I'll try to fix it otherwise I'll run it disabling --disable-error. regards, Bapt pgp4TZqhdx5AR.pgp Description: PGP signature
Re: Binary packages for LibreOffice 3.5 or 3.4
On Mon, May 07, 2012 at 08:22:16PM +0200, Dimitry Andric wrote: > On 2012-05-07 12:22, Hartmann, O. wrote: > ... > > The error I faced was introduced by the port net/libcmis, which in my > > case was built via gcc 4.6 (and doesn't build with CLANG). After > > building libcmis with legacy gcc 4.2.1, I was able to build > > editors/libreoffice without problems (as far as the selected options > > concern). > > Here's a diff for the net/libcmis port, to make it compile with clang. > Can someone from ports please apply this? > > The software has some very basic C++ problems, such as non-virtual > destructors, and tends to compile everything with -Werror -Wall > -pedantic, so some errors are expected. :) > > Another approach, which takes less modifications, is to just run its > configure script with --disable-error. Committed thank you, regards, Bapt pgp7zDQg1hcXW.pgp Description: PGP signature
Re: panic, seems related to r234386
On Mon, May 07, 2012 at 12:28:41PM -0700, Doug Barton wrote:
> On 05/06/2012 15:19, Sergey Kandaurov wrote:
> > On 7 May 2012 01:54, Doug Barton wrote:
> >> I got this with today's current, previous (working) kernel is r232719.
> >>
> >> panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx
> >> @ /frontier/svn/head/sys/kern/vfs_subr.c:4595
>
> ...
>
> > Please try this patch.
> >
> > Index: fs/ext2fs/ext2_vfsops.c
> > ===
> > --- fs/ext2fs/ext2_vfsops.c (revision 235108)
> > +++ fs/ext2fs/ext2_vfsops.c (working copy)
> > @@ -830,7 +830,6 @@
> > /*
> > * Write back each (modified) inode.
> > */
> > - MNT_ILOCK(mp);
> > loop:
> > MNT_VNODE_FOREACH_ALL(vp, mp, mvp) {
> > if (vp->v_type == VNON) {
> >
>
> Didn't help, sorry. I put 234385 through some pretty heavy load
> yesterday, and everything was fine. As soon as I move up to 234386, the
> panic triggered again. So I cleaned everything up, applied your patch,
> built a kernel from scratch, and rebooted. It was Ok for a few seconds
> after boot, then panic'ed again, I think in a different place, but I'm
> not sure because subsequent attempts to fsck the file systems caused new
> panics which overwrote the old ones before they could be saved.
>
Another MNT_ILOCK was hiding few lines below, try this patch:
http://student.agh.edu.pl/~mjguzik/patches/ext2fs-ilock.patch
I've tested this a bit and I believe this fixes your problem.
--
Mateusz Guzik
___
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 Mon, May 07, 2012 at 10:39:51AM -0400, John Baldwin wrote:
> On Friday, May 04, 2012 4:07:24 pm Anton Shterenlikht wrote:
> > On Fri, May 04, 2012 at 11:07:59AM -0400, John Baldwin wrote:
> > > On Friday, May 04, 2012 7:51:33 am Anton Shterenlikht wrote:
> > > > On Thu, May 03, 2012 at 02:46:18PM -0400, John Baldwin wrote:
> > > > > On Thursday, May 03, 2012 11:35:19 am Anton Shterenlikht wrote:
> > > > > > On Tue, May 01, 2012 at 12:35:26PM +0100, Anton Shterenlikht wrote:
> > > > > > > On Mon, Apr 30, 2012 at 08:43:14AM -0400, John Baldwin wrote:
> > > > > > > > >
> > > > > > > > > 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?
> > > > > > >
> > > > > > > I reverted back to r231158, built world and generic
> > > > > > > kernel (minus all modules, i.e. "option MODULES_OVERRIDE=").
> > > > > > > This works, see the verbose boot dmesg at the end.
> > > > > > >
> > > > > > > I think I'll just do a binary search.
> > > > > >
> > > > > > I traced it to r233677.
> > > > > > The only change from 233676 to 233677 is
> > > > > > in /sys/dev/pci/pci.c
> > > > > >
> > > > > > My kernel is GENERIC with no modules
> > > > > > and with various bits removed, e.g. all raid devices
> > > > > > and PCI network devices, which I definitely
> > > > > > haven't got on this laptop.
> > > > > >
> > > > > > Below is the verbose boot with r233676.
> > > > > > Apparently at the beginning there's also
> > > > > > the previous unsuccessful boot with r233677.
> > > > > > Is this a new feature? I didn't know the
> > > > > > previous dmesg is preserved after a reboot.
> > > > > > Anyway, you can see clearly the error with r233677.
> > > > > >
> > > > > > I guess this is something to do with
> > > > > > ata -> ada change?
> > > > >
> > > > > I don't think so.
> > > > >
> > > > > Please try just this change:
> > > > >
> > > > > Index: pci.c
> > > > > ===
> > > > > --- pci.c (revision 234928)
> > > > > +++ pci.c (working copy)
> > > > > @@ -2822,10 +2822,14 @@ pci_add_map(device_t bus, device_t dev, int
> > > > > reg, s
> > > > >* from the parent.
> > > > >*/
> > > > > resource_list_delete(rl, type, reg);
> > > > > - } else {
> > > > > + start = 0;
> > > > > + device_printf(bus,
> > > > > + "pci%d:%d:%d:%d bar %#x failed to allocate",
> > > > > + pci_get_domain(dev), pci_get_bus(dev),
> > > > > pci_get_slot(dev),
> > > > > + pci_get_function(dev), reg);
> > > > > + } else
> > > > > start = rman_get_start(res);
> > > > > - pci_write_bar(dev, pm, start);
> > > > > - }
> > > > > + pci_write_bar(dev, pm, start);
> > > > > return (barlen);
> > > > > }
> > > > >
> > > >
> > > > That helped, thank you.
> > >
> > > Bizarre, can you get a regular dmesg with that change applied?
> >
>
> Hmm, I missed a newline at the end. :) Looks like this happened twice.
> I've added the relevant verbose boot messages from your earlier kernel
> below each one:
>
> > pci0: on pcib0
> > pci0: pci0:0:20:2 bar 0x10 failed to allocate
> > pcib1: at device 1.0 on pci0
>
> found-> vendor=0x1002, dev=0x4383, revid=0x00
> domain=0, bus=0, slot=20, func=2
> class=04-03-00, hdrtype=0x00, mfdev=0
> cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> intpin=a, irq=10
> powerspec 2 supports D0 D3 current D0
> map[10]: type Memory, range 64, base 0xcc408000, size 14, enabled
> pcib0: matched entry for 0.20.INTA
> pcib0: slot 20 INTA hardwired to IRQ 16
>
> > pcib4: at device 20.4 on pci0
> > pcib4: failed to allocate initial memory window: 0xcc10-0xcc1f
> > pci2: on pcib4
> > pci2: pci0:2:4:0 bar 0x10 failed to allocate
> > cbb0: irq 20 at device 4.0 on pci2
>
> found-> vendor=0x1180, dev=0x0476, revid=0xb6
> domain=0, bus=2, slot=4, func=0
> class=06-07-00, hdrtype=0x02, mfdev=1
> cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x07 (1750 ns)
> intpin=a, irq=10
> powerspec 2 supports D0 D1 D2 D3 current D0
> map[10]: type Memory, range 32, base 0xcc10, size 12, enabled
> pcib4: failed to allocate initial memory window
> (0xcc10-0xcc1f,0x10)
>
Re: panic, seems related to r234386
On 05/07/2012 13:11, Mateusz Guzik wrote: > On Mon, May 07, 2012 at 12:28:41PM -0700, Doug Barton wrote: >> On 05/06/2012 15:19, Sergey Kandaurov wrote: >>> On 7 May 2012 01:54, Doug Barton wrote: I got this with today's current, previous (working) kernel is r232719. panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx @ /frontier/svn/head/sys/kern/vfs_subr.c:4595 >> >> ... >> >>> Please try this patch. Ok, so far so good. Again, thanks for the quick response. I'm stress-testing my ext2fs partitions a bit atm, and everything seems Ok. I'll let you know if I run into any problems. So my next question is, does removing those locks present any risks? Should they be replaced by different locks, or were they just safety belts to start with? Finally, should my next step be to advance to the latest current + your patch and see how I go from there? Doug -- This .signature sanitized for your protection ___ 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_arena.c:182: Failed assertion: "p[i] == 0"
On May 7, 2012, at 12:19 PM, Steve Wills wrote:
>> On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
>>> After applying Dimitry Andric's patches to contrib/jemalloc and
>>> replacing
>>> /usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
>>> head as of 234536:
>>>
>>> FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797
>>> 234536M: Sat Apr 21 10:23:33 PDT 2012
>>> r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
>>>
>>> However, as I was copying a /usr/obj hierarchy via tar -- e.g.:
>>>
>>> root@freebeast:/common/home/david # (cd /var/tmp && rm -fr obj && mkdir
>>> obj) && (cd /usr && tar cpf - obj) | (cd /var/tmp && tar xpf -)
>>>
>>> it ran for a while, then:
>>>
>>> : jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
>>> Abort (core dumped)
>>> root@freebeast:/common/home/david # echo $?
>>> 134
>>> root@freebeast:/common/home/david # ls -lTio *.core
>>> ls: No match.
>>> root@freebeast:/common/home/david #
>>>
>>> So ... no core file, apparently.
>>>
>>> freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
>>> jemalloc_arena.c
>>> freebeast(10.0-C)[3]
>>>
>>> No file named "jemalloc_arena.c", either.
>>>
>>> But contrib/jemalloc/src/arena.c contains a function,
>>> arena_chunk_validate_zeroed():
>>>
>>> 175 static inline void
>>> 176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
>>> 177 {
>>> 178 size_t i;
>>> 179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind
>>> << LG_PAGE));
>>> 180
>>> 181 for (i = 0; i < PAGE / sizeof(size_t); i++)
>>> 182 assert(p[i] == 0);
>>> 183 }
>>>
>>> Thoughts?
>>
>> I received a similar report yesterday in the context of filezilla, but
>> didn't get as far as reproducing it. I think the problem is in
>> chunk_alloc_dss(), which dangerously claims that newly allocated memory is
>> zeroed. It looks like I formalized this bad assumption in early 2010,
>> though the bug existed before that. It's a bigger deal now because sbrk()
>> is preferred over mmap(), so the bug has languished for a couple of years.
>> I'll get a fix committed today (and revert the order of preference
>> between sbrk() and mmap()).
>>
>> By the way, I wonder why not everyone hits this (I don't).
>
> I just now hit the same issue while using ports tinderbox. It was calling
> tar during the "makeJail" tinderbox subcommand and gave the same error as
> in the subject. Funny thing is I had run the same command (on a different
> "jail") right before this and didn't get the error. What's the status of
> this? Should I set MALLOC_PRODUCTION=yes in /etc/make.conf, rebuild world
> and forget about it?
How recent is your system? This problem should have been fixed by r234569, so
if you're still seeing problems after that revision, there's another problem we
need to figure out. (By the way, it's possible for an application to trigger
this assertion, but unlikely.)
Thanks,
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: Binary packages for LibreOffice 3.5 or 3.4
on 07/05/2012 12:35 Baptiste Daroussin said the following: > On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: >> on 07/05/2012 01:58 Baptiste Daroussin said the following: >>> Well for libreoffice on freebsd clang is the official compiler, because >>> 4.2.1 is just too old for libreoffice, and I never managed to make it built >>> (the 3.5) with gcc from ports. >> >> What problem are you running into? >> I am able to build the latest libreoffice with gcc46. > > Really with no modification on the ports? Yes. (OK, I lied, see below) > Are you sure you are not building it with clang which is forced by default? Yes. I set WITH_GCC in make.conf. Some notes: - I have boost 1.48 via the patches from the boost port maintainer (long overdue to be committed) - on one system I build (almost) all ports with gcc46 (base system is built in a standard fashion) - on another system I build (almost) all ports with base gcc (except, obviously, those ports that have USE_GCC=4.6[+]) And, oh, almost forgot, I had to manually apply the attached patch in cppunit/ subdirectory on FreeBSD 10. It seems that the source code in question is extracted during build, so it is not possible to apply the patch during normal patch target. The patch is for the well-known FreeBSD1 vs FreeBSD10 confusion in autotools. -- Andriy Gapon ___ 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: Binary packages for LibreOffice 3.5 or 3.4
On Tue, May 08, 2012 at 08:10:25AM +0300, Andriy Gapon wrote: > on 07/05/2012 12:35 Baptiste Daroussin said the following: > > On Mon, May 07, 2012 at 09:20:06AM +0300, Andriy Gapon wrote: > >> on 07/05/2012 01:58 Baptiste Daroussin said the following: > >>> Well for libreoffice on freebsd clang is the official compiler, because > >>> 4.2.1 is just too old for libreoffice, and I never managed to make it > >>> built > >>> (the 3.5) with gcc from ports. > >> > >> What problem are you running into? > >> I am able to build the latest libreoffice with gcc46. > > > > Really with no modification on the ports? > > Yes. (OK, I lied, see below) > > > Are you sure you are not building it with clang which is forced by default? > > Yes. I set WITH_GCC in make.conf. > > Some notes: > - I have boost 1.48 via the patches from the boost port maintainer (long > overdue > to be committed) > - on one system I build (almost) all ports with gcc46 (base system is built > in a > standard fashion) > - on another system I build (almost) all ports with base gcc (except, > obviously, > those ports that have USE_GCC=4.6[+]) > > And, oh, almost forgot, I had to manually apply the attached patch in cppunit/ > subdirectory on FreeBSD 10. It seems that the source code in question is > extracted during build, so it is not possible to apply the patch during normal > patch target. The patch is for the well-known FreeBSD1 vs FreeBSD10 confusion > in autotools. Yes but only with gcc46 because cppunit needs the same libstdc++ as libreoffice so with gcc 4.6 is needs to be built with bundled, while it is unbundled with clang. regards, Bapt pgpavsUkyb9vy.pgp Description: PGP signature
Re: panic, seems related to r234386
On 8 May 2012 05:14, Doug Barton wrote: > On 05/07/2012 13:11, Mateusz Guzik wrote: >> On Mon, May 07, 2012 at 12:28:41PM -0700, Doug Barton wrote: >>> On 05/06/2012 15:19, Sergey Kandaurov wrote: On 7 May 2012 01:54, Doug Barton wrote: > I got this with today's current, previous (working) kernel is r232719. > > panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx > @ /frontier/svn/head/sys/kern/vfs_subr.c:4595 >>> >>> ... >>> Please try this patch. > > Ok, so far so good. Again, thanks for the quick response. I'm > stress-testing my ext2fs partitions a bit atm, and everything seems Ok. > I'll let you know if I run into any problems. > > So my next question is, does removing those locks present any risks? > Should they be replaced by different locks, or were they just safety > belts to start with? Unlike in the previously used macro MNT_VNODE_FOREACH_ABORT_ILOCKED(), the currently used macro MNT_VNODE_FOREACH_ALL_ABORT() manages mount mutexes itself so you don't need to mess with them. The locking is there, it's just hidden behind macros. > > Finally, should my next step be to advance to the latest current + your > patch and see how I go from there? Yep, so that patches will be tested before they go to head. -- wbr, pluknet ___ 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: Binary packages for LibreOffice 3.5 or 3.4
On 05/07/12 22:08, Baptiste Daroussin wrote: > On Mon, May 07, 2012 at 08:22:16PM +0200, Dimitry Andric wrote: >> On 2012-05-07 12:22, Hartmann, O. wrote: >> ... >>> The error I faced was introduced by the port net/libcmis, which in my >>> case was built via gcc 4.6 (and doesn't build with CLANG). After >>> building libcmis with legacy gcc 4.2.1, I was able to build >>> editors/libreoffice without problems (as far as the selected options >>> concern). >> >> Here's a diff for the net/libcmis port, to make it compile with clang. >> Can someone from ports please apply this? >> >> The software has some very basic C++ problems, such as non-virtual >> destructors, and tends to compile everything with -Werror -Wall >> -pedantic, so some errors are expected. :) >> >> Another approach, which takes less modifications, is to just run its >> configure script with --disable-error. > Committed thank you, > > regards, > Bapt Thank you very much. signature.asc Description: OpenPGP digital signature
Re: Binary packages for LibreOffice 3.5 or 3.4
On 05/07/12 20:22, Dimitry Andric wrote: > On 2012-05-07 12:22, Hartmann, O. wrote: > ... >> The error I faced was introduced by the port net/libcmis, which in my >> case was built via gcc 4.6 (and doesn't build with CLANG). After >> building libcmis with legacy gcc 4.2.1, I was able to build >> editors/libreoffice without problems (as far as the selected options >> concern). > > Here's a diff for the net/libcmis port, to make it compile with clang. > Can someone from ports please apply this? > > The software has some very basic C++ problems, such as non-virtual > destructors, and tends to compile everything with -Werror -Wall > -pedantic, so some errors are expected. :) > > Another approach, which takes less modifications, is to just run its > configure script with --disable-error. Thank you very much. This seems to work for me, hope others will see the same progress. On all suspected and reported boxes, LibreOffice now compiles with CLANG. I consider this a s a positive sign for all the work of the team has done, thanks again! And even for the patience with me/us "users". Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: Binary packages for LibreOffice 3.5 or 3.4
> I'd like to ask whether there are sites were binary packages could be > downloaded from and are there any experiences with installing them on > either 9-STABLE or 10-CURRENT? We (BSDForen.de) have unofficial packages build by the community at http://wiki.bsdforen.de/anwendungen/libreoffice_aus_inoffiziellen_paketen While the page is written in german, english (en_GB) packages are available. 7-STABLE, 8-STABE and 9-STABLE are covered. -- Homepage: www.yamagi.org XMPP: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB pgpSINVaKU9ZU.pgp Description: PGP signature
Re: Binary packages for LibreOffice 3.5 or 3.4
on 08/05/2012 08:51 Baptiste Daroussin said the following: > Yes but only with gcc46 because cppunit needs the same libstdc++ as > libreoffice so with gcc 4.6 is needs to be built with bundled, while it is > unbundled with clang. So the "internal" cppunit was probably not needed in the environment where the "external" cppunit was also built with gcc46. But I guess that there is no good way to detect that. P.S. A hackish way would be to use something like objdump to check for required versions of GLIBCXX in libcppunit*.so. But that's too hackish and too much trouble, I guess. But, hm, it looks like libcppunit-1.12.so doesn't require any newer symbols from libstdc++ beyond what's provided by base gcc's library: $ objdump -p -w /usr/local/lib/libcppunit-1.12.so.1 ... Dynamic Section: NEEDED libstdc++.so.6 NEEDED libm.so.5 NEEDED libc.so.7 NEEDED libgcc_s.so.1 SONAME libcppunit-1.12.so.1 RPATH /usr/local/lib/gcc46 ... Version References: required from libgcc_s.so.1: 0x0b792650 0x00 07 GCC_3.0 required from libm.so.5: 0x077a28b0 0x00 05 FBSD_1.0 required from libc.so.7: 0x077a28b0 0x00 03 FBSD_1.0 required from libstdc++.so.6: 0x02297f89 0x00 06 GLIBCXX_3.4.9 0x056bafd3 0x00 04 CXXABI_1.3 0x08922974 0x00 02 GLIBCXX_3.4 Ref: http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html -- Andriy Gapon ___ 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"
