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

[Bill Deegan]

smartlink determines what linker to use to link an executable based on the
contents.
For example if the contents is plain C vs C++ you many need a different
linker/flags/etc.

On Tue, Nov 3, 2015 at 8:53 AM, Neal Becker <ndbecker2 at gmail.com> wrote:

> 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?
>
> _______________________________________________
> 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/20151103/3766466b/attachment.html>