Re: Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #404

From: Henrik Nordström <henrik_at_henriknordstrom.net>
Date: Wed, 17 Mar 2010 21:49:08 +0100

ons 2010-03-17 klockan 03:26 +0000 skrev Amos Jeffries:

> Since we are working on this. Is new/delete operators not something that
> should be in src/base libbase anyway?

Inline operator overloading is a little tricky to have in a lib
unfortunately, due to the same reasons ufsdump linking failed. Better to
have the fallback for those by explicit linking. The issue is if the
operator reference is further down the library chain in which case we
may well end up with the linker pulling in some other random object
which had the operator as an inline instead of our intended "operator
object".

Remeber that linking is a left-to-right operation. Once the linker has
moved a step to the right in resolving symbols it does not look back
when encountering new unresolved symbols, it just further to the right.

The core of this problem is operator overloading using an inline
definition of the operator. The overloaded method needs to get linked to
all modules of the link, even if not all modules is compiled using the
header defining our operator. To solve this the compiler adds a weak
global to each module compiled with the inline overloading operator so
that it may be found somewhere by the modules which is lacking the
inline for some reason. This works fine if every object is meant to be
bundled together, but in our psuedo-libs we have lots of objects which
MUST NOT be referenced in some links, but the linker do not know this
and sometimes makes (for us) bad choices..

Regards
Henrik
Received on Wed Mar 17 2010 - 20:49:13 MDT

This archive was generated by hypermail 2.2.0 : Thu Mar 18 2010 - 12:00:07 MDT