Mike Stump wrote:
On Nov 10, 2006, at 9:48 AM, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Thanks for pointing that out. But that's not a realistic danger for
the actual application. The accessor function is always going to be
in a library compiled at a separate time. The call will always be
from a program built at a separate time, so -combine isn't a factor.
We are building a compiler to outsmart you. We presently working on
technology (google ("LTO")) to break your code. :-) Don't cry when
we turn it on by default and it does. I'd recommend understanding the
rules and following them.
This raises another interesting point. Aggressive link time optimization
may be nice in a lot of cases, but there are boundaries that should not
(and most likely cannot) be crossed. E.g., you shouldn't go peering
inside libraries to look behind their exported interfaces. You probably
can't, in the case of a shared library, but you probably could for a
static library. This also raises the question of what exactly a static
library represents - is it just a group of object files collected
together for convenience, as an intermediate step in a large build
process, or is it a coherent entity that provides a strictly defined set
of services? GNU libtool is known to create "convenience libraries"
simply as a means of aggregating object files together, before doing
something else with them. (A good argument can be made that this is
stupid; they should be using "ld -r" for that purpose, but that's
another story...) libtool isn't the only example, either. As a
convenience collection, you should be free to globally optimize across
it to your heart's content. But as an actual library, you should stop at
its exported interface. How will you distinguish these two cases, when
all you see is "foo.a" on the command line?
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
