After looking at this for quite a while, I'm afraid I'm unsure how to proceed.
As of now, static and static-pie are mutually exclusive. So given the
GNU_USER_TARGET_STARTFILE_SPEC you pasted
earlier, "static" matches before "static-pie", causing the wrong start files.
It seems to me that the static-pie target complicates things more than
matching against static+pie individually.
If I convert -static + -pie to -static-pie, then "static" won't be
matched in specs, where maybe it otherwise should. Same for -pie.
Would you prefer to swallow -static and -pie and pass along only
-static-pie? Or forward them all along, and fix the specs which look
for static before static-pie ?
Regards,
Cory
On Tue, Jan 30, 2018 at 2:36 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Tue, Jan 30, 2018 at 11:18 AM, Cory Fields <li...@coryfields.com> wrote:
>> On Tue, Jan 30, 2018 at 2:14 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> On Tue, Jan 30, 2018 at 11:07 AM, Cory Fields <li...@coryfields.com> wrote:
>>>> On Tue, Jan 30, 2018 at 1:35 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>> On Tue, Jan 30, 2018 at 10:26 AM, Cory Fields <li...@coryfields.com>
>>>>> wrote:
>>>>>> Hi list
>>>>>>
>>>>>> I'm playing with -static-pie and musl, which seems to be in good shape
>>>>>> for 8.0.0. Nice work :)
>>>>>>
>>>>>> However, the fact that "gcc -static -pie" and "gcc -static-pie"
>>>>>> produce different results is very unexpected. I understand the case
>>>>>> for the new link-type, but merging the options when possible would be
>>>>>> a huge benefit to existing buildsystems that already cope with both
>>>>>> individually.
>>>>>>
>>>>>> My use-case:
>>>>>> I'd like to build with --enable-default-pie, and by adding "-static"
>>>>>
>>>>> Why not adding "-static-pie" instead of "-static"?
>>>>>
>>>>>> to my builds, produce static-pie binaries. But at the moment, that
>>>>>> attempts to add an interp section.
>>>>>>
>>>>>> So my question is, if no conflicting options are found, why not hoist
>>>>>> "-static -pie" to "-static-pie" ?
>>>>>>
>>>>>> Regards,
>>>>>> Cory
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> H.J.
>>>>
>>>> My build system, and plenty of others I'm sure, already handle -static
>>>> and -pie. Having that understood to mean "static-pie" would mean that
>>>> the combination would now just work.
>>>>
>>>> Asking a different way, if I request -static and -pie, without -nopie,
>>>> quietly creating non-pie binary seems like a bug. Is there a reason
>>>> _not_ to interpret it as -static-pie in that case?
>>>
>>> GNU_USER_TARGET_STARTFILE_SPEC is defined as
>>>
>>> #define GNU_USER_TARGET_STARTFILE_SPEC \
>>> "%{shared:; \
>>> pg|p|profile:%{static-pie:grcrt1.o%s;:gcrt1.o%s}; \
>>> static:crt1.o%s; \
>>> static-pie:rcrt1.o%s; \
>>> " PIE_SPEC ":Scrt1.o%s; \
>>> :crt1.o%s} \
>>> crti.o%s \
>>> %{static:crtbeginT.o%s; \
>>> shared|static-pie|" PIE_SPEC ":crtbeginS.o%s; \
>>> :crtbegin.o%s} \
>>> %{fvtable-verify=none:%s; \
>>> fvtable-verify=preinit:vtv_start_preinit.o%s; \
>>> fvtable-verify=std:vtv_start.o%s} \
>>> " CRTOFFLOADBEGIN
>>>
>>> to pick a suitable crt1.o for static PIE when -static-pie is used.
>>>
>>> If gcc.c can convert ... -static ... -pie and ... -pie ... -static ... to
>>> -static-pic for GNU_USER_TARGET_STARTFILE_SPEC, it
>>> should work.
>>>
>>> --
>>> H.J.
>>
>> Great, that's how I've fixed it locally. Would you consider accepting
>> a patch for this?
>
> I'd like to see it in GCC 8. Please open a GCC bug and submit your
> patch against it.
>
> Thanks.
>
> --
> H.J.
