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

            Bug ID: 70423
           Summary: -shared option description isn't clear about exactly
                    when -fpic/-fPIC is required
           Product: gcc
           Version: 5.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: britton.kerin at gmail dot com
  Target Milestone: ---

Section 3.13 Options for Linking includes this:

-shared
    Produce a shared object which can then be linked with other objects to form
an executable. Not all systems support this option. For predictable results,
you must also specify the same set of options used for compilation (-fpic,
-fPIC, or model suboptions) when you specify this linker option.

This makes it sound like -fpic/-fPIC would be required when performing a
link-only gcc invocation (i.e. with arguments consisting only of .o files).
Most people don't include -fpic/-fPIC in this situation and in fact it
apparently isn't required:

Cary Coutant wrote in a bug report elsewhere:

     The -fpic and model suboptions are not linker options. They're only
     required when you pass -shared to gcc if you're also compiling source
     files at the same time. If you're just running gcc to link a bunch of .o
     files, compiler options like -fpic are unnecessary.

This problem could be fixed by changing the -shared description to read like
this:

-shared
    Produce a shared object which can then be linked with other objects to form
an executable. Not all systems support this option. For predictable results,
you must also specify the same set of options used for compilation (-fpic,
-fPIC, or model suboptions) when you specify this linker option in a gcc
invocation that will perform both compilation and linking.

Actually this is still a little imperfect since if I understand correctly the
purpose is to get the same set of options in the compile/link invocation as
those used for any previous compilations that produced object files to be
included in the link.  If the invocation compiles everything that gets linked
there's no possibility to go wrong.  But I think the above gets the point
accross.

This is worth fixing because -shared -fPIC -fpic etc. form a somewhat
complicated nest so the specifications need to be precise.  I believe most
existing build systems don't mix compilation and linking, so don't use
-fpic/-fPIC at link time, so violate the most likely (but wrong) interpretation
of the situations in which -fpic/-fPIC are required according to the current
-shared option description.

Reply via email to