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

[Neal Becker]

Bill Deegan wrote:

> 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

What is smartlink?