[fedora c2] conflicting strerror types

[Kiehlster]

I get this message while trying to compile qmail (netqmail-1.05) on a fedora core 2 box with pretty up-to-date packages:

./compile tls.ctls.c:12: error: conflicting types for 'strerror'/usr/include/string.h:256: error: previous declaration of 'strerror' was heregmake: *** [tls.o] Error 1syscmd: /usr/bin/gmake setupsyscmd: result: 512

Has anyone seen this and could perhaps tell me what I did wrong?  Ive fixed things up until this point including adjusting the vqadmin install because it didn't want to download (I specified a version number, but the download didn't include that version in the url)

Oh, almost forgot, This is in Toaster 4.08

[Kiehlster]

Nobody has a clue on this?

Well, I'm still stuck on this problem, but I'm slowly finding more information on the web about this problem.  So I thought I'd show you some of my findings.  Here's a quote from the shupp toaster mailing list found on mail-archive:

Quote:

After I commented out the strerror declaration from tls.c and I downgraded my openssl from 0.9.8 to 0.9.7g, the compilation completed successfully. But tls.c compilation issued the following warning: ./compile tls.c tls.c: In function `ssl_strerror': tls.c:25: warning: pointer/integer type mismatch in conditional expression And in the line 25, I see an attribution using the commented function: line 25:  return errno == error_timeout ? "timed out" : strerror(errno);

I'd really prefer not to hack up code only to ignore warning messages that could potentially cause a memory leak or even an exploitable vulnerability.

It looks like a problem with a bad programming decision, and possibly related to the openssl-0.9.8 install (which I also have installed because I have to have it installed in order to upgrade perl to 5.8.7 - those darn rpm dependencies always ruin it for everything).  From the code, I have a feeling somebody was trying to overload the function declaration for strerror to accept an integer instead of a string.  Do you suppose we can get a patch to resolve this strerror issue?  Shouldn't be any more work than making it convert 'errno' into something that the normal strerror will accept.