First of all let me apologize for the huge delay in getting back to you. I meant to reply, then got distracted with silly things such as full time job, family and all that. Promise to get better at answering questions in the future.
I will try to answer some of your points:
1) My dev machine is 64bit, I promise to be more careful in the future and also compile / test in 32 bit. I used to do lots of 32/64 testing on 10 Linux distros or so back when I was trying to launch Zero BUGS as a startup, but now that I gave up on that
and made it open source I am more frugal.
I am a bit puzzled that Elf32_Xword and size_t are not the same size in 32 bit. I will investigate this weekend.
2) The intent was indeed to have the linker look into third_party_libs (even if the user has those on the system, I WANT to link with the specific version I tested with). Looks like a BUG and your suggested fix looks good.
3) Yeah, moving away from gtksourceview-1.0 was a pain that I kept delaying -- I hope my change from late last night addresses the issue.
Come to think of that, I think I should change my configure script to look for gtksourceview-2.0 first, and only if not found to fail over to gtksourceview-1.0. Or maybe even drop 1.0 altogether.
4) The reason --ui-disable is parsed by the GUI plugin is that I tried to create a component-based architecture where the engine does not need to know about implementation details of the plugin. Each plugin gets a chance to look at the command line and grab
the switches that it recognizes.
If any command line switches are left unconsumed, there should be a warning about unrecognized command line options.
If the GUI does not build, then there's no UI anyway.
5) My recollection is that Eclipse talks to GDB via the Debugger Machine Interface (http://www.linux-foundation.org/en/DMI). I started researching that back in 2007 then I dropped it.
One of the plugins in the Zero Debugger is a Python interpreter that has access to internal C++ interfaces (via boost::python). The idea is to allow users to quickly script the debugger, or build extensions to it in Python.
dmi.py (it is in the source tree under the python directory) was my attempt to implement a DMI-conforming command line interface for the debugger, so that I could talk to it from Eclipse.
I have not tested with D recently but unless Walter did something to his DWARF-outputting code it should work great. For most parts my debugger is language-agnostic. One language-specific part that I always wanted to re-architect is the expression interpreter,
which is built around C/C++ syntax.
Sorry again for the horrible response time. If you have the time and desire to contribute to this project I could give you check-in access.