Re: [dpdk-dev] [PATCH v2 01/10] build: add an option to enable LTO build

[Ray Kinsella <mdr@ashroe.eu>]

On 24/09/2019 13:59, Neil Horman wrote:
> On Tue, Sep 24, 2019 at 12:25:35PM +0200, Bruce Richardson wrote:
>> On Tue, Sep 24, 2019 at 08:46:25AM +0200, Andrzej Ostruszka wrote:
>>> On 9/23/19 6:13 PM, Bruce Richardson wrote:
>>> [...]
>>>> However, testing on my system with the meson build, I'm getting lots of
>>>> link errors [See below]. Any suggestions?
>>>>
>>>> /Bruce
>>>>
>>>> /usr/bin/ld: /tmp/dpdk-testpmd.hncbtE.ltrans93.ltrans.o: in function `ena_stop':
>>>> <artificial>:(.text+0x9ed6): undefined reference to `rte_timer_stop'
>>> [...]
>>>
> The notion of using the same object file to link to a static archive and a dso
> seems somewhat suspect to me in general.

Well I would say there are two different things going on here, one
doesn't exclude the other.

> I say that because I don't see a way
> for the linker to know/prove at link time that the options used to compile an
> object for target (a) will be the same as those used to compile the same object
> for target (b).  

Yes and no. So I might build an object differently for say a different
platform, but I am not sure I would necessarily build it differently for
static versus dynamic (linking is a different story of course).

(lto is also a different story, as when you build objects with lto on,
as I remember you end up with guile not bytecode)

> In this particular case, you've identified an issue in
> compilation changes that triggers off the building of dso's vs static archives,
> but I could envision a scenario in which you might try to build targets for BSD
> and Linux in parallel, or even for different machines (i.e. build for a least
> common denominator x8664 target, and a highly optimized recent x8664 processor
> with all the ISA extensions enabled). We don't do that currently now of course,
> but we could, and the only way we could do so would be to rebuild all the
> objects with the compilation flags for each separately.

Ok - but there is nothing in the above in this that precludes all of
these object variants being used in both static and dynamic builds, it's
all down to how they are integrated - FD.io VPP does this out of the box
as it happens.

> 
> That said, if the goal is to just overcome this particular situation, it might
> (strong might), be sufficient to simply augment the MAP_STATIC_SYMBOL macro in
> the CONFIG_RTE_BUILD_SHARED_LIB=n case to append the 'used' attribute.
> Ostensibly, LTO would be smart enough then to not eliminate the symbol?  Just a
> thought.

+1, that would be a simple solution.

> 
> But I think we need to take care here.  While its fine solve this particular
> situation, I think the notion of reusing objects for multiple link targets has
> the potential to uncover many issues of this class, which won't be as solveable
> without having to just rebuild objects from scratch.
> 
> Neil
> 
>> Regards,
>> /Bruce
>>