Does `-fwhole-program' make sense when compiling shared libraries?

Dave Korn dave.korn.cygwin@gmail.com
Tue May 18 13:58:00 GMT 2010


[ hmf.  This one got lost to an smtp error when I sent it yesterday.  It
appears there's more or less agreement that at the moment you're supposed to
manually annotate all external entry points if you want to use -fwhole-program
on a library.  On windows, where we often do that anyway, it looks like it
would make a great deal of sense to infer externally_visible from dllexport. ]

On 17/05/2010 19:26, Dave Korn wrote:
> On 17/05/2010 18:57, Toon Moene wrote:
>> On 05/17/2010 08:08 PM, Dave Korn wrote:
>>>      Hi!
>>>
>>>    PR42904 is a bug where, when compiling a windows DLL using
>>> -fwhole-program,
>>> the compiler optimises away the entire library body, because there's no
>>> dependency chain related to 'main' to anchor it.
>> Aren't "shared library" and "whole program" mutually exclusive concepts ?
>>
>> The mere fact that you are building a library means that it cannot be
>> the whole program, and because a shared library cannot be determined to
>> have being used by any fixed program, by definition cannot be "the whole
>> program".
>>
>> Or so I'd think.
> 
>   Well, indeed that is strictly the case, but a shared library is also a
> self-contained bundle of dependencies, and if all the externally visible
> functions were treated as roots like 'main', I would have thought
> -fwhole-program could usefully do its thing.  So I wondered if anyone had
> thought about making it work.  (I guess the PR should be treated as an
> enhancement request.)
> 
>     cheers,
>       DaveK




More information about the Gcc mailing list