[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wuftpd-questions
Subject:    Re: wu-ftpd 2.6.1 compiled using 64-bit mode on Solaris7, but transfer value issue.
From:       Bob Luckin <bob () ti ! com>
Date:       2001-09-25 22:21:26
[Download RAW message or body]

Jeff, here's an update; additional comments are inserted below.

On Tue, Sep 25, 2001 at 04:43:08PM -0500, Bob Luckin wrote:
> Jeff,
> 
> I sent a couple of emails on this topic to you last Friday, and got a warning
> bounce on Saturday that they had not yet been delivered; I don't know if
> you ever got them or not.
> 
> I did say that from a quick glance at the code that I thought the file
> transfers would work OK if compiled with the correct switches, but that
> some of the numbers being reported might not be correct, or words to that
> effect.
> 
> On Tue, Sep 25, 2001 at 12:12:37PM -0500, Jeff Koenig wrote:
> > I was able to compile wu-ftpd 2.6.1 in 64-bit mode using Sun's C compiler (Sun \
> > Workshop C compiler v5.0).  (I gave up on gcc since I have heard that gcc has \
> > issues with 64-bit on Solaris.) 
> > I can transfer >2GB files now, but am having an issue with the transfer output \
> > showing negative values: 
> > Example 1:
> > ftp> get 2gigs
> > 200 PORT command successful.
> > 150 Opening BINARY mode data connection for 2gigs (-1988100096 bytes).
> 
> When you compile for large file support, I believe that the off_t file type
> is defined as a longlong.  However, looking at the code in ftpd.c, this
> string is being created by a call to sprintf using the macro L_FORMAT, which
> according to line 4283 of ftpd.c is defined as "ld".  My guess is that for
> large file Solaris compiles this should be "lld" instead.  I'm not sure
> where else L_FORMAT is used; I have a feeling that there are places where
> it is used which really still need to be "ld", so simply changing L_FORMAT
> may break something else.  For a quick and dirty fix, try changing the
> format string on line 4767 to use "lld" instead of L_FORMAT and see if it
> helps.

Thinking about this further, I realised that compiling with xarch=v9, you
should be getting 32-bit ints and 64-bit longs, and I _think_ that off_t
will be a long, not a longlong.

In this case, the "ld" value should result in your getting the correct output.
However, I noticed that you used the "configure" method to compile, instead
of "build".  Configure is known to be flaky under Solaris; a lot of people
(not all) have found that some of the #define macros are not set correctly.
My guess is that the SOLARIS_2 macro has not been defined, resulting in
L_FORMAT being set to "d" instead of "ld".  You might want to try using the
"build" method to compile and see if this fixes the problem.  (You could also
try manually changing the format string to use "ld" instead of L_FORMAT with
your current configuration, to verify if that is the problem.  But if it is,
you probably should still recompile using "build", as you may encounter
other problems due to "configure" not setting macros correctly, in addition
to this one (eg. the wrong command being issued for "ls").

> > Example 2:
> > 226 Transfer complete.
> > local: 2gigs remote: 2gigs
> > 2306867200 bytes received in 7.7e+02 seconds (2938.52 Kbytes/s)
> > ftp> bye
> > 221-You have transferred -1988100096 bytes in 1 files.
> > 221-Total traffic for this session was -1988092930 bytes in 4 transfers.
> > 221-Thank you for using the FTP service on edt6500.
> > 221 Goodbye.
> > 
> > Why does the transfer show as being a negative value?  Any suggestions on how to \
> > resolve that?
> 
> Looks like this one is coming from ftpcmd.y; lines 887 and below.  These
> are written out using "%d" because the variables data_count_total and
> byte_count_total are defined as external int.  These are defined as int
> in ftpcmd.c and referred to in both ftpcmd.y and extensions.c.  An int is
> clearly too small to hold the size of a 2 GB file, so you'll have to change
> these and the corresponding format statements to get the correct value output.
> There may be other similar instances elsewhere in the code.
> 
> I'm not sure if these problems have been fixed in the latest development
> snapshot for 2.7.0 or not, so I don't know whether pulling that would help.

Using "build" instead of configure will not fix this problem; you're going
to have to change these ints to longs either way.

Good luck again !

Cheers, Bob

> > My compiling method is posted below.
> > 
> > Jeff
> > 
> > To Install wu-ftp 2.6.1 with 64-bit mode (for large file support) using Sun's \
> >                 Compiler
> > --------------------------------------------------------------------------------------
> >  Set PATH to use SUN Workshop compiler and not gcc
> > 	TCSH example: % setenv PATH /usr/sbin:/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin
> > 
> > Set CC variable
> > 	TCSH example: % setenv CC cc
> > 
> > Set CFLAGS variable
> > 	TCSH example: % setenv CFLAGS "-xarch=v9 -xCC -Xa"
> > 
> > Run ./configure
> > 	TCSH example: ./configure
> > 
> > Run make
> > 	TCSH example: make
> > 
> > Run "make install"
> > 	TCSH example: make install
> > 
> > > > > "Jeff Koenig" <Jeff.Koenig@experian.com> 09/21/01 11:21AM >>>
> > I am beginning to think I need to compile wu-ftp 2.6.1 in 64-bit mode, but do not \
> > know how to do this with gcc. 
> > Anyone know what the flags or options are to tell gcc to compile wu-ftp 2.6.1 in \
> > 64-bit mode for large file support on Solaris? 
> > Jeff
-- 
Bob Luckin      bob@ti.com      "Coder, adapt; FTP Ada, redo C"


[prev in list] [next in list] [prev in thread] [next in thread]