Re: [Patch, target] Sort out some issues in config{,/*}/darwin*.h

[Jack Howarth <howarth at bromo dot med dot uc dot edu>]

On Wed, Apr 14, 2010 at 12:44:51PM -0500, Peter O'Gorman wrote:
> DISCLAIMER: I am not a maintainer.
> 
> On 04/14/2010 11:41 AM, IainS wrote:
> 
> 
> >     o macro-ized DSYMUTIL so that we can change it without editing the specs.
> >     o Provided a wrapper for the system-supplied dsymutil that allows us to edit out bogus warnings.
> >         this is installed in $(libexecdir) . The initial version filters the message that gives us problems
> >             like PR43254. 
> 
> I think this is not such a bad idea. People building linux -> darwin
> cross compilers (At least, I think they exist) currently may have to
> edit the specs so that dsymutil is not called, because it is not an open
> source project at Apple. Since your wrapper always exits successfully
> they shouldn't need to do that anymore... Are you sure that the wrapper
> should always exit successfully?
> 
> >         (a) Always runs when we are generating an exe - IMO this is more intuitive to the end user - and
> >              it side-steps the problem with the existing spec. 
> 
> I don't actually agree with this, but don't feel that strongly about it
> either.
> 
> >     o Filter out -lm and re-apply it where needed.  [I've provided a bolt-hole for anyone who wants to
> >        force -lm (-force_lm) at least until we confirm that this is not an issue.] 
> 
> There are multpile libraries that are just symlinks to libSystem (libc,
> libinfo, libpthread, libdl, for example). It seems odd to treat libm
> specially here. If the original problem was a test suite failure, why
> not fix the test suite to not add -lm on darwin? Sorry, I know this will
> drive you nuts, but I don't get from the PR why you chose this
> workaround. If memory serves correctly libm has always been a symlink to
> libSystem (or the System framework in 10.0). There is no need to treat
> different darwin versions differently here.
> 
> > 
> >     o fixed darwin10 not to provide no_compact_unwind when building for <10.6. 
> 
> Was this actually causing a problem?

I assume this change was just a cleanup, no? Or does the linker complain when
using -mmacosx-version-min=10.5 and passing -no_compact_unwind? With
-mmacosx-version-min=10.5 set, the linker should default to the legacy non-compact
unwinder code generation so -no_compact_unwind would just be redundant.
                Jack

> 
> Sorry, I didn't spend much time looking at the PRs, I will look more
> closely this evening.
> 
> Peter