https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #54184|0                           |1
        is obsolete|                            |
  Attachment #54208|0                           |1
        is obsolete|                            |
  Attachment #54214|0                           |1
        is obsolete|                            |

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 54220
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54220&action=edit
patch version 3.1


This is patch v3 + some specific changes. [hence it is 3.1 :) ]

The main issues with v3 (and v4 on PR108261) are:

 - link items are positional (you need to ensure that the runtime libraries
appear after the user's objects).
 - adding {f*} to the cc1gm2 line causes f options to be duplicated, this could
(potentially alter the behaviour of the command line when final values of
opposite switches are used - which is the 'usual' mechanism).
 - V3 was still adding the '-L' options for the various libraries which are not
needed (v4 fixes this, but not the other issues)

 - Supporting the target's ability to handle -Bstatic/dynamic in specs is going
to be hard.

---- so ... 


1. we use the specs now to insert the include paths; this works very nicely.

2. we use the existing sequencing the language-driver to ensure that the link
positional arguments are in the right places (and to handle the Bstatic/dynamic
stuff)

3. We remove the {f*} from the cc1gm2 spec [note it is possible that other
similar  entries will cause duplication of their content .. I did not check
this yet]

This means that we can drop the linker-related extra specs and code (and
actually simplify things a bit in the lang-specific driver).

4. We skip options that we will re-insert to avoid duplication there too.

-----

NOTE: with specs, it is usually necessary to ensure that they being and/or end
with whitespace because they can be arbitrarily concatenated.

-----

This does not fix PR108261 (neither does v4, FWIW) on Darwin.

Reply via email to