Linux 64bit branch
doob at me.com
Sun Jan 12 03:42:30 PST 2014
On 2014-01-12 08:19, Jesse Phillips wrote:
> I wanted to mention that I have a branch for the base and gtk
> repositories which compile under 64bit.
Thanks, that's great.
> I don't know if changes are correct, in the since that I don't have a
> grasp on the boundaries with the gtk libraries. They shouldn't affect
> 32bit though (it also compiles)
I had a look at the changes. I noticed a couple things:
* Most changes seems to be related to changing "int" to "size_t" or
"ptrdiff_t". "int" was used because that's what the Java API uses. Java
doesn't even have unsigned types. Is the changes really necessary? Does
it require a lot of casts otherwise?
The place where it is correct to change the type is when the SWT scource
code look something like this: "(int)/*64*/". That is a hint to a tool
SWT uses to automatically translate between 32 and 64bit. These cases
should always be replaced with the native type. Be it either a pointer
type, size_t or something else.
* Currently DWT is compatible with both D1 and D2. Could you please use
"to!(T)(args)" instead and import "tango.util.Convert" when Tango is
used to make it compatible with D1 as well. I do intend to drop the
support for D1 at some point, either when I merge in DWT-Cocoa or when
there is a significant large change making it not practical to do the
change both for D1 and D2. Anyway, I want to drop the support in a
controlled way, making a D1 branch, make an announcement and so on. I
don't think this is a significant large change to break the D1 support.
It's easy to make it compatible with both D1 and D2.
* I see that you have used "auto". I prefer we try to avoid using "auto"
at all. My experience with using "auto" in DWT is that it's easier to
make a mistake when porting. When not using "auto" both the return type
of a function and in the expression where it's used need to have the
correct type. Also, "auto" doesn't exist in Java and we want to stay as
close to the Java source code to make it easier to merge future versions.
> As I have not built a working example yet I won't be creating a pull
> request, the compiler message for snippet 107:
> (org-eclipse-swt-program-Program.o): undefined reference to symbol
> //usr/lib/x86_64-linux-gnu/libgnomevfs-2.so.0: error adding symbols: DSO
> missing from command line
> Which could be an issue with ordering or missing a library. I don't
> know if I'll get anything working, but wanted to provide information
> that there is a compiling lib for 64bit out there.
Ok, I see. Have you verified that you have all the necessary libraries
installed? They're listed here:
More information about the Digitalmars-d-dwt