"Size of symbol" changes when linking

[houchin]

Hi,

I'm trying to refactor the Aerospace ADL Front End distribution, and in the process of screwing something up, I noticed some warnings that occur even in my known good older installations, which bother me more than the others. There are two functions that seem to be being compiled differently depending on which portion of ADL compiles them. I am seeing this in the UW distributed ADL 4:

Here's an example of the error messages:

Code: Select all

/usr/bin/ld: Warning: size of symbol `void ProCmnProductDictionary::getDefaultFill<char>(ProCmnProductFieldAccessors*, char&)' changed from 2162 in ProGipViirsNbarNdviDispatcherMain.o to 1779 in /daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/lib/libProEdrViirsNHFutil_lib.a(ErrorHandler.o)

The three functions that appear to have different compilations are:

• DDSUTIL_PairedPerfSnap(int, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
• DDSUTIL_PerfSnapFunction(int, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
• DDSUTIL_SinglePerfSnap(int, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, long long, long long, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
• ProCmnDegRadConvertor<double>::degToRadConversion(double*, double*, int, int)
• ProCmnDegRadConvertor<double>::radToDegConversion(double*, double*, int, int)
• ProCmnDegRadConvertor<float>::degToRadConversion(float*, float*, int, int)
• ProCmnDegRadConvertor<float>::radToDegConversion(float*, float*, int, int)
• operator<<(std::basic_ostream<char, std::char_traits<char> >&, ProSdrCmnGeoEclipse const&)
• operator<<(std::basic_ostream<char, std::char_traits<char> >&, RawDataRecordStatusRegister&)
• operator<<(std::basic_ostream<char, std::char_traits<char> >&, SYSTEMTIME&)
• unsigned char* IngMsdCoefficients_Converter::convertFieldToValue<unsigned char*>(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned char*)
• void ProCmnProductDictionary::getDefaultFill<char>(ProCmnProductFieldAccessors*, char&)
• void ProCmnProductDictionary::getDefaultFill<unsigned char>(ProCmnProductFieldAccessors*, unsigned char&)

So I dug through the build log to see if I could tell exactly how those two functions were being built differently. Here are the two g++ commands, translating "." and ".." in the -I options based on the current working directory at that point in the build script:

Code: Select all

/apps/gcc-4.4.5/bin/g++ -DBYTE_ORDER_LE -DADL_ENV -D_USE_FLAT_FILE_ -D_THREAD_SAFE -DGCC -m64 -fPIC -Wall -Wno-unknown-pragmas      -O3
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/GIP/VIIRS/GridToGrid/NbarNdviDispatcher/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/GIP/VIIRS/GridToGrid/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/AlgorithmFactory/VIIRS/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/DMS/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/INF/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/INF/common/exceptions/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/INF/common/util/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/INF/util/cfg/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/INF/util/time/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/ING/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/common/local/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/common/local/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/common/local/include
-c ProGipViirsNbarNdviDispatcherMain.cpp -o ProGipViirsNbarNdviDispatcherMain.o

Code: Select all

/apps/gcc-4.4.5/bin/g++ -DBYTE_ORDER_LE -DADL_ENV -D_USE_FLAT_FILE_ -D_THREAD_SAFE -DGCC -m64 -fPIC -Wall -Wno-unknown-pragmas      -O3
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/EDR/VIIRS/ocean/nhf/src/util_lib
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/EDR/VIIRS/ocean/nhf/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/DMS/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/INF/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/INF/common/exceptions/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/INF/common/util/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/INF/util/cfg/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/INF/util/time/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/ADL/CMN/Utilities/ING/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/common/local/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/common/local/include
-I/daq7_raid7/vsdr/aero/user2/houchin/trunk/common/local/include
-c ErrorHandler.cpp -o ErrorHandler.o

(Note that the triple inclusion of common/local/include is due to the UW COTS library structure pointing at the same place for multiple COTS packages)

The first two -I options are to include directories directly relative to the specific source file itself, so I expect those would not match. However, for ProGipViirsNbarNdviDispatcherMain.o, it is also pointing at ADL/CMN/Utilities/AlgorithmFactory/VIIRS/include.

An yes, I realize that this warning is related to the size of compiled code and not the size of a data structure in memory. But it still bothers me. Can someone convince me this really can be ignored?

[kbisanz]

After seeing this post we noticed similar warnings for us. I'll admit it does sound somewhat more serious than other warnings. We haven't noticed any issues it's causing though.

We'll continue to investigate and post back if we find anything out.