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
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
>>>
On Wednesday, 12. April 2006 18:38, David Faure wrote:
> 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 ;)
We use -fno-common because we don't want common symbols. Why you have common
symbols with unsermake is
On Wednesday 12 April 2006 13:27, Dirk Mueller wrote:
> On Wednesday, 12. April 2006 18:38, David Faure wrote:
>
> > 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 ;)
>
> We use -fno-common because we don't wa
Allen Winter wrote:
>But Dirk, with -fno-common I have no way of linking this yacc/lex
> generated code.
Are both files generated by yacc and lex?
The problem is that both define a symbol called kcalin:
parseholiday.c:FILE*kcalin;
scanholiday.c:#define yyin kcalin
scanholiday.c:FILE
On Wednesday, 12. April 2006 20:24, Allen Winter wrote:
> But Dirk, with -fno-common I have no way of linking this yacc/lex generated
> code.
No, you need to fix your symbol conflict instead.
> I do have hopes (if Cornelius' kode stuff can support it) of replacing
> libkholidays with a brand ne
