[Scons-users] How to simultaneously build pie executables and pic shared libraries?
Vasily
just.one.man at yandex.ru
Fri Oct 30 16:32:47 EDT 2015
Hi Andrew,
The described case looks like you have several separate environments that
share a lot of stuff except some flags. Environment.Override() or
Environment.Clone() could help you here.
P.S. Parts might be able to help in your case :-) You can take a look at
either parts.tigris.org orbitbucket.org/sconsparts
Thanks,
Vasily
30 окт. 2015 г. 17:05 пользователь "Andrew C. Morrow" <
andrew.c.morrow at gmail.com> написал:
>
> Thanks Bill -
>
> That could probably work, however, that approach does have some problems
> in general. Notably, it doesn't compose. If tool A wants to replace Program
> with a customized builder, and tool also B wants also to replace Program
> with a different builder, you can't use tool A and tool B in the same
> project.
>
> I'll keep thinking about it. For now, I only really need this to work in
> the static linking case, which I think I can do reasonably easily, but of
> course I'd like to ultimately extend it to the dynamic case as well.
>
> Thanks,
> Andrew
>
>
>
> On Sat, Oct 24, 2015 at 5:15 PM, Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>> Andrew,
>>
>> For setting up the environment for ASLR you can us a PseudoBuilder
>> ( see:
>> http://scons.org/doc/production/HTML/scons-user.html#chap-add-method )
>>
>> Is the following correct?
>> c->o for inclusion in shared libraries -fpic
>> c->o for inclusion in programs/static libraries -fpie
>> .o's->.so not -fpie
>> .o's & .so's -> binaries -fpie
>>
>> Here's the what sets up the program builder (from
>> SCons/Tool/__init__.py). I think you could put this in your ASLR pseudo
>> builder and change the action so the build string used whatever
>> variables/flags you want. Based on the LinkAction or ShLinkAction strings..
>> def createProgBuilder(env):
>> """This is a utility function that creates the Program
>> Builder in an Environment if it is not there already.
>>
>> If it is already there, we return the existing one.
>> """
>>
>> try:
>> program = env['BUILDERS']['Program']
>> except KeyError:
>> import SCons.Defaults
>> program = SCons.Builder.Builder(action =
>> SCons.Defaults.LinkAction,
>> emitter = '$PROGEMITTER',
>> prefix = '$PROGPREFIX',
>> suffix = '$PROGSUFFIX',
>> src_suffix = '$OBJSUFFIX',
>> src_builder = 'Object',
>> target_scanner = ProgramScanner)
>> env['BUILDERS']['Program'] = program
>>
>> return program
>>
>>
>>
>> -Bill
>>
>> On Sat, Oct 24, 2015 at 6:17 AM, Andrew C. Morrow <
>> andrew.c.morrow at gmail.com> wrote:
>>
>>>
>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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/20151030/fe9b9892/attachment-0001.html>
More information about the Scons-users
mailing list