Re: [patch] build fat libgcc_s.1.dylib for darwin

[Mike Stump <mrs at apple dot com>]

On Jul 10, 2006, at 2:23 PM, Eric Christopher wrote:
> Here's a patch that makes libgcc_s.1.dylib fully "fat" or  
> "universal" for darwin. It involves a little rewriting of the  
> makefile dependencies in the file since we don't really have a  
> "post-processing" step for libgcc.
>
> Tested (and install tested) on ppc-darwin (with 64-bit multilib),  
> x86-darwin, no regressions.
>
> OK to hold for 4.3?

I'm anticipating that we have enough testing on this for you to be  
sure it is ok...  I'd rather have it for 4.2.  Mark, ok for mainline/ 
4.2?

> +	$(LN_S) $(DESTDIR)$(slibdir)/libgcc_s.1.dylib \
> +		$(DESTDIR)$(slibdir)/libgcc_s_ppc64.1.dylib

No.  symlinks should always be the shortest, most direct possible.

I think that means:

> +	$(LN_S) libgcc_s.1.dylib \
> +		$(DESTDIR)$(slibdir)/libgcc_s_ppc64.1.dylib

?

Now, I'm seeing a make -j2 failure in my internal 4.2 since I've not  
yet been able to track it down in my tree, I'd ask, are you sure this  
is -j2 safe?

The problem I was having was that ranlib is being run on libgcc.a and  
libgcov.a during make install time and they weren't there because  
there were multiple invocations of the same rule being run at once  
and they were conflicting.  I had the feeling that stmp-lipo was  
making it harder to track down or causing it.

A clean build always shows the problem for me, but an incremental one  
hides it.

Ok as far as I'm concerned if you think it is -j2 safe.