[fpc-devel] 2.0.4-rc3 available

[Tomas Hajny]

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:
 .
 .
> I realize that OS/2 and OpenVMS are fringe operating systems so I
> expect to have to do some development of both fpc & Lazarus there
> myself, the question is really how much work i.e. time is required.
>
> 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.


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


>> > I tried to compile Lazarus with the last official fpc release,
>> > os2200 a couple of days ago, but that was too old.
>> >
>> > So, thanks for this rc which I have downloaded and built
>> > under OS/2.
>>
>> Are you talking about compilation of FPC 2.0.4-rc3 sources under OS/2?
>> OS/2 binaries of 2.0.4-rc2 were uploaded by me earlier. However, I got a
>> SIGSEGV while trying to build rc3. I already had this in the past and it
>> unfortunately largely depends on the exact environment (so e.g. it
>> cannot
>> be reproduced any more if compiling with debug information included
>> :-(((
>> ).
>
> Yes I just downloaded fpcbuild-2.0.4-rc3.tar.gz, extracted the tar
> using untgz, ( untgz failed to completely unpack it ) untarred it
> with gnu tar and ran 'make os2' using the fpc from os2200.zip which
> was the latest I could find.
> After that it installed with 'make install'. The only error I
> saw was the one about gdb.

Right - different make options resulting in correct compilation...


>> > I'm still feeling my way around so I'm not sure
>> > that everything compiled that could be expected, but the
>> > compiler and many executables are there and work.
>> > I spotted one comment about GDB as the output scrolled
>> > past that said that debugging would be unavailable.
>> > Is this normal or a fault with my set up?
>>
>> Well, I guess this refers to IDE compilation. Unfortunately, the OS/2
>> version of GDB is based on ancient 4.16 sources and nobody managed to
>> create libgdb.a which could be in turn used for including debugging
>> support in our IDE. You can still debug with standalone GDB or the PMGDB
>> add-on (both distributed with FPC too). BTW, I didn't include IDE
>> (fp.exe)
>> in RC1 and RC2 because it was crashing somewhere in the thunking code
>> inside the EMX libraries (emxwrap.dll or emx.dll) while calling
>> VioShowBuf
>> (it worked correctly in the past, so I'm not sure what exactly happened
>> there :-( ). I'd be interested to know whether your experience is
>> different.
>
> That sounds about right.
> 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.

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


> If it is have
> you had a look at the Innotek builds, currently gcc-3.3.5 csd1.
> I haven't used gdb much but I understand that the newer gccs from
> Innotek are not compatible with the gdb we currently have.
> 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).

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.

Tomas