[fpc-devel] 2.0.4-rc3 available

[Dave Parsons]

On Mon, 14 Aug 2006 18:48:55 +0200 (CEST), Tomas Hajny wrote:

> Dave Parsons wrote:
> > On Mon, 14 Aug 2006 13:15:51 +0200 (CEST), Tomas Hajny wrote:
> >> Dave Parsons wrote:
> >> > On Sun, 13 Aug 2006 23:08:29 +0200, Tomas Hajny wrote:
>  .
>  .
> > To help me, I would like to know for instance how to bootstrap fpc
> > on a new platform. What is the original compiler? Any form of
> > Pascal compiler, gcc or whatever.
> > How dependent on fpc is Lazarus?
> 
> Lazarus is fully dependent on FPC in the sense that it's FPC which is used
> for all compilation.

Yes, I should have asked perhaps, how dependent on FPC is FPC.
(see my reply to Jonas)


> >>From what I have read, Lazarus uses Gtk as its widget set.
> > Gtk 1.2.10 is available on OpenVMS and a Gtk 2 has been spoken
> > about - one day perhaps. Same applies to OS/2. Is Gtk2 essential?
> 
> GTK availability on OS/2 is little bit problematic at the moment - as far
> as I know, the only available version needs to have X Window libraries
> available (e.g. using XFree86/2 installation). There's no native port
> available (meaning a port based on native GUI functions provided directly
> by OS/2). As you might know, XFree86/2 basically provides another desktop
> running in full-screen, i.e. separated from native OS/2 apps, etc. There's
> a project supposed to provide X Window libraries allowing to use usual GUI
> windows (i.e. running on the usual OS/2 desktop), but I'm not sure whether
> it's in useable state already.

>From further reading I now believe that Lazarus uses Gtk1 which is
available everywhere, so that helps. Correct me if I am wrong.

Re. OS/2, XFree/2 etc. yes the only Gtk versions that I have found
need X window support, typically XFree/2 or HOBX11 - or Everblue
which is what you were referring to I suspect. I had a look at
that a year or so ago but got side tracked onto wxWidgets. Maybe
my time would have been better spent pursuing Everblue instead;-(

> > Re above and compilers, I did notice the EMX libs there, what are
> > they used for as etc., or is gcc involved somewhere.
> 
> GCC isn't involved at all. We use the following GNU stuff at the moment:
> 
> 1) binutils (as.exe and ld.exe). as.exe is available in new versions too,
> ld.exe not really as far as I know. Newer versions of as.exe (distributed
> with Innotek GCC builds) are dynamically linked to libcXXX.dll and two
> other libs (e.g. bfd2e.dll and iintl6i.dll).
> 
> 2) Existing (ancient) ld.exe for OS/2 can only produce (modified) a.out
> format executables, and this format is supported by the existing (equally
> ancient) GDB (plus the GUI wrapper PMGDB). This format implies always
> having EMX.DLL linked in (performed automatically by ld.exe). In addition
> to this, helper routine used to allow access to HW ports (unit ports) is
> used as well.
> 
> 3) EMXWRAP.DLL is a wrapper library for calling console 16-bit OS/2 API
> functions in KBDCALLS.DLL, MOUCALLS.DLL and VIOCALLS.DLL (text mode
> console access as used in our text-mode IDE - keyboard, mouse and video).
> 
> 
> The following alternatives would be possible:
> 
> 1) FPC already has internal assembler and linker, but these don't support
> the OS/2 target at the moment. Changing the assembler part to support
> output of a.out object files wouldn't make much sense, so you'd basically
> need to change both sides in parallel (although you could possibly use a
> different external linker in the first phase, like LINK386.EXE distributed
> with OS/2 or Watcom linker). Alternatively, it might be possible to switch
> to Watcom assembler and Watcom linker for OS/2 target - somebody
> experimented with that in the past, but he didn't manage to bring it to
> useable state.
> 
> 2) Function for accessing ports requires special segment in the resulting
> executable. Support for that would need to be added in internal linker,
> but both LINK386.EXE and WLINK.EXE can handle that without problems. GDB
> is another story - there's no GDB able to handle regular OS/2 executable
> format (LX - based on Intel OMF). Alternative debuggers exist (e.g. Watcom
> debugger, SDD from IBM and debugger for Virtual Pascal/2), but there's no
> support for their integration with FPC so far. Out of them, only Watcom
> debugger might be compatible with debug info format produced with FPC.

Which format does FPC use?

> 3) To avoid use of EMXWRAP.DLL, one needs to be able to call 16-bit APIs
> directly. This would need to add support for another calling convention in
> the compiler and provide some RTL helpers (again requiring special segment
> in the final executable). However, EMXWRAP.DLL isn't really an issue most
> probably (and some other alternative wrappers exist which could be used
> instead if really needed).

Thanks for clarifying all the above.

> > This is of course a concern since the debugger is one of the main
> > strengths of a good IDE.
> 
> Well, I don't think that newer gcc builds provide any other/better GDB. In
> addition, it might be possible to "port" the integration layer to a
> different debugger (or to try to implement those functions directly on top
> of the OS/2 API for debugging, possibly with the help of WDSibyl sources
> used for inspiration).

No indeed, as I understand it, gdb hasn't been updated to use
the newer gccs and the old one doesn't work with them at all.
I looked at Sibyl, which I do use, and WDSibyl as possibilities
for OS/2 but Wolfgang seems to me to be deviating from Delphi
compatibility rather than improving it, though there might be
some useful ideas there.

Has there been any discussion/attempt to get away from GDB and
integrate a native FPC solution? Using an external debugger
doesn't seem ideal to me.

> Feel free to contact me directly if you are interested to discuss it in
> more detail and possibly get involved in extending/improving the existing
> OS/2 support.

Thanks. It's been a long holiday weekend here and I'm back to
work tomorrow so I want to spend today assessing Lazarus on Linux.
After that, next weekend, I should be a bit more informed and will
be in a better position to try to decide what's possible and the
way forward. Whichever, I'll get back to you.

Thanks again,

Dave