> > What is the recommended version of gcc to use with elog 2.5.9?  I searched
> > the discussion database but found nothing pertaining to this. 
> 
> Well, the same code compiles on gcc and on Visual C++ under Windows, so
> hopefully there is no dependence on the gcc version (;-)
> 
> I use gcc 3.2.3 on Scientific Linux 3.03.

I ask because I get a dependency that I did not have before with 2.5.3. 
Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.

> > I ask because I get a dependency that I did not have before with 2.5.3. 
> > Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> > strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.
> 
> mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
> into a separate directory:
> 
> ...
> -rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
> -rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
> drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
> -rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
> -rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
> -rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
> -rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h
> 
> I have right now no access to 3.4. Once I get it, I will address the errors
> occuring there.

Ah, now I need to figure out how to pickup the new includes.  
BTW, personally I wouldn't take my word regarding the 3.4 errors -- I was simply
trying an alternative version and it is likely that the way ours is configured is the
problem.

Thanks!

> > > I ask because I get a dependency that I did not have before with 2.5.3. 
> > > Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> > > strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.
> > 
> > mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
> > into a separate directory:
> > 
> > ...
> > -rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
> > -rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
> > drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
> > -rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
> > -rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
> > -rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
> > -rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h
> > 
> > I have right now no access to 3.4. Once I get it, I will address the errors
> > occuring there.
> 
> Ah, now I need to figure out how to pickup the new includes.  
> BTW, personally I wouldn't take my word regarding the 3.4 errors -- I was simply
> trying an alternative version and it is likely that the way ours is configured is the
> problem.
> 
> Thanks!


Ok, now I see the issue - the tar extract created the mxml directory in the root (not
under the created directory elog-2.5.9).  Is there a reason why these includes are not
placed in the src dir like the regex.h/.c include?

> > > > I ask because I get a dependency that I did not have before with 2.5.3. 
> > > > Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> > > > strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.
> > > 
> > > mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
> > > into a separate directory:
> > > 
> > > ...
> > > -rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
> > > -rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
> > > drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
> > > -rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
> > > -rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
> > > -rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
> > > -rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h
> > > 
> > > I have right now no access to 3.4. Once I get it, I will address the errors
> > > occuring there.
> > 
> > Ah, now I need to figure out how to pickup the new includes.  
> > BTW, personally I wouldn't take my word regarding the 3.4 errors -- I was simply
> > trying an alternative version and it is likely that the way ours is configured is the
> > problem.
> > 
> > Thanks!
> 
> 
> Ok, now I see the issue - the tar extract created the mxml directory in the root (not
> under the created directory elog-2.5.9).  Is there a reason why these includes are not
> placed in the src dir like the regex.h/.c include?


Ack, ok, I moved the includes into src and tried re-compiling -- and received several
"undefined symbol" errors from the linker.  Clearly the libraries cannot be moved into src?

> [ritt@pc5082 /tmp]$ tar -xzvf elog-2.5.9-2.tar.gz
> elog-2.5.9/
> elog-2.5.9/doc/
> elog-2.5.9/doc/adminguide.html
> ...
> mxml/
> mxml/mxml.c
> mxml/strlcpy.c
> mxml/mxml.h
> mxml/strlcpy.h
> [ritt@pc5082 /tmp]$ cd elog-2.5.9
> [ritt@pc5082 elog-2.5.9]$ make
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elog src/elog.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o regex.o src/regex.c
> ... skipping warnings ...
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o mxml.o ../mxml/mxml.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o strlcpy.o ../mxml/strlcpy.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -I../mxml -o elogd src/elogd.c regex.o
> mxml.o strlcpy.o
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elconv src/elconv.c
> [ritt@pc5082 elog-2.5.9]$
> 
> --------------
> No undefined functions here. I guess you have an old Makefile? Just use the complete tar
> package from the last version.

Ok, now I have it.  Old Makefile because I had to perform some deletions to make "make" work
right under Solaris.  Basically, I took out the ifdef structures - "make" was blowing up on
these.  Everything now compiles perfectly -- don't change anything.  Thanks for that last pointer.

Steve