[Scons-users] How to simultaneously build pie executables and pic shared libraries?

[Andrew C. Morrow]

Hi Bill -

Thanks for the suggestions, some comments below:


>
> Any reason you couldn't use several different environments with the flags
> set as you want and
>

I'd need at least two distinct named top level Environments, one for
Programs, and one for Libraries, and then users would need to import and
export those as appropriate across ~70 SConscript files. My users (other
developers) are going to get it wrong somewhere. They are very accustomed
to writing env.Program or env.Library (Library is overridden to call either
env.StaticLibrary or env.SharedLibrary depending on a global build switch).
With this approach, they would need to remember to call program_env.Program
and library_env.Library. That seems redundant.

Additionally, were someone to accidentally use the PIE configured
Environment to build a shared library it would be an error I think, but if
they used the PIC configured Environment to build an executable it would
just work, but produce an executable that was not position independent.
Tests would all pass, and the security error would likely go unnoticed. I'd
rather make it impossible to get wrong by configuring one Environment so
that .StaticLibrary, .SharedLibrary, and .Program all did the right thing
by construction.

I'd also need to find every place that the existing
common-to-programs-and-libraries Environment is now cloned, modified, and
then used to create several programs and libraries, and do that twice, once
for the Program Environment, and once for the Library Environment. That
seems fragile.


> then use the appropriate one for each type of file you want to build?
> Or you can just specify the flags on the builder:
>
> env.Program(target,sources,
>     PROGCCFLAGS=["-fpie"],
>     SHCCFLAGS=["-fpic"],
>     PROGLINKFLAGS=["-pie"])
>

I want to be able to turn ASLR on and off with a build flag, so the
decision about whether the flags should be present needs to be made at
SCons runtime. Also, not all of the target platforms support the flags, so
their use is conditioned on configure checks. Finally, some platforms, like
Windows, may have entirely different approaches, or require no
configuration at all, like OS X.

And, for this to work, I'd still need to introduce PROG*FLAGS into CCCOM
and LINKCOM, right? I think if I do that then I can just do the right thing
globally. And there are hundreds of .Program and .Library calls, so I don't
really want to change them all.

Ideally, I'd like this to work as a Tool, so that you can just say
env.Tool("ASLR"), and have it modify the 'env' as needed, and then have
env.Program (PIE objects, PIE linkflags), env.StaticLibrary (pie objects),
and env.SharedLibrary (pic objects, shared library linkflags) do the right
thing.

SCons for unix like environments is by default set up to consider building
shared libraries as "do everything you normally do for programs, but with
some extra stuff configured via the SH* flags". But to do ASLR right, pic
shared libraries and pie executables are just different. One is not a
refinement of the other, nor is it produced via a superset of the other's
flags.

Which seems to that motivate the introduction of PROG*FLAGS.

Thanks for your thoughts!

Andrew



> -Bill
>
> On Fri, Oct 23, 2015 at 8:19 PM, Andrew C. Morrow <
> andrew.c.morrow at gmail.com> wrote:
>
>>
>> Hi -
>>
>> I think it is pretty straightforward to get PIE executables with SCons if
>> all linking is static:
>>
>> env.AppendUnique(
>>     CCFLAGS=["-fpie"],
>>     LINKFLAGS=["-pie"],
>> )
>>
>> How to make it work for a build with both executables and shared
>> libraries is not as clear. The problem is that object files destined for
>> the shared libraries need to still be built with -fpic and linked as
>> normal, but object files destined for the executable need to be built with
>> -fpie and then the executable must be linked with -pie:
>>
>> Doing this:
>>
>> env.AppendUnique(
>>     CCFLAGS=["-fpie"],
>>     SHCCFLAGS=["-fpic"],
>>     LINKFLAGS=["-pie"],
>> )
>>
>> doesn't work because objects being compiled for shared libraries receive
>> both CCFLAGS and SHCCFLAGS. Similarly for linking, where the link step for
>> shared libraries gets both LINKFLAGS and SHLINKFLAGS. We definitely don't
>> want to pass -pie to our shared library builds, nor do we want both -fpie
>> and -fpic on the compile line when building objects for shared libraries.
>>
>> It feels like there is a need for PROG[C|CC|CXX]FLAGS and PROGLINKFLAGS?
>> In other words, compiler and linker flags analogous to the SH prefixed
>> variants but that are only used when building objects for an executable or
>> linking an executable.
>>
>> One idea I had was to modify CCCOM, CXXCOM, and LINKCOM to honor
>> PROGC*FLAGS and PROGLINKFLAGS, though I'm not very excited about it. Then I
>> could do this:
>>
>> env.AppendUnique(
>>     PROGCCFLAGS=["-fpie"],
>>     SHCCFLAGS=["-fpic"],
>>     PROGLINKFLAGS=["-pie"],
>> )
>>
>> Does this seem like a viable path to achieve PIE executables with PIC
>> shared libraries, or am I going to run into surprises? Any thoughts on
>> other ways to do this? Has anyone managed to make this work?
>>
>> Thanks,
>> Andrew
>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20151024/e2a1f63f/attachment.html>