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

[Bill Deegan]

Andrew,



On Sat, Oct 31, 2015 at 3:56 PM, Andrew C. Morrow <andrew.c.morrow at gmail.com
> wrote:

>
>
> 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.
>

You may find time stamps or command line flags somehow encoded in the
libraries?
I think I remember chasing something like this down with gnulink before.
Try running you linker with --verbose so you'll see the intermediate steps.
Then you may want to see if you can get it to spit out it's intermediate
products.


>
>
>>
>>
>>>
>>> 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.
>

That seems reasonable.   May need similar flags for Fortran as well. and go?


-Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20151031/9a8b0edf/attachment.html>