Date: Fri, 4 Apr 2014 13:56:48 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: mexas@bris.ac.uk, pfg@FreeBSD.org, Boris Samorodov <bsam@passap.ru>, freebsd-ports@freebsd.org Subject: Re: cups-client broken on ia64, blocks 70 ports, please help Message-ID: <F15EE675-40AA-49F2-B777-C09888EDC4FE@FreeBSD.org> In-Reply-To: <20140404121333.GC85325@ivaldir.etoilebsd.net> References: <20140404121333.GC85325@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Apr 2014, at 13:13, Baptiste Daroussin <bapt@FreeBSD.org> wrote: > On Fri, Apr 04, 2014 at 04:08:13PM +0400, Boris Samorodov wrote: >> 04.04.2014 15:49, Baptiste Daroussin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> On Fri, Apr 04, 2014 at 02:18:15PM +0400, Boris Samorodov wrote: >>>> 04.04.2014 12:07, Anton Shterenlikht =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>>>>=20 >>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D188161 >>>>>=20 >>>>> Compiling adminutil.c... >>>>> cc -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector = -I.. -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing = -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_THREAD_SAFE = -D_REENTRANT -D_CUPS_NO_DEPRECATED=3D1 -D_PPD_DEPRECATED=3D"" -c -o = adminutil.o adminutil.c >>>>> adminutil.c:1: warning: -fstack-protector not supported for this = target >>>>> In file included from pwg-private.h:25, >>>>> from cups-private.h:31, >>>>> from adminutil.c:33: >>>>> ../cups/cups.h:34:35: error: dispatch/dispatch.h: No such file or = directory >>>>=20 >>>> Hm. cups/cups.h has the following code: >>>> ----- >>>> # ifdef __BLOCKS__ >>>> # include <dispatch/dispatch.h> >>>> # endif /* __BLOCKS__ */ >>>> ----- >>>>=20 >>>> It seems that the whole dispath is an Apple thing. How does it come >>>> about that it get used by FreeBSD? I think this check may be = removed. >>>>=20 >>>> Anyway please try the following patch (place it in to the >>>> print/cups/file directory -- mind print/cups origin, >>>> not print/cups-client) and retry: >>>> ftp://ftp.wart.ru/pub/misc/patch-cups-cups.h >>>>=20 >>>=20 >>> That is on recent head, due to the import of _BLOCKS_ support but we = don't have >>> libdispatch >>=20 >> Makes sense, thanks. >>=20 >> Wait a little, I don't get any defines: >> ----- >> % uname -a >> FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #77 r264083: = Fri >> Apr 4 00:30:01 SAMT 2014 >> bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X amd64 >>=20 >> % grep __BLOCKS__ -r /usr/include >> /usr/include/heimbase.h:#ifdef __BLOCKS__ >> /usr/include/heimbase.h:#ifdef __BLOCKS__ >> /usr/include/heimbase.h:#ifdef __BLOCKS__ >> /usr/include/stdlib.h:#ifdef __BLOCKS__ >> /usr/include/stdlib.h:#ifdef __BLOCKS__ >> /usr/include/stdlib.h:#ifdef __BLOCKS__ >> /usr/include/stdlib.h:#ifdef __BLOCKS__ >> /usr/include/hx509-protos.h:#ifdef __BLOCKS__ >> /usr/include/hx509-protos.h:#endif /* __BLOCKS__ */ >> /usr/include/dirent.h:#ifdef __BLOCKS__ >> ----- >>=20 >=20 > The compilers defines it, this is probably due to using gcc on ia64,=20= > I'm CCing Pedro and David on this as the are the guilty one about = __BLOCKS__ > support :) and may know better $ echo | clang -dM -x c - -E | grep BLOCK $ echo | clang -fblocks -dM -x c - -E | grep BLOCK #define __BLOCKS__ 1 $ echo | gcc -dM -x c - -E | grep BLOCK #define __BLOCKS__ 1 $ echo | gcc -fno-blocks -dM -x c - -E | grep BLOCK It's an inconsistency between base gcc and base clang: one defaults to = supporting blocks, the other defaults to not supporting them. I'd like = to blame Pedro, but actually I think the base-system bug is that is that = clang doesn't default to -fblocks behaviour. So, the simplest fix is simply to add -fno-blocks to the CFLAGS for this = port. Given that it has libdispatch support, however, it would be nice = if we could have an option for using libdispatch that would (as well as = passing the correct configure options and so on) add -fblocks to CFLAGS = if building with libdispatch and -fn-blocks otherwise. It would also be nice to tell the cups developers that it's not = particularly clever to use the existence of a compiler feature to test = for the presence of a library. They seem to have come up with an = interesting spelling of #ifdef __APPLE__, rather than adding a proper = configure check. =20 If we've got a baseline, the attached diff enables blocks support by = default in clang and so an exprun can see how many ports break by = assuming that blocks support means libdispatch / Cocoa / OS X... David Index: contrib/llvm/tools/clang/lib/Driver/ToolChains.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/llvm/tools/clang/lib/Driver/ToolChains.h (revision = 263972) +++ contrib/llvm/tools/clang/lib/Driver/ToolChains.h (working copy) @@ -519,6 +519,8 @@ return Generic_ELF::IsIntegratedAssemblerDefault(); } =20 + virtual bool IsBlocksDefault() const { return true; } + virtual bool UseSjLjExceptions() const; protected: virtual Tool *buildAssembler() const;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F15EE675-40AA-49F2-B777-C09888EDC4FE>