1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: "Size of symbol changed" warnings building EPICS Base 3.14.12.2 |
From: | Dirk Zimoch <[email protected]> |
To: | Andrew Johnson <[email protected]> |
Cc: | [email protected] |
Date: | Tue, 13 Mar 2012 11:07:04 +0100 |
Andrew, Lewis,If the C++ template instantiation is the problem, then the -fno-implicit-templates command line option may help. If that is used, the compiler will not create any code "behind the scenes".
Instead it requires that for each template, you explicitly specify in which file you want to have the implementation. See section "Where's the Template?" in the gcc info pages.
In exactly one source code file one has to write a line like template class epicsSingleton<localHostName>::reference; Dirk Andrew Johnson wrote:
Hi Dirk,On 3/7/12 2:50 AM, Dirk Zimoch wrote:These two functions, epicsSingleton<localHostName>::reference::~reference(void) and epicsSingleton<localHostName>::reference::operator->(void) both contain 'assert' (see src/libCom/cxxTemplates/epicsSingleton.h). 'assert' is a macro: # define assert(exp) ((exp) ? (void)0 : \ epicsAssert(__FILE__, __LINE__, #exp, epicsAssertAuthor)) Depending on the optimization level, '(void)0' may be eliminated and the code becomes shorter (by 4 bytes = 1 PPC instruction). Try to 'make clean' in the epics base top directory and compile again.The problem is more subtle than that, although I suspect that different optimization levels is probably the underlying cause.Remember Lewis is using a very old version of g++, from back when C++ templates were new; my guess is that ldppc is recompiling the template instances it needs to link the code behind the scenes, but it wasn't told the optimization level that g++ppc used to compile the instances that appear in the .o files it's linking with so it doesn't get the same length code and generates that warning. There may be a flag we could turn on to show more about what's going on inside ldppc, but it's really not worth looking into IMHO; better to spend the time upgrading to vxWorks 5.5.- Andrew