Client build fails on Debian 2.1/slink (i386)
Hi,
I got a conflict with dprintf() when compiling the hobbit client on Debian 2.1.
It runs :
GNU C Library production release version 2.0.7, by Roland McGrath et al. gcc 2.7.2.3
The error is :
gcc -g -O2 -Wall -Wno-unused -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DLINUX -I. -I/tmp/cvf/include -DCLIENTONLY=1 -I. -I../include -c cgiurls.c -o cgiurls.o
In file included from /tmp/cvf/include/libbbgen.h:55,
from cgiurls.c:24:
/tmp/cvf/include/../lib/errormsg.h:21: conflicting types for dprintf' /usr/include/stdio.h:159: previous declaration of dprintf'
I guess this is a problem with former releases of gcc that fails to have multiple prototypes.
If I add -D__STRICT_ANSI__ or -ansi to CFLAGS (stdio.h' dprintf is conditionnal to this), it builds a little more and fails later :
gcc -g -O2 -Wall -Wno-unused -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DLINUX -I. -I/tmp/cvf/include -ansi -DCLIENTONLY=1 -I. -I../include -c sig.c -o sig.o
sig.c: In function setup_signalhandler': sig.c:77: storage size of sa' isn't known
sig.c:107: warning: implicit declaration of function `sigaction'
Any ideas ?
(by the way debian 2.1 needs sco's PATH_MAX... patch too)
-- Charles Goyard - cgoyard at cvf.fr - (+33) 1 45 38 01 31
On Thu, Jul 20, 2006 at 05:35:03PM +0200, Charles Goyard wrote:
I got a conflict with dprintf() when compiling the hobbit client on Debian 2.1.
How about fixing it with "apt-get dist-upgrade" ... ?
Maybe not.
/tmp/cvf/include/../lib/errormsg.h:21: conflicting types for
dprintf' /usr/include/stdio.h:159: previous declaration ofdprintf'
Like they say in the man-page "Clearly, the names were badly chosen."
Indeed.
I've changed all 351 instances of "dprintf" to "dbgprintf"... grab the latest version of the portability patch from http://www.hswn.dk/hobbitsw/betapatches/
Regards, Henrik
Greetings,
I also have been trying to get clientupdate to work, but I have been getting the following errors:
Found update in progress or failed update (started 55 minutes ago) Tar: /bin/hobbitlaunch - cannot create [snipping the rest of the files in the tar] Upgrade failed, tar reported error status
However when I go to untar the file manually, there is nothing wrong with the tar file, so I am not sure what is wrong there.
Also I did have a question about the man page -- in the part where it says: " All files in the tar archive must have filenames relative to the clients' $BBHOME (usually, ~hobbit/client/)."
Does that mean that I should go into ~hobbit/client/ and tar cvf [filename] *
or should I tar cvf [filename] ~hobbit/client/*
thanks, Adam
Henrik Stoerner wrote :
Like they say in the man-page "Clearly, the names were badly chosen."
Indeed.
Indeed.
I've changed all 351 instances of "dprintf" to "dbgprintf"... grab the latest version of the portability patch from http://www.hswn.dk/hobbitsw/betapatches/
Well, thanks a lot !
But...
gcc -g -O2 -Wall -Wno-unused -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DLINUX -I. -I/tmp/snapshot/include -DCLIENTONLY=1 -o logfetch logfetch.c ../lib/hobbitclient.a
logfetch.c: In function logdata': logfetch.c:134: warning: implicit declaration of function fseeko'
logfetch.c:168: warning: implicit declaration of function `ftello'
"These functions are found on SysV-like systems. They are not present in libc4, libc5, glibc 2.0 but available since glibc 2.1. "
The fix should be easy.
(may I say I'm a bit _sorry_ to try to install hobbit on oldies like that ?)
-- Charles Goyard - cgoyard at cvf.fr - (+33) 1 45 38 01 31
On Fri, Jul 21, 2006 at 10:25:43AM +0200, Charles Goyard wrote:
gcc -g -O2 -Wall -Wno-unused -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DLINUX -I. -I/tmp/snapshot/include -DCLIENTONLY=1 -o logfetch logfetch.c ../lib/hobbitclient.a logfetch.c: In function
logdata': logfetch.c:134: warning: implicit declaration of functionfseeko' logfetch.c:168: warning: implicit declaration of function `ftello'"These functions are found on SysV-like systems. They are not present in libc4, libc5, glibc 2.0 but available since glibc 2.1. "
The fix should be easy.
Yes, the LFSDEF in build/Makefile.Linux should be set to blank.
Could you try running the command MAKE=make ./build/lfs.sh on your Debian 2.1 system and tell me what it says ?
(may I say I'm a bit _sorry_ to try to install hobbit on oldies like that ?)
Sure you are :-)
Regards, Henrik
Henrik Stoerner a écrit :
Yes, the LFSDEF in build/Makefile.Linux should be set to blank.
Could you try running the command MAKE=make ./build/lfs.sh on your Debian 2.1 system and tell me what it says ?
Checking for Large File Support ... ERROR: LFS support check failed for large file support
So I blanked LFSDEF as you suggest and it now builds.
(may I say I'm a bit _sorry_ to try to install hobbit on oldies like that ?)
Sure you are :-)
Ever heard of "SINIX-N 5.43 C4001 RM400 1/384 R4000" ? It may be my next build target :).
Thanks a lot Henrik !
-- Charles Goyard - cgoyard at cvf.fr - (+33) 1 45 38 01 31
On Fri, Jul 21, 2006 at 10:51:36AM +0200, Charles Goyard wrote:
Henrik Stoerner a écrit :
Yes, the LFSDEF in build/Makefile.Linux should be set to blank.
Could you try running the command MAKE=make ./build/lfs.sh on your Debian 2.1 system and tell me what it says ?
Checking for Large File Support ... ERROR: LFS support check failed for large file support
OK, that particular check doesn't run in the normal configure process right now, but it means that we could use it to check for LFS support.
(may I say I'm a bit _sorry_ to try to install hobbit on oldies like that ?)
Sure you are :-)
Ever heard of "SINIX-N 5.43 C4001 RM400 1/384 R4000" ? It may be my next build target :).
Actually, I have - guess my age is showing here! As I recall it, it was a Siemens system based on the System V rel 4 version, so it should be fairly similar to your SCO_SV system as far as Hobbit is concerned.
Regards, Henrik
Henrik Stoerner a écrit :
On Thu, Jul 20, 2006 at 05:35:03PM +0200, Charles Goyard wrote:
I got a conflict with dprintf() when compiling the hobbit client on Debian 2.1.
How about fixing it with "apt-get dist-upgrade" ... ?
Maybe not.
dist-upgrading a slink is not that easy...and will take a long time. It will need to gradually go to potato, then woody, then sarge.Direct dist-upgrade to N+2 is not supported by Debian.
I guess that Charles never upgraded because this is a production server or the like. But, hey, that's really really old....no more security support so I deeply hope for you that the thing is not exposed..:-)
participants (4)
-
adam.scheblein＠marquette.edu
-
cgoyard＠cvf.fr
-
christian.perrier＠onera.fr
-
henrik＠hswn.dk