This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



On 15 Apr 2010, at 19:06, Peter O'Gorman wrote:
So I read all those PRs last night, and ick.

o Split the LINK_COMMAND_SPEC into two bits:
LINK_COMMAND_SPEC_A Common across the platform.
DSYMUTIL_SPEC which needs to vary depending on the default debug
format.

Looking at the PRs it does indeed seem absolutely necessary to wrap dsymutil and always exit 0 from the wrapper... Why not eat all of its stderr & stdout, btw, your -Wdsymutil flag could still be used to see them if required?

I want to see any errors/warnings from dsymutil that we don't specifically know are bogus.
(that's the reason I match it completely rather than wild-carding).


The proposed solution is better on the testsuite time than doing an extra pass with Wdsymutil.

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

If you do decide to remove -lm, there is no need to add a -force_lm
option, the users who really really want a libm can add it with its full
path. Also no need to not eat it when targetting 10.3 etc.

-force_lm is mostly there for safety checks - I never saw it as a suitable long-term thing.


I think it's a horrible icky way to workaround the problem, but I don't
know that there exist less horrible ways. This really needs to be a
separate patch, just because it's so ugh.

if one wanted to be neater it would be necessary to write a


"%:remove-outfile() " - since %<lXX doesn't work for outfiles.
and %:replace-outfile() won't allow the replacement to be empty.

I thought of doing this - but decided to go the simple route for now.

I don't know what the -lgcc before -lSystem does, but ld won't look at
it until after it's looked at libSystem anyway, will it, unless the user
has passed -search_paths_first?

Hmm. well I think if it had the same name as a library OSX was using - you'd be right:
ld always includes the .dylib before the .a.
BUT, since it's not in the list of dylibs; ld is going to treat it as the same as if the User had added a ".a" on the C/L.


As for the other bits, well, they could be separate patches too,
couldn't they? :)

Well.
The DSYMUTIL & spec stuff needs to stay together - otherwise you'll get hoards of testsuite fails between then two parts (esp. in fortran).


--

the white space tidies could be separated ... if anyone feels strongly about it.

--

I'm not too bothered about the '-lm' patch - I thought the x86_64 dudes would be keen .. but if it's not bothering them, then we can just leave it alone.

We can't just "take it out" of the testsuite -- it's added by Dejagnu - so
we need to handle it locally or
wait until a new version of dejagnu appears -
or recommend running with a patched dejagnu ...


... anyone who wants to, can look at the solution to that in PR42333 .

thanks for the reviews,
Iain


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]