[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Bacula Windows Client 64bit build.

On Tuesday 29 July 2008 22:36:20 Martin Simmons wrote:
> >>>>> On Tue, 29 Jul 2008 09:03:12 +0530, Riyas Y said:
> >
> > 1.            We use Bacula series 1.39 and understand that it supports
> > taking builds targeting 64 bit linux machines.
> >
> > But in the code at many places we can see poiners, size_t  assigned to
> > int datatypes..
> >
> > How can we say that this won't create any problems?
> Version 1.39 is very old, so you should check in the latest version first
> to see if it has been fixed.
> If it is still a problem, please give examples of each type of assignment
> (file name and line number).
> > 2.            Does anything need to be considered  to take Bacula Client
> > only build targeting 64 bit architectures?
> >
> > We want a bacula client running as a native 64 bit application rather
> > than as a legacy 32 bit application on Windows Server 2003 (or any other
> > 64 bit windows OS)?
> The obvious question is why?  Bacula client doesn't usually need much
> memory.
> The main problem is that Win32 bacula is usually cross compiled using
> mingw, but I think that doesn't support 64bit yet.

Martin has hit this right on with his remarks:

A couple of addition points:
- Bacula core code is 32/64 bit clean, that is a well established fact
- The Win32 I/O code is 32/64 bit clean.
- I cannot be 100% that the Win32 "compat" layer, or Microsoft's APIs are
  32/64 bit clean.
- In general there is nothing wrong with referencing "int"; on a 64 bit 
system "int" is 64 bits.  The problem occurs on 32 bit systems where an int 
is 32 bits, but I know of no cases in Bacula where using ints is a problem.
- size_t is not a pointer, and I know of no case where a pointer in Bacula is 
assigned to an int.  Casting or referencing size_t as an int, in most cases 
in Bacula is perfectly OK even on 32 bit systems.
- Anyway, getting a 64 bit Win32 is not very high on our priority list, but if 
someone can find problems in the current code and submit patches and modify 
the current build procedure to produce 64 bit Win32 binaries, we would be 
happy to accept them.  
- I strongly suggest that you check with us as there are *many* places in 
Bacula were 32 bit entities are used because 64 bits is not needed (e.g. the 
I/O read/write lengths are a maximum 1MB so 64 bit is not needed), and there 
is no need to change that code.

Best regards,


This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list

This mailing list archive is a service of Copilotco.