[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
> 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.
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.