Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On 09/10/13 07:20, hiren panchasara wrote:
On Sat, Sep 7, 2013 at 5:10 AM, olli hauer mailto:oha...@gmx.de>> wrote:
There are 13 ports using --with-iconv=${LOCALBASE}
devel/apr1
devel/apr2
devel/git
irc/epic5
lang/gauche
net-mgmt/ettercap
net/ssltunnel-client
net/yaz
net/zebra-server
textproc/libxml2
textproc/py-libxml2
www/apache22
www/apache24
and devel/glib20, print/ghostscript8, print/ghostscript9 using
--with-libiconv=gnu
--with-libiconv=native
--with-libiconv=no
--with-libiconv=no
I am hitting following failure while building devel/glib20
gconvert.c:66:2: error: GNU libiconv not in use but included iconv.h
is from libiconv
#error GNU libiconv not in use but included iconv.h is from libiconv
How do I get past this?
Looks like you have some leftovers from the libiconv port. Have you
removed it? can you give the output of ls /usr/local/include/iconv.h?
What is the output if "head /usr/include/iconv.h"?
% uname -a
FreeBSD flymockour-l7.corp.yahoo.com
10.0-CURRENT FreeBSD 10.0-CURRENT
#2 r255423M: Mon Sep 9 12:29:22 PDT 2013
That M in the revision number indicates you're using a modified
checkout, May I ask which modifications you have in your source tree?
--
Guido Falsi
___
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: [PATCH] mtree should not output size if the file is not a regular file
Am 10.09.2013 01:51, schrieb Christos Zoulas: > On Sep 10, 1:21am, d...@des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) wrote: > -- Subject: Re: [PATCH] mtree should not output size if the file is not a reg > > | Roll a large tarball (e.g. a complete FreeBSD installation). Copy it to > | different machines with different filesystems. Untar and run mtree on > | the result. Notice that you get different output on each machine > | because they report different sizes for directories; one might report > | the actual on-disk size (which might vary depending on past contents) > | while the other might report the number of entries. > > Yes, I agree. I would like to note that the current NetBSD code looks like: > > if (keys & F_SIZE && > (flavor != F_NETBSD6 || S_ISREG(p->fts_statp->st_mode))) > > which means that F_NETBSD6 did not print this, and we recently changed > it to print the size for compatibility with F_FREEBSD9... We also made > the default F_MTREE format to print the size. So I guess the thing to > do is change the code to: > > if (keys & F_SIZE && > (flavor == F_FREEBSD9 || S_ISREG(p->fts_statp->st_mode))) Uh, does that flavor == F_FREEBSD9 solve a real problem? Or is it just to reflect some syntax without proper semantics? Or is this just gratuitious because someone else does nonsense we need to do it, too? Or is it required to cater for expectations on the other end (when reading such an mtree description)? If not, let's just drop the size where it's meaningless. It's meant for the next major update, after all. If necessary, bump the OSREVISION. ___ 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: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On Sat, Sep 7, 2013 at 5:10 AM, olli hauer wrote:
> There are 13 ports using --with-iconv=${LOCALBASE}
> devel/apr1
> devel/apr2
> devel/git
> irc/epic5
> lang/gauche
> net-mgmt/ettercap
> net/ssltunnel-client
> net/yaz
> net/zebra-server
> textproc/libxml2
> textproc/py-libxml2
> www/apache22
> www/apache24
>
>
> and devel/glib20, print/ghostscript8, print/ghostscript9 using
> --with-libiconv=gnu
> --with-libiconv=native
> --with-libiconv=no
> --with-libiconv=no
>
I am hitting following failure while building devel/glib20
gconvert.c:66:2: error: GNU libiconv not in use but included iconv.h is
from libiconv
#error GNU libiconv not in use but included iconv.h is from libiconv
How do I get past this?
% uname -a
FreeBSD flymockour-l7.corp.yahoo.com 10.0-CURRENT FreeBSD 10.0-CURRENT #2
r255423M: Mon Sep 9 12:29:22 PDT 2013
r...@flymockour-l7.corp.yahoo.com:/usr/obj/usr/home/hirenp/head/sys/GENERIC
amd64
% cat /etc/src.conf
WITH_LIBICONV_COMPAT=y
BOOT_COMCONSOLE_SPEED=115200
PORTS_MODULES=x11/nvidia-driver
cheers,
Hiren
>
> Unfortunately Uses/iconv.mk defines only --with-libiconv(-prefix).
>
> If Uses/iconv.mk can be extended with something like ICON_PATH, then
> the 13 ports can be changed quickly to use the right iconv.
>
> --
> Regards,
> olli
> ___
> 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: [PATCH] mtree should not output size if the file is not a regular file
On Sep 9, 2013, at 4:51 PM, Christos Zoulas wrote: > On Sep 10, 1:21am, d...@des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) wrote: > -- Subject: Re: [PATCH] mtree should not output size if the file is not a reg > > | Roll a large tarball (e.g. a complete FreeBSD installation). Copy it to > | different machines with different filesystems. Untar and run mtree on > | the result. Notice that you get different output on each machine > | because they report different sizes for directories; one might report > | the actual on-disk size (which might vary depending on past contents) > | while the other might report the number of entries. > > Yes, I agree. I would like to note that the current NetBSD code looks like: > >if (keys & F_SIZE && > (flavor != F_NETBSD6 || S_ISREG(p->fts_statp->st_mode))) > > which means that F_NETBSD6 did not print this, and we recently changed > it to print the size for compatibility with F_FREEBSD9... We also made > the default F_MTREE format to print the size. So I guess the thing to > do is change the code to: > >if (keys & F_SIZE && > (flavor == F_FREEBSD9 || S_ISREG(p->fts_statp->st_mode))) DES is right: size should just be omitted for non-regular files. Bug-for-bug compatibility can be taken too far. I prefer Xin's original patch. Tim ___ 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: [PATCH] mtree should not output size if the file is not a regular file
On Sep 10, 1:21am, d...@des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) wrote: -- Subject: Re: [PATCH] mtree should not output size if the file is not a reg | Roll a large tarball (e.g. a complete FreeBSD installation). Copy it to | different machines with different filesystems. Untar and run mtree on | the result. Notice that you get different output on each machine | because they report different sizes for directories; one might report | the actual on-disk size (which might vary depending on past contents) | while the other might report the number of entries. Yes, I agree. I would like to note that the current NetBSD code looks like: if (keys & F_SIZE && (flavor != F_NETBSD6 || S_ISREG(p->fts_statp->st_mode))) which means that F_NETBSD6 did not print this, and we recently changed it to print the size for compatibility with F_FREEBSD9... We also made the default F_MTREE format to print the size. So I guess the thing to do is change the code to: if (keys & F_SIZE && (flavor == F_FREEBSD9 || S_ISREG(p->fts_statp->st_mode))) christos ___ 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: [PATCH] mtree should not output size if the file is not a regular file
Christos Zoulas writes: > Xin Li writes: > > I think it doesn't make sense to emit size information for non-regular > > files like directories, symlinks, etc. although both our and NetBSD's > > mtree would emit it. > We could change that, but what's the harm? Roll a large tarball (e.g. a complete FreeBSD installation). Copy it to different machines with different filesystems. Untar and run mtree on the result. Notice that you get different output on each machine because they report different sizes for directories; one might report the actual on-disk size (which might vary depending on past contents) while the other might report the number of entries. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: [PATCH] mtree should not output size if the file is not a regular file
On Sep 9, 2:35pm, delp...@delphij.net (Xin Li) wrote: -- Subject: [PATCH] mtree should not output size if the file is not a regular | Hi, | | I think it doesn't make sense to emit size information for non-regular | files like directories, symlinks, etc. although both our and NetBSD's | mtree would emit it. We could change that, but what's the harm? christos ___ 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: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
On Tue, 2013-09-10 at 00:42 +0200, O. Hartmann wrote: > On Tue, 10 Sep 2013 00:24:05 +0300 > Ivan Klymenko wrote: > > > В Mon, 9 Sep 2013 23:17:13 +0200 > > "O. Hartmann" пишет: > > > > > On Tue, 10 Sep 2013 00:02:37 +0300 > > > Ivan Klymenko wrote: > > > > > > > В Mon, 9 Sep 2013 22:37:48 +0200 > > > > "O. Hartmann" пишет: > > > > > > > > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76: > > > > > error: too few arguments to function call, expected 10, have 9 > > > > > cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^ > > > > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int > > > > > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > > > > > vm_size_t, > > > > > > > > Try the following changes: > > > > int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr, > > > > --- cbAllocated, TRUE, VM_PROT_ALL, > > > > VM_PROT_ALL, 0); +++ cbAllocated, 0, > > > > VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0); > > > > > > > > for Nvidia driver need to make similar changes... > > > The man page of vm_map_find() says the last parameter is of int, > > > named int cow. On the hurry, I didn't find any explanation of that > > > parameter. Setting it to "0" (zero) also in the nvidia_subr.c makes > > > the driver compile again. > > > > > > But simply filling in a int zero is a bit strange without knowing > > > what to do, isn't it? > > > > > > Thanks anyway, > > > > > > Oliver > > > > This commit you to find an appropriate example ... > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=291456+0+current/svn-src-head > > And in this case, the driver Nvidia really need to specify 0 in place > > of the sixth argument ... > > but I'm not sure at 100% :) > > I have a patch attached for the x11/nvidia-driver Makefile. It doesn't > work and I loose hairs due to not knowing why. > > When issuing the following command sequence on the console: > > cd /usr/ports/x11/nvidia-driver > make clean extract > sed -i -e '/(VM_PROT_READ | VM_PROT_WRITE), 0);$/s/0);$/0, 0);/g' \ > work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c > > > and check then line 835 (the corrupt one) in file > work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c, > > I see this BEFORE: > > status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE), > &virtual_address, size, VMFS_ANY_SPACE, > (VM_PROT_READ | VM_PROT_WRITE), > ===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0); > > > and I see this AFTER the sed'ed replacement: > > status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE), > &virtual_address, size, VMFS_ANY_SPACE, > (VM_PROT_READ | VM_PROT_WRITE), > ===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0, 0); > > BUT: Using the patch (see attached, please apply to > x11/nvidia-driver/Makefile) gives me an error in x11/nvidia-driver: > > make clean patch > > ===> Cleaning for nvidia-driver-325.15 > ===> License NVIDIA accepted by the user > ===> Found saved configuration for nvidia-driver-325.08_1 > ===> nvidia-driver-325.15 depends on file: /usr/local/sbin/pkg - found > ===> Fetching all distfiles required by nvidia-driver-325.15 for > building > ===> Extracting for nvidia-driver-325.15 > => SHA256 Checksum OK for NVIDIA-FreeBSD-x86_64-325.15.tar.gz. > ===> Patching for nvidia-driver-325.15 > sed: 1: "/(VM_PROT_READ | VM_PRO ...": invalid command code 0 > *** Error code 1 > > The Shell/make should be able to substitute within a single-quotet > command to sed, but the error message reports differently. > > Do not be confused about the driver revision I use. I tried the > official one (319.XX) as well and it is not working the very same way > and the patch won't either. > > Oliver I don't know about the sed error, but I think the change you're trying to make is wrong. The new '0' parameter to vm_map_find() isn't added at the end, it goes after the size parameter. -- Ian ___ 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: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
On Tue, 10 Sep 2013 00:24:05 +0300
Ivan Klymenko wrote:
> В Mon, 9 Sep 2013 23:17:13 +0200
> "O. Hartmann" пишет:
>
> > On Tue, 10 Sep 2013 00:02:37 +0300
> > Ivan Klymenko wrote:
> >
> > > В Mon, 9 Sep 2013 22:37:48 +0200
> > > "O. Hartmann" пишет:
> > > >
> > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76:
> > > > error: too few arguments to function call, expected 10, have 9
> > > > cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^
> > > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int
> > > > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *,
> > > > vm_size_t,
> > >
> > > Try the following changes:
> > > int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr,
> > > --- cbAllocated, TRUE, VM_PROT_ALL,
> > > VM_PROT_ALL, 0); +++ cbAllocated, 0,
> > > VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0);
> > >
> > > for Nvidia driver need to make similar changes...
> > The man page of vm_map_find() says the last parameter is of int,
> > named int cow. On the hurry, I didn't find any explanation of that
> > parameter. Setting it to "0" (zero) also in the nvidia_subr.c makes
> > the driver compile again.
> >
> > But simply filling in a int zero is a bit strange without knowing
> > what to do, isn't it?
> >
> > Thanks anyway,
> >
> > Oliver
>
> This commit you to find an appropriate example ...
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=291456+0+current/svn-src-head
> And in this case, the driver Nvidia really need to specify 0 in place
> of the sixth argument ...
> but I'm not sure at 100% :)
I have a patch attached for the x11/nvidia-driver Makefile. It doesn't
work and I loose hairs due to not knowing why.
When issuing the following command sequence on the console:
cd /usr/ports/x11/nvidia-driver
make clean extract
sed -i -e '/(VM_PROT_READ | VM_PROT_WRITE), 0);$/s/0);$/0, 0);/g' \
work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c
and check then line 835 (the corrupt one) in file
work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c,
I see this BEFORE:
status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE),
&virtual_address, size, VMFS_ANY_SPACE,
(VM_PROT_READ | VM_PROT_WRITE),
===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0);
and I see this AFTER the sed'ed replacement:
status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE),
&virtual_address, size, VMFS_ANY_SPACE,
(VM_PROT_READ | VM_PROT_WRITE),
===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0, 0);
BUT: Using the patch (see attached, please apply to
x11/nvidia-driver/Makefile) gives me an error in x11/nvidia-driver:
make clean patch
===> Cleaning for nvidia-driver-325.15
===> License NVIDIA accepted by the user
===> Found saved configuration for nvidia-driver-325.08_1
===> nvidia-driver-325.15 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by nvidia-driver-325.15 for
building
===> Extracting for nvidia-driver-325.15
=> SHA256 Checksum OK for NVIDIA-FreeBSD-x86_64-325.15.tar.gz.
===> Patching for nvidia-driver-325.15
sed: 1: "/(VM_PROT_READ | VM_PRO ...": invalid command code 0
*** Error code 1
The Shell/make should be able to substitute within a single-quotet
command to sed, but the error message reports differently.
Do not be confused about the driver revision I use. I tried the
official one (319.XX) as well and it is not working the very same way
and the patch won't either.
Oliver
--- Makefile.orig 2013-09-10 00:30:53.0 +0200
+++ Makefile 2013-09-10 00:40:08.0 +0200
@@ -160,6 +160,11 @@
s/CAP_IOCTL/cap_rights_init(\&rights, &)/' \
${WRKSRC}/src/nvidia_linux.c
.endif
+# Changes in vm_map_find() due to r255426
+.if ${OSVERSION} >= 154
+ ${REINPLACE_CMD} -e '/(VM_PROT_READ | VM_PROT_WRITE), 0);$/s/0);$/0, 0);/g' \
+ ${WRKSRC}/src/nvidia_subr.c
+.endif
# Fix stack buffer overflow in nvidia_sysctl_bus_type()
.if ${NVVERSION} < 3192300
${REINPLACE_CMD} -E '/bus_type\[4\]/d ; \
signature.asc
Description: PGP signature
Re: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
On Mon, 09 Sep 2013 16:49:23 -0600
Ian Lepore wrote:
> On Tue, 2013-09-10 at 00:42 +0200, O. Hartmann wrote:
> > On Tue, 10 Sep 2013 00:24:05 +0300
> > Ivan Klymenko wrote:
> >
> > > В Mon, 9 Sep 2013 23:17:13 +0200
> > > "O. Hartmann" пишет:
> > >
> > > > On Tue, 10 Sep 2013 00:02:37 +0300
> > > > Ivan Klymenko wrote:
> > > >
> > > > > В Mon, 9 Sep 2013 22:37:48 +0200
> > > > > "O. Hartmann" пишет:
> > > > > >
> > > > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76:
> > > > > > error: too few arguments to function call, expected 10,
> > > > > > have 9 cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^
> > > > > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int
> > > > > > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t,
> > > > > > vm_offset_t *, vm_size_t,
> > > > >
> > > > > Try the following changes:
> > > > > int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr,
> > > > > --- cbAllocated, TRUE, VM_PROT_ALL,
> > > > > VM_PROT_ALL, 0); +++ cbAllocated, 0,
> > > > > VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0);
> > > > >
> > > > > for Nvidia driver need to make similar changes...
> > > > The man page of vm_map_find() says the last parameter is of int,
> > > > named int cow. On the hurry, I didn't find any explanation of
> > > > that parameter. Setting it to "0" (zero) also in the
> > > > nvidia_subr.c makes the driver compile again.
> > > >
> > > > But simply filling in a int zero is a bit strange without
> > > > knowing what to do, isn't it?
> > > >
> > > > Thanks anyway,
> > > >
> > > > Oliver
> > >
> > > This commit you to find an appropriate example ...
> > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=291456+0+current/svn-src-head
> > > And in this case, the driver Nvidia really need to specify 0 in
> > > place of the sixth argument ...
> > > but I'm not sure at 100% :)
> >
> > I have a patch attached for the x11/nvidia-driver Makefile. It
> > doesn't work and I loose hairs due to not knowing why.
> >
> > When issuing the following command sequence on the console:
> >
> > cd /usr/ports/x11/nvidia-driver
> > make clean extract
> > sed -i -e '/(VM_PROT_READ | VM_PROT_WRITE), 0);$/s/0);$/0, 0);/g' \
> > work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c
> >
> >
> > and check then line 835 (the corrupt one) in file
> > work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c,
> >
> > I see this BEFORE:
> >
> > status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE),
> > &virtual_address, size, VMFS_ANY_SPACE,
> > (VM_PROT_READ | VM_PROT_WRITE),
> > ===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0);
> >
> >
> > and I see this AFTER the sed'ed replacement:
> >
> > status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE),
> > &virtual_address, size, VMFS_ANY_SPACE,
> > (VM_PROT_READ | VM_PROT_WRITE),
> > ===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0, 0);
> >
> > BUT: Using the patch (see attached, please apply to
> > x11/nvidia-driver/Makefile) gives me an error in x11/nvidia-driver:
> >
> > make clean patch
> >
> > ===> Cleaning for nvidia-driver-325.15
> > ===> License NVIDIA accepted by the user
> > ===> Found saved configuration for nvidia-driver-325.08_1
> > ===> nvidia-driver-325.15 depends on file: /usr/local/sbin/pkg -
> > found ===> Fetching all distfiles required by nvidia-driver-325.15
> > for building
> > ===> Extracting for nvidia-driver-325.15
> > => SHA256 Checksum OK for NVIDIA-FreeBSD-x86_64-325.15.tar.gz.
> > ===> Patching for nvidia-driver-325.15
> > sed: 1: "/(VM_PROT_READ | VM_PRO ...": invalid command code 0
> > *** Error code 1
> >
> > The Shell/make should be able to substitute within a single-quotet
> > command to sed, but the error message reports differently.
> >
> > Do not be confused about the driver revision I use. I tried the
> > official one (319.XX) as well and it is not working the very same
> > way and the patch won't either.
> >
> > Oliver
>
> I don't know about the sed error, but I think the change you're trying
> to make is wrong. The new '0' parameter to vm_map_find() isn't added
> at the end, it goes after the size parameter.
>
> -- Ian
Yes, you're correct and my face is red like a tomatoe :-(
I try this sed replacement expression:
sed -i -e '/\&virtual_address\, size\, \
VMFS_ANY\_SPACE\,$/s//\&virtual_address\, size\, 0\, \
VMFS_ANY\_SPACE\,/g' work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c
It works from the command line, but it doesn't work from the (attached)
Makefile-patch.
--- Makefile.orig 2013-09-10 00:30:53.0 +0200
+++ Makefile 2013-09-10 01:04:05.0 +0200
@@ -160,6 +160,12 @@
s/CAP_IOCTL/cap_rights_init(\&rights, &)/' \
${WRKSRC}/src/nvidia_linux.c
.endif
+# Changes in vm_map_find() due to r255426
+.if ${OSVERSION} > 153
+ ${REI
Re: [PATCH] mtree should not output size if the file is not a regular file
Xin Li writes: > I think it doesn't make sense to emit size information for non-regular > files like directories, symlinks, etc. although both our and NetBSD's > mtree would emit it. I agree. The size of a directory will vary from filesystem to filesystem, while the size of a symlink is simply the length of its target. There is no need for it, and in the case of a directory, including it causes spurious diffs between mtree descriptions of identical trees on different systems. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"
[PATCH] mtree should not output size if the file is not a regular file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I think it doesn't make sense to emit size information for non-regular files like directories, symlinks, etc. although both our and NetBSD's mtree would emit it. Comments? Index: usr.sbin/mtree/create.c === - --- usr.sbin/mtree/create.c (revision 255424) +++ usr.sbin/mtree/create.c (working copy) @@ -208,7 +208,7 @@ statf(int indent, FTSENT *p) output(indent, &offset, "mode=%#o", p->fts_statp->st_mode & MBITS); if (keys & F_NLINK && p->fts_statp->st_nlink != 1) output(indent, &offset, "nlink=%u", p->fts_statp->st_nlink); - - if (keys & F_SIZE) + if (keys & F_SIZE && S_ISREG(p->fts_statp->st_mode)) output(indent, &offset, "size=%jd", (intmax_t)p->fts_statp->st_size); if (keys & F_TIME) Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBCgAGBQJSLj8GAAoJEG80Jeu8UPuzfr4H/RU/qxwVIBAdiXzaD7CvPnCr 3fl+wMIaugYYyZCOWXu1cW4NS8eq5PGPtkJyXCjxGjnyjIpJgZ9XWxZMzdNR4ID0 qLuDOStThE3jjQ/11vx4G4qwsd7iB/BE0O8dfpf68VQu50b40IRl6nDRfHrUETuZ wYFT+tbm6EiJlNif6Y9XNFJhdAuow3oPEexx6fxv5AUaC9ZeyoSZQdCJoDcfOsXm gEnB1IJiS5hRXckimvTrq8pjnfj+u6oTAj9U4klAx0yDk6VZuZPIWaYOnPZJr7BR rVuiRbLFnc2yIPyFFq7y3guqCJpRvOwRuOF/N5vj3qSCYJXmIasXkUjUM6hsxA0= =hteB -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: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
В Mon, 9 Sep 2013 23:17:13 +0200 "O. Hartmann" пишет: > On Tue, 10 Sep 2013 00:02:37 +0300 > Ivan Klymenko wrote: > > > В Mon, 9 Sep 2013 22:37:48 +0200 > > "O. Hartmann" пишет: > > > > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76: > > > error: too few arguments to function call, expected 10, have 9 > > > cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^ > > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int > > > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > > > vm_size_t, > > > > Try the following changes: > > int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr, > > --- cbAllocated, TRUE, VM_PROT_ALL, > > VM_PROT_ALL, 0); +++ cbAllocated, 0, > > VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0); > > > > for Nvidia driver need to make similar changes... > The man page of vm_map_find() says the last parameter is of int, named > int cow. On the hurry, I didn't find any explanation of that > parameter. Setting it to "0" (zero) also in the nvidia_subr.c makes > the driver compile again. > > But simply filling in a int zero is a bit strange without knowing what > to do, isn't it? > > Thanks anyway, > > Oliver This commit you to find an appropriate example ... http://docs.freebsd.org/cgi/getmsg.cgi?fetch=291456+0+current/svn-src-head And in this case, the driver Nvidia really need to specify 0 in place of the sixth argument ... but I'm not sure at 100% :) ___ 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: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
On Tue, 10 Sep 2013 00:02:37 +0300 Ivan Klymenko wrote: > В Mon, 9 Sep 2013 22:37:48 +0200 > "O. Hartmann" пишет: > > > x11/nvidia-driver (as well as emulators/virtualbox-ose-kmod) do not > > compile on FreeBSD 10.0-CURRENT #0 r255426: Mon Sep 9 21:35:43 > > CEST 2013 amd64. > > > > The error is: > > > > x11/nvidia-driver: > > > > --- nvidia_subr.o --- > > nvidia_subr.c:835:46: error: too few arguments to function call, > > expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0); > > ^ > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here > > int vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > > vm_size_t, ^ > > 1 error generated. > > *** [nvidia_subr.o] Error code 1 > > > > > > emulators/virtualbox-ose-kmod: > > > > [...] > > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76: > > error: too few arguments to function call, expected 10, have 9 > > cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^ > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int > > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > > vm_size_t, > > Try the following changes: > int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr, > --- cbAllocated, TRUE, VM_PROT_ALL, > VM_PROT_ALL, 0); +++ cbAllocated, 0, > VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0); > > for Nvidia driver need to make similar changes... > ___ > 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" The man page of vm_map_find() says the last parameter is of int, named int cow. On the hurry, I didn't find any explanation of that parameter. Setting it to "0" (zero) also in the nvidia_subr.c makes the driver compile again. But simply filling in a int zero is a bit strange without knowing what to do, isn't it? Thanks anyway, Oliver signature.asc Description: PGP signature
CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
x11/nvidia-driver (as well as emulators/virtualbox-ose-kmod) do not compile on FreeBSD 10.0-CURRENT #0 r255426: Mon Sep 9 21:35:43 CEST 2013 amd64. The error is: x11/nvidia-driver: --- nvidia_subr.o --- nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0); ^ @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, vm_size_t, ^ 1 error generated. *** [nvidia_subr.o] Error code 1 emulators/virtualbox-ose-kmod: [...] /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76: error: too few arguments to function call, expected 10, have 9 cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^ @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, vm_size_t, signature.asc Description: PGP signature
Re: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
В Mon, 9 Sep 2013 22:37:48 +0200 "O. Hartmann" пишет: > x11/nvidia-driver (as well as emulators/virtualbox-ose-kmod) do not > compile on FreeBSD 10.0-CURRENT #0 r255426: Mon Sep 9 21:35:43 CEST > 2013 amd64. > > The error is: > > x11/nvidia-driver: > > --- nvidia_subr.o --- > nvidia_subr.c:835:46: error: too few arguments to function call, > expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0); > ^ > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here > int vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > vm_size_t, ^ > 1 error generated. > *** [nvidia_subr.o] Error code 1 > > > emulators/virtualbox-ose-kmod: > > [...] > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76: > error: too few arguments to function call, expected 10, have 9 > cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^ > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > vm_size_t, Try the following changes: int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr, --- cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); +++ cbAllocated, 0, VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0); for Nvidia driver need to make similar changes... ___ 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: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Mon, 2013-09-09 at 07:51 -0600, Ian Lepore wrote: > On Mon, 2013-09-09 at 08:57 +0200, Stefan Esser wrote: > > Am 08.09.2013 08:14, schrieb O. Hartmann: > > > On Sat, 7 Sep 2013 22:49:54 GMT rak...@freebsd.org wrote: > > > > > >> Synopsis: devel/qt4-script: > > >> /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is > > >> ambiguous > > >> > > >> State-Changed-From-To: open->patched State-Changed-By: rakuco > > >> State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 > > >> State-Changed-Why: I don't think the previous version worked. > > >> > > >> From your description, it looks like you've switched to building > > >> with libc++ whereas libstdc++ was being used before. > > >> > > >> The upcoming Qt 4.8.5 plus a few patches which only made it to > > >> 4.8.6 (but we've backported) will finally make Qt build with > > >> libc++. > > >> > > >> We've just sent an exp-run request for Qt 4.8.5, and will > > >> hopefully fix all these errors once it is committed. > > >> > > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 > > > > > > > > > I build the world/kernel since early this year with > > > > > > CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= > > > -std=c++11 > > > > > > > > > in /etc/src.conf. I do not use those flags in /etc/make.conf! > > > /etc/src.conf is supposed to target ONLY the /usr/src world, not > > > the ports - this is as I interpret the man page for /etc/src.conf > > > and it would be logical. But this rule/thinking seems to be broken > > > by some includes from /usr/ports/Mk ingredients. > > > > There are ports that use bsd.prog.mk instead of the Makefile supplied > > with the source files. Just grep for bsd.port.mk in the port's "files" > > sub directory, if you find that /etc/src.conf settings affect a port. > > > > I think these ports are in violation of POLA and had a longer mail > > exchange with a port maintainer, who told me that use of bsd.prog.mk > > was the preferred method to build binaries on FreeBSD, for base and > > for ports. > > > > So no file under /usr/ports/Mk is to blame, but some ports do > > implicitly reference /etc/src.conf via their use of bsd.prog.mk. > > > > Regards, STefan > > > > NB: I just performed the grep suggested above and found that the > > following ports mention bsd.prog.mk in files/*: > > > > > > If those ports .include before bsd.prog.mk, I think > everything should work properly. It looks like src.conf is an "opt-out" > system, and bsd.port.mk sets the variable to opt out. > > I don't especially like this (opt-in would be better), but I don't see > an easy fix either. We use bsd.prog.mk at $work (I'd better go add the > opt-out now), it seems like others probably do the same. > > It would be much better if the base build opted in, but the only way I > can see to do that would be to install a "makefile.up" system where a > makefile.up in every directory under the base src allows "walking up" to > the top of the src hierarchy no matter where the build is started from, > so that you can always get some top-level file to do the opt-in. Hrm. I take that back. You can't set _WITHOUT_SRCCONF and then .include and expect anything to work. For some reason all the setting of the MK_whatever knobs is disabled by setting _WITHOUT_SRCCONF, and without all those things defined, the rest of the bsd.*.mk files don't work. ::sigh:: What a mess. -- Ian ___ 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: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Mon, 2013-09-09 at 08:57 +0200, Stefan Esser wrote: > Am 08.09.2013 08:14, schrieb O. Hartmann: > > On Sat, 7 Sep 2013 22:49:54 GMT rak...@freebsd.org wrote: > > > >> Synopsis: devel/qt4-script: > >> /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is > >> ambiguous > >> > >> State-Changed-From-To: open->patched State-Changed-By: rakuco > >> State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 > >> State-Changed-Why: I don't think the previous version worked. > >> > >> From your description, it looks like you've switched to building > >> with libc++ whereas libstdc++ was being used before. > >> > >> The upcoming Qt 4.8.5 plus a few patches which only made it to > >> 4.8.6 (but we've backported) will finally make Qt build with > >> libc++. > >> > >> We've just sent an exp-run request for Qt 4.8.5, and will > >> hopefully fix all these errors once it is committed. > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 > > > > > > I build the world/kernel since early this year with > > > > CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= > > -std=c++11 > > > > > > in /etc/src.conf. I do not use those flags in /etc/make.conf! > > /etc/src.conf is supposed to target ONLY the /usr/src world, not > > the ports - this is as I interpret the man page for /etc/src.conf > > and it would be logical. But this rule/thinking seems to be broken > > by some includes from /usr/ports/Mk ingredients. > > There are ports that use bsd.prog.mk instead of the Makefile supplied > with the source files. Just grep for bsd.port.mk in the port's "files" > sub directory, if you find that /etc/src.conf settings affect a port. > > I think these ports are in violation of POLA and had a longer mail > exchange with a port maintainer, who told me that use of bsd.prog.mk > was the preferred method to build binaries on FreeBSD, for base and > for ports. > > So no file under /usr/ports/Mk is to blame, but some ports do > implicitly reference /etc/src.conf via their use of bsd.prog.mk. > > Regards, STefan > > NB: I just performed the grep suggested above and found that the > following ports mention bsd.prog.mk in files/*: > > If those ports .include before bsd.prog.mk, I think everything should work properly. It looks like src.conf is an "opt-out" system, and bsd.port.mk sets the variable to opt out. I don't especially like this (opt-in would be better), but I don't see an easy fix either. We use bsd.prog.mk at $work (I'd better go add the opt-out now), it seems like others probably do the same. It would be much better if the base build opted in, but the only way I can see to do that would be to install a "makefile.up" system where a makefile.up in every directory under the base src allows "walking up" to the top of the src hierarchy no matter where the build is started from, so that you can always get some top-level file to do the opt-in. -- Ian ___ 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: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
On 9 Sep 2013, at 14:27, Ulrich Spörlein wrote: > Case in point, I only recently switched to clang in base and now the > newsbeuter port crashes during startup (yeah, it builds fine). So all > I'm asking for now is: how can I override a random port to be built with > gcc (either from base or ports, I don't care). And what special > considerations need to be done when the port uses C++. Setting USE_GCC=any to build with any gcc, or USE_GCC=yes to build with a gcc from ports (they should do the same thing on a no-gcc-in-base system) For C++ ports, can you check whether the error is from libc++ or clang, by first building libstdc++ from base and then setting CXXFLAGS=-stdlib=libstdc++ and LDFLAGS=-stdlib=libstdc++? This will build it with libstdc++ and if that works then it narrows the issue down. Also, don't forget to report bugs to the port maintainer... David ___ 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: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
On Fri, 2013-09-06 at 21:19:32 +0100, David Chisnall wrote: > Hi Everyone, > > As of r255321, we are no longer building gcc or libstdc++ as part of the > default install on platforms where clang is cc. > > If you are using gcc, you have two options: > > 1) Install one of the lang/gcc* ports (Warner has been working on separating > out the patches to our GCC, so these should soon be patched to provide the > same features as the one in base) > > 2) Put WITH_GCC=yes and WITH_GNUCXX=yes in your src.conf when you build world. > > GCC will stay in the base system tree for at least the lifetime of the 10.x > release, and possibly longer if it is still being actively used. It will > remain used by tinderboxes and make universe for some architectures, so if > you commit code without testing with gcc people will know very soon... > > Thanks to Warner for all of his recent work on disentangling the toolchain, > to all of the people (Roman, Dimitry, Brooks, and others) who worked on > getting clang integrated into FreeBSD and to everyone who tested it and filed > bug reports. As of today, PowerPC64 joins x86 and ARM as platforms where > world+kernel can be successfully built (and work) with clang (although it > isn't the default yet and needs more testing), and hopefully other > architectures will follow soon. > > Huge thanks to all of the ports people who have spent the last two weeks > working on dealing with the fallout from iconv and ensuring that all of the > ports work with clang and libc++. I think over the last week, the number of > failing / ignored ports has dropped by about a thousand a day on the no-gcc > test box that Bapt has been running, which is a phenomenal achievement. Indeed, thanks to all for their hard work, this is good news overall! To nitpick, however, what has been fixed is that ports "build" with clang and libc++, no effort can humanely be done to make sure they really *work* as before. Case in point, I only recently switched to clang in base and now the newsbeuter port crashes during startup (yeah, it builds fine). So all I'm asking for now is: how can I override a random port to be built with gcc (either from base or ports, I don't care). And what special considerations need to be done when the port uses C++. Cheers, Uli ___ 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: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Sun, 8 Sep 2013 14:57:01 +0200 Dimitry Andric wrote: > On Sep 8, 2013, at 08:14, O. Hartmann > wrote: > > On Sat, 7 Sep 2013 22:49:54 GMT > > rak...@freebsd.org wrote: > > > >> Synopsis: > >> devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: > >> call to 'swap' is ambiguous > >> > >> State-Changed-From-To: open->patched > >> State-Changed-By: rakuco > >> State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 > >> State-Changed-Why: > >> I don't think the previous version worked. > >> > >> From your description, it looks like you've switched to building > >> with libc++ whereas libstdc++ was being used before. > >> > >> The upcoming Qt 4.8.5 plus a few patches which only made it to > >> 4.8.6 (but we've backported) will finally make Qt build with > >> libc++. > >> > >> We've just sent an exp-run request for Qt 4.8.5, and will hopefully > >> fix all these errors once it is committed. > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 > > > > I build the world/kernel since early this year with > > > > CXXFLAGS+= -stdlib=libc++ > > CXXFLAGS+= -std=c++11 > > > > > > in /etc/src.conf. I do not use those flags > > in /etc/make.conf! /etc/src.conf is supposed to target ONLY > > the /usr/src world, not the ports - this is as I interpret the man > > page for /etc/src.conf and it would be logical. But this > > rule/thinking seems to be broken by some includes > > from /usr/ports/Mk ingredients. > > Since r255321, -stdlib=libc++ is effectively the default, at least > when you haven't set gcc as the default compiler. So it also applies > to ports, which unavoidably will lead to a bit of fallout. My > personal experience is that most C++-based ports compile fine with > libc++ instead of libstdc++, except for a few that rely on internal > libstdc++ details. > > However, -std=c++11 is *not* yet the default, and C++11 has different > rules here and there, so some ports might fail to compile due to this. > For some ports, too much hacking may be required to make them work > with C++11. So in case of trouble, try removing -std=, or setting it > to different values (c++0x, c++98, gnu++98, etc), to get the port to > compile. > > Note the base system should have no problems with -std=c++11, so > please continue to use the option in src.conf, and report any > problems if you encounter them, so we can fix them. :-) > I've been using clang and libc++ successfully on 9.1-RELEASE for quite some time now. Based on what I've learned, expect the following pitfalls that might hit you hard in production: - Bugs in in libc++: CURRENT is good about pulling in fixes, but there are still quite basic things getting fixed, e.g. cout/cerr not being thread safe (this was supposedly fixed in CURRENT and STABLE just a few weeks ago). Another example was handling std::vector incorrectly (ouch). Other problems only affect C++11/C++14 features and shouldn't be a big issue when porting. - Mixed C++ library linkage: For some ports autoconf/libtool might pull in libstdc++ by accident, you really don't want this to happen since std types don't match (e.g. std::exception and everything inheriting from it, which will break exception handling in client code). - Incompatibilities in corner cases of the language: A good example is the exception specification of destructors. Those are defaulting to noexcept(true) now, while in C++03 it's the opposite. Even though it's bad design in almost all cases, the language permits throwing from destructors in general. I got hit by that when porting devel/ice, which depends on databases/db5, which has no exception specification for destructors, but throws from them under certain circumstances (e.g. database close failed), in that specific case also from callbacks that were called from within db5. Overall the code was quite convoluted, but valid C++03. On top of that there are the usual incompatibilities between implementations (like iostreams in gcc 4.2's libstdc++ does some things differently then the imho more compliant libc++) and compile time problems (like the swap issue you experiences, those are easy to fix). So the bottom line is: When converting a port to use clang++ -std=c++11 -stdlib=libc++, the fact that it builds ok and runs a couple of unit tests without problems is not enough. Cheers, Michael -- Michael Gmelin ___ 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"
[head tinderbox] failure on amd64/amd64
TB --- 2013-09-09 07:30:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-09-09 07:30:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-09-09 07:30:20 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-09-09 07:30:20 - cleaning the object tree TB --- 2013-09-09 07:30:20 - /usr/local/bin/svn stat /src TB --- 2013-09-09 07:30:25 - At svn revision 255413 TB --- 2013-09-09 07:30:26 - building world TB --- 2013-09-09 07:30:26 - CROSS_BUILD_TESTING=YES TB --- 2013-09-09 07:30:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-09 07:30:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-09 07:30:26 - SRCCONF=/dev/null TB --- 2013-09-09 07:30:26 - TARGET=amd64 TB --- 2013-09-09 07:30:26 - TARGET_ARCH=amd64 TB --- 2013-09-09 07:30:26 - TZ=UTC TB --- 2013-09-09 07:30:26 - __MAKE_CONF=/dev/null TB --- 2013-09-09 07:30:26 - cd /src TB --- 2013-09-09 07:30:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Sep 9 07:30:34 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_ZN5clang13VTableContext15getVTableLayoutEPKNS_13CXXRecordDeclE' c++: error: unable to execute command: Abort trap: 6 (core dumped) c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Target: x86_64-unknown-freebsd10.0 Thread model: posix c++: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. c++: note: diagnostic msg: Error generating preprocessed source(s). *** Error code 254 Stop. bmake[5]: stopped in /src/lib/clang/libclangcodegen *** Error code 1 Stop. bmake[4]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-09-09 09:20:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-09-09 09:20:13 - ERROR: failed to build world TB --- 2013-09-09 09:20:13 - 5324.30 user 949.73 system 6593.28 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full ___ 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 in ZFS: solaris assert: dn->dn_datablkshift != 0
On Sun, Sep 08, 2013 at 11:14:44PM +0200, Jeremie Le Hen wrote: > On Sun, Sep 08, 2013 at 10:05:55PM +0100, Steven Hartland wrote: > > > On Sun, Sep 08, 2013 at 09:02:48PM +0100, Steven Hartland wrote: > > >> > On Sun, Sep 08, 2013 at 03:17:09PM +0100, Steven Hartland wrote: > > >> >> I believe this was added by this change set:- > > >> >> http://svnweb.freebsd.org/base?view=revision&revision=253821 > > >> >> > > >> >> Might want to try back out that change and see if everything > > >> >> works after that? > > >> > > > >> > Actually, I already rolled back my kernel to August 1st: > > >> > > > >> > # svn info . > > >> > Path: . > > >> > Working Copy Root Path: /usr/src > > >> > URL: http://svn0.us-west.freebsd.org/base/head/sys > > >> > Repository Root: http://svn0.us-west.freebsd.org/base > > >> > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > >> > Revision: 253847 > > >> > Node Kind: directory > > >> > Schedule: normal > > >> > Last Changed Author: ian > > >> > Last Changed Rev: 253847 > > >> > Last Changed Date: 2013-07-31 21:14:00 +0200 (Wed, 31 Jul 2013) > > >> > > > >> > > > >> > And the problem seems to have gone away. I could perform a full zfs > > >> > send/receive whereas it would trigger a panic 100% of the time with a > > >> > recent kernel. > > >> > > >> I still think r253821 is the cause the reason being is prior to r253996 > > >> ASSERTS in ZFS where not actually active in HEAD. > > >> > > >> So if you could roll forward but then backout r253821 and confirm this > > >> is indeed the cause that would be a good starting point. > > >> > > >> If this is indeed the cause be worth engaging Matthew Ahrens cc'ed to > > >> find out the reasoning behind the new ASSERT why you may be hitting it? > > > > > > > > > > Errm, was there meant to be some content in your reply Jeremie, as it seems > > to be missing? > > Indeed, probably a bad key combo in vi :). > > I'm reverting r253821 and r254753 (the second one was supposingly fixing > the first one) and recompiling my kernel. > > I will let you know. So far so good, I've been able to synchronize my datasets beyond the point where it crashed last time. Matthew, do you have any idea of a fix I could try on top of FreeBSD's r253821 and r254753? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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"
