cups-client broken on ia64, blocks 70 ports, please help

[Pedro Giffuni]

(I had to do some copy-pasting to get this email out due to some yahoo smtp brokeness, sorry for the mess)

On 04/04/2014 07:56, David Chisnall wrote:
> On 4 Apr 2014, at 13:13, Baptiste Daroussin <bapt at FreeBSD.org> wrote:
> 
>> On Fri, Apr 04, 2014 at 04:08:13PM +0400, Boris Samorodov wrote:
>>> 04.04.2014 15:49, Baptiste Daroussin пишет:
>>>> On Fri, Apr 04, 2014 at 02:18:15PM +0400, Boris Samorodov wrote:
>>>>> 04.04.2014 12:07, Anton Shterenlikht пишет:
>>>>>>
>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=188161
>>>>>>
>>>>>> 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=1 -D_PPD_DEPRECATED="" -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
>>>>>
>>>>> Hm. cups/cups.h has the following code:
>>>>> -----
>>>>> #  ifdef __BLOCKS__
>>>>> #    include <dispatch/dispatch.h>
>>>>> #  endif /* __BLOCKS__ */
>>>>> -----
>>>>>
>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>
>>>> That is on recent head, due to the import of _BLOCKS_ support but we don't have
>>>> libdispatch
>>>
>>> Makes sense, thanks.
>>>
>>> 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 at bb052.bsnet:/usr/obj/usr/src/sys/BB64X  amd64
>>>
>>> % 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__
>>> -----
>>>
>>
>> The compilers defines it, this is probably due to using gcc on ia64,
>> 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.
> 


The policy in Apple's GCC and in FreeBSD since r260311 is to enable blocks support by default unless std=C99 is set.

> 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.
>


I agree that the main issue here is that the cups developers shouldn't be using language features to determine if the platform has libdispatch. This is, however, an exciting opportunity to use libdispatch more extensively.

I will be committing a small patch to make it easier to build libdispatch with GCC on 11.x and 10.x.

Regards,

Pedro.