I'm trying to compile my single main.d program in Arch Linux 64-bit, but it won't link, and I don't understand why.

Attempt 1:
----------
dmd source/main.d -Idwt/imp -Jdwt/org.eclipse.swt.gtk.linux.x86/res -L-Ldwt/lib -L--verbose -L-l:org.eclipse.swt.gtk.linux.x86 -L-l:dwt-base -L-lgtk-x11-2.0 -L-lgdk-x11-2.0 -L-latk-1.0 -L-lgdk_pixbuf-2.0 -L-lgthread-2.0 -L-lpangocairo-1.0 -L-lfontconfig -L-lXtst -L-lXext -L-lXrender -L-lXinerama -L-lXi -L-lXrandr -L-lXcursor -L-lXcomposite -L-lXdamage -L-lX11 -L-lXfixes -L-lpango-1.0 -L-lgobject-2.0 -L-lgmodule-2.0 -L-ldl -L-lglib-2.0 -L-lcairo -L-lgnomeui-2

...
attempt to open main.o succeeded
main.o
attempt to open org.eclipse.swt.gtk.linux.x86 failed
attempt to open dwt/lib/org.eclipse.swt.gtk.linux.x86 failed
attempt to open /usr/lib/org.eclipse.swt.gtk.linux.x86 failed
...
attempt to open dwt-base failed
attempt to open dwt/lib/dwt-base failed
attempt to open /usr/lib/dwt-base failed

...
/usr/bin/ld: cannot find org.eclipse.swt.gtk.linux.x86
/usr/bin/ld: cannot find dwt-base
...

But the libs are there...
ls -al dwt/lib
total 26488
drwxr-xr-x  2 mike users     4096 Jul 13 15:02 .
drwxr-xr-x 11 mike users     4096 Jul 13 10:04 ..
-rw-r--r--  1 mike users  2216828 Jul 13 13:02 dwt-base.a
-rw-r--r--  1 mike users 24894894 Jul 13 13:02 org.eclipse.swt.gtk.linux.x86.a


Attemp 2: Add .a to the missing lib files
attempt to open org.eclipse.swt.gtk.linux.x86.a failed
attempt to open dwt/lib/org.eclipse.swt.gtk.linux.x86.a succeeded
attempt to open /usr/lib/org.eclipse.swt.gtk.linux.x86.a failed
...
attempt to open dwt-base.a failed
attempt to open dwt/lib/dwt-base.a succeeded
attempt to open /usr/lib/dwt-base.a failed
...
/usr/bin/ld: cannot find org.eclipse.swt.gtk.linux.x86.a
/usr/bin/ld: cannot find dwt-base.a
...

It says it finds the files, but still fails to link.  All other libs seem to link fine.  What am I doing wrong?

Thanks,
Mike

On Sunday, 13 July 2014 at 06:24:29 UTC, Mike wrote:
> I'm trying to compile my single main.d program in Arch Linux 64-bit, but it won't link, and I don't understand why.
>
> Attempt 1:
> ----------
> dmd source/main.d -Idwt/imp -Jdwt/org.eclipse.swt.gtk.linux.x86/res -L-Ldwt/lib -L--verbose -L-l:org.eclipse.swt.gtk.linux.x86 -L-l:dwt-base -L-lgtk-x11-2.0 -L-lgdk-x11-2.0 -L-latk-1.0 -L-lgdk_pixbuf-2.0 -L-lgthread-2.0 -L-lpangocairo-1.0 -L-lfontconfig -L-lXtst -L-lXext -L-lXrender -L-lXinerama -L-lXi -L-lXrandr -L-lXcursor -L-lXcomposite -L-lXdamage -L-lX11 -L-lXfixes -L-lpango-1.0 -L-lgobject-2.0 -L-lgmodule-2.0 -L-ldl -L-lglib-2.0 -L-lcairo -L-lgnomeui-2
>
> ...
> attempt to open main.o succeeded
> main.o
> attempt to open org.eclipse.swt.gtk.linux.x86 failed
> attempt to open dwt/lib/org.eclipse.swt.gtk.linux.x86 failed
> attempt to open /usr/lib/org.eclipse.swt.gtk.linux.x86 failed
> ...
> attempt to open dwt-base failed
> attempt to open dwt/lib/dwt-base failed
> attempt to open /usr/lib/dwt-base failed
>
> ...
> /usr/bin/ld: cannot find org.eclipse.swt.gtk.linux.x86
> /usr/bin/ld: cannot find dwt-base
> ...
>
> But the libs are there...
> ls -al dwt/lib
> total 26488
> drwxr-xr-x  2 mike users     4096 Jul 13 15:02 .
> drwxr-xr-x 11 mike users     4096 Jul 13 10:04 ..
> -rw-r--r--  1 mike users  2216828 Jul 13 13:02 dwt-base.a
> -rw-r--r--  1 mike users 24894894 Jul 13 13:02 org.eclipse.swt.gtk.linux.x86.a
>
>
> Attemp 2: Add .a to the missing lib files
> attempt to open org.eclipse.swt.gtk.linux.x86.a failed
> attempt to open dwt/lib/org.eclipse.swt.gtk.linux.x86.a succeeded
> attempt to open /usr/lib/org.eclipse.swt.gtk.linux.x86.a failed
> ...
> attempt to open dwt-base.a failed
> attempt to open dwt/lib/dwt-base.a succeeded
> attempt to open /usr/lib/dwt-base.a failed
> ...
> /usr/bin/ld: cannot find org.eclipse.swt.gtk.linux.x86.a
> /usr/bin/ld: cannot find dwt-base.a
> ...
>
> It says it finds the files, but still fails to link.  All other libs seem to link fine.  What am I doing wrong?
>
> Thanks,
> Mike

Nevermind, just found out only 32-bit libs are created.

On 2014-07-13 08:32, Mike wrote:

> Nevermind, just found out only 32-bit libs are created.

Yes, currently DWT only supports 32bit.

-- 
/Jacob Carlborg

On Sunday, 13 July 2014 at 10:00:46 UTC, Jacob Carlborg wrote:
> On 2014-07-13 08:32, Mike wrote:
>
>> Nevermind, just found out only 32-bit libs are created.
>
> Yes, currently DWT only supports 32bit.

I'm using Arch Linux 64, and the multilibs are missing libgnomeui-2.

What are your future plans for DWT?  Are you still interested in investing into it or are you yielding to gtkd/qtd/etc..?

I really like the library and was able to pick it up very quickly.  If you're interested in putting more into it, what can I do to help?  Can you gude me through the changes necessarry to port it to 64-bit?

Mike

On 2014-07-14 18:57, Mike wrote:

> I'm using Arch Linux 64, and the multilibs are missing libgnomeui-2.
>
> What are your future plans for DWT?  Are you still interested in
> investing into it or are you yielding to gtkd/qtd/etc..?

I'm currently not working on DWT. When I will do that again it will be on the OS X port. I'm still trying to keep it up to date with the latest version of DMD, reviewing pull requests and helping out here.

> I really like the library and was able to pick it up very quickly.  If
> you're interested in putting more into it, what can I do to help?  Can
> you gude me through the changes necessarry to port it to 64-bit?

Absolutely. First, there are someone else that is already working on a 64bit port, if I understand it correctly [1]. Perhaps you could collaborate.

As for the guidance. I think it's easiest to just try and compile it for 64bit and see what errors you get. Then I can help with more specific problems that you encounter.

Start by removing the "-m32" flags in build.d [2], which forces it to compile for 32bit. Then I would guess most errors will be for types declared as "int" when they should be declared as "size_t" or "ptrdiff_t".

I have no idea how the GTK and Gnome interfaces work, if they are different on 64bit. I didn't write the original code for DWT.

[1] http://forum.dlang.org/thread/cpmhhmslzyvtpkzsgkaj@forum.dlang.org

[2] https://github.com/d-widget-toolkit/dwt/blob/master/build.d

-- 
/Jacob Carlborg

On Monday, 14 July 2014 at 19:18:46 UTC, Jacob Carlborg wrote:
>
> As for the guidance. I think it's easiest to just try and compile it for 64bit and see what errors you get. Then I can help with more specific problems that you encounter.
>

Well, I haven't tried to build yet, but I have been going through the source code, and I found something interesting.

I downloaded the swt source code for both Win32 and Win64, and compared them in WinMerge.

What's interesting is the source code is littered with stuff like this:

File: org/eclipse/swt/widgets/IME.java


SWT - Win32
*******************
LRESULT WM_KILLFOCUS (int /*long*/ wParam, int /*long*/ lParam) {
	if (!isInlineEnabled ()) return null;
	int /*long*/ hwnd = parent.handle;
	int /*long*/ hIMC = OS.ImmGetContext (hwnd);
	if (hIMC != 0) {
		if (OS.ImmGetOpenStatus (hIMC)) {
			OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR, OS.CPS_COMPLETE, 0);
		}
		OS.ImmReleaseContext (hwnd, hIMC);
	}
	return null;
}

SWT - Win64
********************
LRESULT WM_KILLFOCUS (long /*int*/ wParam, long /*int*/ lParam) {
	if (!isInlineEnabled ()) return null;
	long /*int*/ hwnd = parent.handle;
	long /*int*/ hIMC = OS.ImmGetContext (hwnd);
	if (hIMC != 0) {
		if (OS.ImmGetOpenStatus (hIMC)) {
			OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR, OS.CPS_COMPLETE, 0);
		}
		OS.ImmReleaseContext (hwnd, hIMC);
	}
	return null;
}


DWT
********************
LRESULT WM_KILLFOCUS (int /*long*/ wParam, int /*long*/ lParam) {
    if (!isInlineEnabled ()) return null;
    auto hwnd = parent.handle;
    auto hIMC = OS.ImmGetContext (hwnd);
    if (hIMC !is null) {
        if (OS.ImmGetOpenStatus (hIMC)) {
            OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR, OS.CPS_COMPLETE, 0);
        }
        OS.ImmReleaseContext (hwnd, hIMC);
    }
    return null;
}

It appears DWT has modeled any `Handle`s as `void*`, and therefore uses `auto` whenever possible.  I could probably do a search & replace for "int /*long*/" or "/*long*/ int" and replace it with "ptrdiff_t" and cover 80% of the necessary changes.

Thoughts?

Also, could you please answer the following questions for me?
* What version of SWT is the current DWT source code based on?
* How would you like me to submit pull requests?  Little-by-little, or one big whopper?
* How does one go about testing DWT?

Thanks for the help.

Mike

On 2014-07-19 01:47, Mike wrote:

> Well, I haven't tried to build yet, but I have been going through the
> source code, and I found something interesting.
>
> I downloaded the swt source code for both Win32 and Win64, and compared
> them in WinMerge.
>
> What's interesting is the source code is littered with stuff like this:
>
> File: org/eclipse/swt/widgets/IME.java

Yes, they have a tool (or built step) that replaces "int /*long*/" with "long /*int*/" to convert to 64bit.

>
> SWT - Win32
> *******************
> LRESULT WM_KILLFOCUS (int /*long*/ wParam, int /*long*/ lParam) {
>      if (!isInlineEnabled ()) return null;
>      int /*long*/ hwnd = parent.handle;
>      int /*long*/ hIMC = OS.ImmGetContext (hwnd);
>      if (hIMC != 0) {
>          if (OS.ImmGetOpenStatus (hIMC)) {
>              OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR,
> OS.CPS_COMPLETE, 0);
>          }
>          OS.ImmReleaseContext (hwnd, hIMC);
>      }
>      return null;
> }
>
> SWT - Win64
> ********************
> LRESULT WM_KILLFOCUS (long /*int*/ wParam, long /*int*/ lParam) {
>      if (!isInlineEnabled ()) return null;
>      long /*int*/ hwnd = parent.handle;
>      long /*int*/ hIMC = OS.ImmGetContext (hwnd);
>      if (hIMC != 0) {
>          if (OS.ImmGetOpenStatus (hIMC)) {
>              OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR,
> OS.CPS_COMPLETE, 0);
>          }
>          OS.ImmReleaseContext (hwnd, hIMC);
>      }
>      return null;
> }
>
>
> DWT
> ********************
> LRESULT WM_KILLFOCUS (int /*long*/ wParam, int /*long*/ lParam) {
>      if (!isInlineEnabled ()) return null;
>      auto hwnd = parent.handle;
>      auto hIMC = OS.ImmGetContext (hwnd);
>      if (hIMC !is null) {
>          if (OS.ImmGetOpenStatus (hIMC)) {
>              OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR,
> OS.CPS_COMPLETE, 0);
>          }
>          OS.ImmReleaseContext (hwnd, hIMC);
>      }
>      return null;
> }
>
> It appears DWT has modeled any `Handle`s as `void*`, and therefore uses
> `auto` whenever possible.  I could probably do a search & replace for
> "int /*long*/" or "/*long*/ int" and replace it with "ptrdiff_t" and
> cover 80% of the necessary changes.
>
> Thoughts?

Ideally I would like that the native type is used, that's what I've done in the OS X port. But if the existing code uses "int /*long*/" then I would say it's acceptable to use "ptrdiff_t". Perhaps we want to come up with a new name?

> Also, could you please answer the following questions for me?
> * What version of SWT is the current DWT source code based on?

It's 3.449.0, at least according to this [1].

> * How would you like me to submit pull requests? Little-by-little, or
> one big whopper?

If possible, smaller changes. But I would prefer DWT to be buildable in-between pull requests.

> * How does one go about testing DWT?

[1] https://github.com/d-widget-toolkit/org.eclipse.swt.win32.win32.x86/blob/master/src/org/eclipse/swt/internal/Library.d#L31-L41

-- 
/Jacob Carlborg

On 2014-07-19 01:47, Mike wrote:

> * How does one go about testing DWT?

I don't have a good answer to that. I mostly try the snippets and see that they behave correctly. For some snippets it might not always be easy to see what they're supposed to do or behave. In that case I compare with the the behavior of the Java version.

SWT has some kind of tests [1], which probably should be ported at some time.

[1] http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/tests/org.eclipse.swt.tests

-- 
/Jacob Carlborg

On Saturday, 19 July 2014 at 15:10:11 UTC, Jacob Carlborg wrote:
> On 2014-07-19 01:47, Mike wrote:
>
>> * How does one go about testing DWT?
>
> I don't have a good answer to that. I mostly try the snippets and see that they behave correctly. For some snippets it might not always be easy to see what they're supposed to do or behave. In that case I compare with the the behavior of the Java version.
>
> SWT has some kind of tests [1], which probably should be ported at some time.
>
> [1] http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/tests/org.eclipse.swt.tests

Interesting! How was the original port from SWT to DWT done?  Was some utility used?

Mike

On Saturday, 19 July 2014 at 15:04:33 UTC, Jacob Carlborg wrote:
>
> Ideally I would like that the native type is used, that's what I've done in the OS X port. But if the existing code uses "int /*long*/" then I would say it's acceptable to use "ptrdiff_t". Perhaps we want to come up with a new name?

What do you mean by "native type"?  I thought the only native types in D were `size_t` and `ptrdiff_t`.  What's the actual syntax you use in the OSX port?


If you're looking for alternative names for `size_t` and `ptrdiff_t` how about:

alias native_int = ptrdiff_t;
alias native_uint = size_t;

Mike