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

From: Amos Jeffries <>
Date: Wed, 17 Mar 2010 22:01:04 +0000

On Wed, 17 Mar 2010 21:49:08 +0100, Henrik Nordström
<> wrote:
> ons 2010-03-17 klockan 03:26 +0000 skrev Amos Jeffries:
>> Since we are working on this. Is new/delete operators not something
>> 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

Yes I know that. Which is why I suggested libbase. The only things that
should be to its right are libmisc, libcompat and the system libraries.

libmisc is slowly being split into OS portability libcompat and shared
Squid code libbase. With the main underlying tools and things being moved
into it from the src/*.o side.

Received on Wed Mar 17 2010 - 22:01:09 MDT

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