Difference in compilation (Re: [Kde-pim] [STATUS] Building KDEPIM with CMake)

[Brad King]

David Faure wrote:
> On Wednesday 12 April 2006 17:55, Allen Winter wrote:
> 
>>On Wednesday 12 April 2006 09:52, David Faure wrote:
>>
>>>On Wednesday 12 April 2006 15:26, Allen Winter wrote:
>>>
>>>>The "solution" I finally committed was to hand-edit the parseholidays.c file  (originally
>>>>generated by yacc from parseholidays.y).  I had to make the FILE *kcalin variable extern.
>>>>But then kcalin is extern in both parseholidays.c and scanholidays.c.  Which doesn't seem correct.
>>>
>>>Well it works since the variable is actually defined in scanholiday.c 
>>>(technically under the name "yyin", but there's a #define yyin kcalin)
>>>
>>>But now I checked the 3.5 branch, and there it's exactly the opposite...
>>>extern FILE *yyin in scanholiday.c and FILE *kcalin in parseholiday.c.
>>>Why was this different in trunk before your commit - that's the real question.
>>>
>>
>>I copied parseholiday.y, parseholiday.[c,h], and scanholiday.c from branches/3.5 into trunk.
>>Re-ran the cmake build process and  got the multiply-defined symbol error for kcalin.
> 
> 
> Ah, you are right, the symbol was defined in scanholiday.c too (without extern).
> 
> In 3.5 branch I get
> $ nm parseholiday.o | grep kcalin
> 00000004 C kcalin
> $ nm scanholiday.o | grep kcalin
> 00000004 B kcalin
> 
> man nm says: "C" The symbol is common.  When  linking, multiple common symbols may appear with the same name.
> 
> With cmake I get "B" for both symbols, hence the "multiple definition" error.
> 
> So this is about a difference during compilation, not during linking.
> In fact most "kcal*" symbols were "C" with unsermake in parseholiday.o.
> 
> unsermake ran gcc with: 
> gcc -DHAVE_CONFIG_H -I../libkholidays -I/devel/kde/src/3/kdepim-3.5/libkholidays -I.. -I/devel/kde/src/3/kdepim-3.5 -I/devel/kde/src/3/kdepim-3.5/libkdepim -I/devel/kde/inst/kde3/include -I/devel/kde/src/3/qt-copy/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -D_FILE_OFFSET_BITS=64 -std=iso9899:1990 -W -Wall -Wchar-subscripts -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -g -O2 -fno-reorder-blocks -fno-schedule-insns -fno-inline -Wformat-security -Wmissing-format-attribute -fPIC -DPIC -c /devel/kde/src/3/kdepim-3.5/libkholidays/parseholiday.c -o ../libkholidays/.libs/parseholiday.o -Wp,-MD,../libkholidays/.deps/parseholiday.TUlo
> 
> cmake runs gcc with:  
> /usr/bin/gcc -Dkholidays_EXPORTS -Wno-long-long -ansi -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -Wmissing-format-attribute -fno-common -O2 -g -fPIC -I/devel/kde/build/4/kdepim/libkholidays -I/devel/kde/src/4/kdepim/libkholidays -I/devel/kde/src/4/kdepim/libkdepim -I/devel/kde/src/4/kdepim -I/devel/kde/build/4/kdepim -I/devel/kde/inst/kde4/include -I/devel/kde/src/4/qt-copy/include -I/devel/kde/src/4/qt-copy/include/Qt -I/devel/kde/src/4/qt-copy/mkspecs/default -I/devel/kde/src/4/qt-copy/include/QtCore -I/devel/kde/src/4/qt-copy/include/QtGui -I/devel/kde/src/4/qt-copy/include/Qt3Support -I/devel/kde/src/4/qt-copy/include/QtAssistant -I/devel/kde/src/4/qt-copy/include/QtDesigner -I/devel/kde/src/4/qt-copy/include/QtNetwork -I/devel/kde/src/4/qt-copy/include/QtOpenGL -I/devel/kde/src/4/qt-copy/include/QtSql -I/devel/kde/src/4/qt-copy/include/QtXml -I/devel/kde/src/4/qt-copy/include/QtSvg -I/devel/kde/src/4/
qt-copy/include/QtTest -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_GNU_SOURCE -DQT3_SUPPORT -DQT_NO_STL -DQT_NO_CAST_TO_ASCII -D_REENTRANT -DQT3_SUPPORT_WARNINGS -DKDE_DEPRECATED_WARNINGS -DHAVE_CONFIG_H=1 -c /devel/kde/src/4/kdepim/libkholidays/parseholiday.c -o libkholidays/CMakeFiles/kholidays.dir/parseholiday.o
> 
> One difference is the lack of -DPIC, but could this matter? This is too lowlevel for me, let's see what kde-buildsystem has to say ;)
> 
> For context, here are the relevant lines:
> 
> parseholiday.c:FILE            *kcalin;
> scanholiday.c:#define yyin kcalin
> scanholiday.c:extern FILE *yyin, *yyout;
> scanholiday.c:FILE *yyin = (FILE *) 0, *yyout = (FILE *) 0;
> 
> [don't look in svn trunk, there's a workaround now]

The difference is the "-fno-common" being passed by CMake which disables 
  common-block ("C") symbols.  This flag is not added by default in 
CMake, so the KDE CMake code must be adding it.

-Brad