[patch ob] Disallow -pie and -static

[Mike Frysinger]

On Monday 27 February 2012 15:56:22 Cary Coutant wrote:
> >> Again, we could define what -static -pie means, but that definition
> >> would include defining how the linker is supposed to handle the option
> >> combination.
> > 
> > i don't see why -pie should require PT_DYNAMIC or PT_INTERP.  -static
> > controls those aspects.
> > 
> > with the compiler driver, -pie would be used to select the appropriate
> > startup objects -- Scrt1.o/crt{begin,end}S.o/etc... vs
> > crt1.o/crt{begin,end}.o/etc...
> 
> I'd have chimed in earlier, but have nothing to say that Ian hasn't
> already said.
> 
> You can argue about what -static -pie should mean, but there's no
> definition for it today, and no spec for the linker to follow.

i'm not arguing that things will work today ... we all agree on that.  my 
point was that the commit was light on details, and for pedants, not an 
entirely accurate error message.

i don't think my implied question was answered: what was the reason for the 
internal error that gold was throwing ?  it just didn't know what to do when 
give -pie -static ?  or there was misbehavior with incoming objects that only 
occurred when using -pie -static ?

> Fundamentally, a PIE is going to need dynamic relocations, and there's
> going to need to be some mechanism in the ABI that tells the linker
> how to pass those to the runtime. Today, that mechanism involves
> PT_DYNAMIC and the dynamic linker. Until that changes, -pie is
> incompatible with -static.

hmm, yes, we still need PT_DYNAMIC.  as for getting that at runtime, the 
kernel already passes all the program headers via aux tags.  so -static should 
omit PT_INTERP, and search for "-lfoo" as a static library rather than shared.

so, other than having the startup objects to handle this, what else is needed 
by the linker ?  still seems fairly simple to me ;).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/binutils/attachments/20120227/0f0f7dbf/attachment.sig>