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

[David Faure]

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]

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
KDE/KOffice developer, Qt consultancy projects
Klarälvdalens Datakonsult AB, Platform-independent software solutions