Re: ITS: scrotwm (already in Debian)
On 2011-11-10 17:08, Andrea Bolognani wrote:
> On Thu, Nov 10, 2011 at 12:56:57PM +0100, Niels Thykier wrote:
>
>> Hi,
>>
>> As the subject suggests I am willing to sponsor the package. :)
>
> I’m glad to hear that!
>
Hi,
>> But
>> before I do; have you considered enabling hardning flags in your
>> package? A basic example of how to do it can be seen the attached patch[1].
>
> Thanks for pointing that out.
>
> I’m looking at the documentation and at your patch, and I’m unsure
> about this bit
>
> %.so: %.c
> - $(CC) $(CFLAGS) -c -fpic -DPIC $+ -o $@
> + $(CC) $(LDFLAGS) $(CFLAGS) -c -fpic -DPIC $+ -o $@
>
> Are you positive $(LDFLAGS) is supposed to be passed to the compiler
> here? It is just creating an object file, so the linker should not
> be called by $(CC).
>
I am indeed wrong. I assumed that the "%.so: %.c" rule implied it was a
shared library and completely overlooked the "-c" argument.
> [...]
>
> I will patch the Makefile and send the patch upstream for inclusion in
> a future release.
>
>> Is there a reason that the binaries are compiled without
>> optimization[2]? As far as I can tell it is an oversight, because the
>> "osx" Makefile includes an "-O2" flag. However, if it is known to have
>> issues with optimization on Linux platforms, a comment about that would
>> be appreciated (bonus points for valid references to bugs against gcc :P).
>
> It’s almost certainly an oversight.
>
>> [1] Strictly speaking the CFLAGS/LDFLAGS from should "overrule" the
>> upstream ones if there are conflicts. Fixing that is left as an
>> exercise to the reader. ;)
>
> Can’t think of a way of doing that without patching the Makefile. But
> then again, patching the Makefile is no big deal.
>
If you are going to send a patch upstream anyway, you might as well make
it possible to insert user *FLAGS after the "upstream flags". ;)
> Thanks for your input, I’ll let you know when I have an updated package
> ready for review.
>
Looking forward to seeing it. :)
~Niels
Reply to: