Re: Some problems packaging libobjc2 version 1.6

[David Chisnall]

On 6 Mar 2012, at 10:31, Richard Stonehouse wrote:

> I've been trying to build an RPM package of libobjc2 version 1.6. This was 
> using GCC version 4.6.2 under a non-root username. The following occurred:
> 
> 1.  The build failed when compiling objc_msgSend.S, because the
>   compiler did not recognise the '-no-integrated-as' option
>   that is used. I cannot find this option in the GCC documentation.
>   Is it a clang-only feature? If so, is it OK - when using GCC - to
>   omit this option (i.e. does GCC have an integrated-as at all?)

It's safe to ignore it if you're using gcc (although if you're using gcc as 
your Objective-C compiler then you can't use half of the features of libobjc2, 
which makes me wonder why you would do that).  It's only really required for 
ARM - clang's integrated assembler does fine on x86, but it doesn't yet 
understand one of the directives in the ARM assembly.

> 2.  When building using the Makefile, rather than the GNUmakefile,
>   the DESTDIR variable is not honoured. DESTDIR is important for
>   building packages. I think the attached patch overcomes this
>   problem.

This is a very ugly patch.  It seems to duplicate the functionality of the 
PREFIX macro, but by scattering references to it everywhere rather than just 
using them in the one place where they're required.  make PREFIX=$DESTDIR 
should do what you want without this.

> 3.  If you make install with 'strip=yes', using the Makefile rather
>   than the GNUmakefile, it fails with a permission failure. The
>   reason seems to be that the Makefile first installs the libraries
>   as read-only, then attempts to strip them. It gets away with this
>   if the make install is run under root, but not if it is run under
>   a non-root username (which is usual when building packages).

This is definitely a bug.  The way it was doing the stripping is just weird.  
It should be fixed in trunk.

> I have some further problems but they may possibly be consequences of the 
> above, or of my work-arounds, so I'd be grateful for feedback on these points.

Let me know how you get on,

David

-- Sent from my brain