[Scons-users] smartlink and reiterating compile flags on the link step

[Andrew C. Morrow]

On Sat, Oct 31, 2015 at 4:03 PM, Bill Deegan <bill at baddogconsulting.com>
wrote:

> Andrew,
>
>
>
>
> On Sat, Oct 31, 2015 at 10:52 AM, Andrew C. Morrow <
> andrew.c.morrow at gmail.com> wrote:
>
>>
>> Hi All -
>>
>> It seems to me that when using smartlink and therefore using the C or C++
>> compiler to drive the link step for programs and shared libraries, that the
>> various C and C++ language compile flags should be reiterated on the link
>> step. In particular, without regard to ordering:
>>
>> C link for static links should include: $CCFLAGS and $CFLAGS
>> C link for shared links should include $CCFLAGS, $CFLAGS, $SHCCFLAGS, and
>> $SHCFLAGS
>> C++ link for static links should include $CCFLAGS and $CXXFLAGS
>> C++ link for shared links should include $CCFLAGS, $SHCCFLAGS, $CXXFLAGS
>> and $SHCXXFLAGS
>>
>> The rationale is that the presence of certain compile flags may mean that
>> the effects of other compile flags are deferred until link time. In
>> particular, if -flto is passed to the compile step, the desired
>> optimization level should be passed to both the compiler invocation for
>> objects, and to the linker invocation for programs or shared libraries.
>> Currently, that latter part doesn't happen with smartlink.
>>
>
> I'm not sure I agree.
> If we were to modify the code as you speak and there were flags for the
> c/c++ compiler which we did not want to get passed to the linker as well,
> how would we prevent that?
>

That is a fair point.



>
>
>
>>
>> See, for instance the section titled "Be sure you get link-time
>> optimization flags right" here:
>> http://hubicka.blogspot.com/2014/04/linktime-optimization-in-gcc-2-firefox.html
>>
>> I've also verified that building a C++ library (with g++ as the smartlink
>> selected linker) with
>>
>> CCFLAGS="-flto -g -O3" LINKFLAGS='-flto -fuse-ld=gold'
>>
>> vs
>>
>> CCFLAGS="-flto -g -O3" LINKFLAGS='$CCFLAGS -fuse-ld=gold'
>>
>>
>
>> generate different binaries (interestingly, when using clang++ to drive
>> the link step, there is no difference).
>>
>
> What about also passing "-g -O3" in your linkflags?
> It seems that in your case, those flags must be altering the outputted
> binary?
>

Yes, sorry, that was an oversight. However, even after correcting for that,
the binaries still differ. I have not yet dug into how, exactly, they
differ, and I will do so.



>
>
>>
>> Is there a way to configure smartlink  (which isn't really documented) so
>> that the appropriate set of compiler flags are reiterated on the link step?
>> Changing $LINKFLAGS and $SHLINKFLAGS doesn't seem quite right as they don't
>> differentiate between C and C++ linking. Or is this an improvement that
>> should be made to smartlink?
>>
>
> Seems like LINKCFLAGS LINKCXXFLAGS and SH* would be a reasonable way to
> address the need for c or c++ specific link flags?
>

Yes, taking your point above, this might be the best way forward. Presumably

LINKCFLAGS: C specific link flags for both programs and shared libraries
SHLINKCFLAGS: C specific link flags for shared libraries only
LINKCCFLAGS: Common C and C++ link flags for both programs and shared
libraries
SHLINKCCFLAGS: Common C and C++ link flags for shared libraries only
LINKCXXFLAGS: C++ specific flags for both programs and shared libraries
SHLINKCXXFLAGS: C++ specific flags for shared libraries only

And then, assuming that I actually do want to blindly pass all of my
compile flags along to the link step in all cases, I could set:

LINKCFLAGS='$CFLAGS'
SHLINKCFLAGS='$SHCFLAGS'
etc.

I still need to validate my belief that some flags that might be ordinarily
considered as only having compile time effects are in fact necessary on the
link line, particularly with respect to optimization flags when using LTO.
I have some pretty good evidence that this is true for GCC, if not clang.
If so, I think that adding these variables might be a good idea.

Presumably, these would only have any effect when using smartlink?
Otherwise, I don't see how they could be applied.

Thanks,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20151031/5f49b90c/attachment-0001.html>