Hello,

I'd like to announce that the third (and
hopefully last) release candidate for FPC 2.0.4
is available for download for most platforms
(i386-linux, x86_64-linux, i386-win32, powerpc-
macosx, i386-go32v2, arm-linux and powerpc-
linux). You can download it from
ftp://ftp.freepascal.org/pub/fpc/beta/2.0.4-rc3/.
i386-freebsd should be hopefully added in the
following days. Please, let us know of any
potential showstoppers before the next weekend
(Saturday, August 20).

Tomas

Hello,

I'm new to this list and my interests are in Lazarus under OS/2 and Linux and therefore by inference fpc.

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

Cheers,
Dave

You must compile with debug information included for gdb to work, you should set this option explicitly.

Michael.

Most of the lazarus snapshots are built with fpc 2.0.4-rc3 too.

For download locations of those test builds, see
http://wiki.lazarus.freepascal.org/index.php/Lazarus_Snapshots_Downloads

Vincent

Hi,

Thanks, I downloaded the source for 0.9.16 on Saturday and I would like to try a prebuilt binary under Linux but I haven't been able to reach the site since.
The ftp site times out and www.lazarus.freepascal.org returns 'Session initialisation failed'. This is with Seamonkey under both OS/2 and Linux.

Ah, the mirrors on the Wiki work. Downloading now thanks.

Cheers,
Dave

Thanks, I'll try that later.

Cheers,
Dave

Dave Parsons wrote

On Sun, 13 Aug 2006 23:08:29 +0200, Tomas Hajny wrote:

Hello Dave,

Lazarus under OS/2? Well, this would still take some time, I guess... Are you planning to work on OS/2 support in Lazarus, or just interested to see it?

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

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.

Tomas

On Mon, 14 Aug 2006 13:15:51 +0200 (CEST), Tomas Hajny wrote:

Hello Tomas,

My primary interest I guess is a replacement for Kylix under Linux but I would also like to be able to use Lazarus under OS/2 and OpenVMS, so first of all I want to find out how far the project has come on these three platforms. Especially important is whether Lazarus can compile an existing program which I now maintain using Delphi 2005 on MSW and Kylix on Linux. It currently uses Indy9 for networking in a large LAN with Solaris and OpenVMS end users.
This is a mature program, started 13 years ago in Turbo Pascal, in daily use by others and continually evolving to meet new requirements.

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?

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?

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.

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

Cheers,
Dave

OpenVMS runs on Alpha or Itaniums and we don't have a code generator for those.

Also OpenVMS is very strange wrt file and disk handling. That makes a port not easy.

To bootstrap FPC you need FPC :-) And you need GNU (cross)binutils for the target platform (or code an internal assembler and linker).

Peter Vreman wrote

And you need GNU (cross)binutils for the target platform

Or you can compile to assembler code, copy all assembler files and the linker script to the target machine and assemble/link there (which is what I always do).

Jonas

Well, it should be possible then but are you really saying that the original FPC was all written in assembler?

Dave

That's 1.x times technology :)

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:

.
.

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.

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

GCC isn't 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).

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

But very fast and much less work than even just downloading and installing cross binutils (let alone compiling them). That's the case for me at least...

Jonas

Well, if you do it only once yes ;)

I also do it like Jonas usually. If only because generally I've to do several alter-link-run cycli when creating prt0.as, and then it would spare me a bunch of copy-binary-to-target operations.

Dave Parsons wrote

Well, it should be possible then but are you really saying that the original FPC was all written in assembler?

No, the original FPC was written in Turbo Pascal (i.e., for Dos/16 bit). From there the cross compilation to Dos/32 bit assembler, OS/2, Linux and later other platforms started. By now, FPC is only compilable by itself.

Jonas

No, but FPC can generate assembler code from Pascal sources, and assembling and linking to final executable may be performed with standalone external tools (e.g. GNU) on a different machine/under different OS (using native assembler and linker for that platform).

Tomas

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

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;-(

Which format does FPC use?

Thanks for clarifying all the above.

No indeed, as I understand it, gdb hasn't been updated to use the newer gccs and the old one doesn't work with 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

Tomas Hajny wrote

Dave Parsons wrote:

...

That might be a possibility for OS/2 (where it isn't needed anyway) and any other x86 OS but I doubt it would be practical for VMS, but see my reply to Jonas.

Dave

Op Tue, 15 Aug 2006, schreef Dave Parsons:

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.

We made the conclusion that we need our own debugger already a few years ago. But making the conclusion and actually writing a debugger for many platforms is a different thing :)

Daniël

Hmm, to the list this time.

Ah good, that makes more sense and gives me a bit more hope.

FPC on OS/2 is no problem since we already have an up-to-date native version of FPC. Lazarus will require work.

VMS Pascal is a bit different from Turbo Pascal but it might be possible even if I have to find an early FPC, bootstrap that using VMS Pascal and then use that to build a modern FPC. After that I don't think it would be too difficult to get Lazarus to work since I already have Glade working fine with Gtk-1.2.10.

Having done some more digging around, I already have v1.0.10 which is still available and also a version which contains instructions for building FPC using BP (and others) dating from 1999, but I can't remember where I got that one from. It appears to be v0.99 but not complete.
Do you know if the older versions are archived anywhere?

I don't know yet whether it will be worth the effort, but it looks as though it could be done if necessary.

My first priority though is to assess the current versions of FPC and Lazarus on Linux and see if they meet our needs. My minimum requirement is a version of Lazarus on Linux, Solaris (sparc) or OpenVMS.
The porting to other platforms is a nice-to-have and would follow later if Lazarus is mature enough now.

Cheers,
Dave

I don't know yet whether it will be worth the effort, but it looks as though it could be done if necessary.

It isn't. I never saw the TP compilability of later 1.0.x versions confirmed, and even before 1.0 times, special care need to be taken (due to TP's memory restraints).

But more importantly, also for a bootstrapping process you need the binutils. And if you have that, crosscompiling is way, way easier.

The point about VMS isn't the cross compilation but the support in the current compiler and rtl.

This would not help, even if VMS Pascal could compile those old FPC sources into a working compiler. The reason is that for this resulting FPC compiler to generate any code which is usable on OpenVMS, this FPC must contain an Alpha code generator. By compiling FPC for the Alpha with a third party compiler, FPC itself does not automagically acquire an Alpha code generator.

As Florian mentions, the bootstrapping/cross-compiling is not a problem, but the necessary support in the compiler and RTL for OpenVMS and the Alpha architecture is. Once that support is added, it's trivial to cross-compile.

There are some very basic Alpha support routines in the FPC compiler sources, but by far not enough to even compile the compiler for Alpha (let alone to generate working code). There is also no OpenVMS RTL, although if you base it on libc it should be fairly easy to add one.

Solaris/sparc will be a lot easier than OpenVMS/Alpha, since 2.1.1 already contains support for Solaris/Sparc. It's not as well debugged as x86 or ppc (most remaining bugs are due to the strict alignment requirements of the Sparc), but it's already in fairly good shape.

Jonas

More importantly, it wouldn't help anyway. First of all, you need a code generator for the particular CPU plus RTL for the particular platform. Both are needed regardless of performing the real compilation natively on that platform or by cross-compilation (i.e. creating code for one platform on another platform, whatever the procedure would look like regarding binutils). As already pointed out by Peter, FPC currently has code generator for neither Alpha nor Itanium CPUs, and there's no RTL for OpenVMS available either.

Tomas

The part you quoted was talking about OpenVMS, so TP is not relevant since if I chose that method I would be starting with the VMS Pascal compiler which has dialect problems it's true, but certainly not memory constraints.

Dave

.
.

STABS format is fully supported (and used for OS/2 target at the moment as the only one supported by the old GDB), but emitter of DWARF debug info is available in the compiler and used for some targets.

.
.

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.

Right. Regarding debugger, he probably doesn't support either of the two debug info formats available in FPC at the moment (new debug info format could be added too, but would probably mean more work).

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.

It isn't ideal indeed. Creating a debugger requires some time, though. You need modules for reading the individual executable formats (as used on the different platforms), modules related to CPU-specific handling plus modules related to platform specific handling. The docs are available, though, as well as sources of some other debuggers (for inspiration) - GDB, SDD386, (WD)Sibyl (written in Pascal and supporting Pascal syntax at least), etc.

Tomas

VP also I believe. Alan said we could have his sources for such purposes if we need them, and at the time debugger and OS/2 specific reasons were the most important reason to get them.

Most of this was done via chat though, so some confirmation from Alan that I can pass the src on would be nice.

Marco van de Voort wrote

Most of this was done via chat though, so some confirmation from Alan that I can pass the src on would be nice.

Not only passing them on, but to re-license them under the GPL or (modified) LGPL.

Jonas

This is imo the way to go because the Watcom debugger supports dwarf.

Jonas Maebe wrote

Not only passing them on, but to re-license them under the GPL or (modified) LGPL.

Or pretty much any other Open Source/Free Software license for that matter...

Jonas

I was thinking more for reference, and less for reuse.

The problem is that if you use source code "for reference", your source code automatically gets tainted by the original one. To be clean you would need someone to write reference documentation based on the original source code, and other people reading this documentation to write their own implementation (like Phoenix did with the original IBM Bios).

An ok from Alan to only license our "derived" source code under any open source license would be equivalent to a license to distribute his original source code under that license (since you can't define how much this derived work should differ). We could have some sort of "gentlemen's agreement" that we will only distribute our own implementation, but I'm not sure how that could be written down.

Maybe after it is written, Alan could approve to distribute whatever copyrighted material from him still present in that end result under our license of choice, but I don't know if there is a way to do it beforehand besides giving us full permission and trusting we won't abuse it (or giving us no redistribution permission and us hoping that we will get that permission at one point in the future for the derived work).

Jonas

Op Tue, 15 Aug 2006, schreef Jonas Maebe:

In that case Borland own copyrights on our RTL.

The actual situation is more nuanced. Implementing from documentation is one way you are reasonably sure to be free from copyright claims.

However, having studied foreign source code does not mean your own source code is poluted, for example article 45l of Dutch copyright law is quite a legal obstable for someone claiming copyright infringement.

The border between tainted and not tained code is not written in any law, and will be up to personal interpretation to judges.

Daniël

If some of the people who wrote the RTL looked at how Borland did things and imitated that, then yes, in principle Borland co-owns the copyright on parts of our RTL. There's however the EU Software Copyright directive which gives an exclusion in case it was for the sole purpose of achieving interoperability -- which is quite appropriate in this case.

Indeed, but I'm not sure if this exists in all copyright laws. I can't find something in the Belgian copyright law at least.

The border between tainted and not tained code is not written in any law, and will be up to personal interpretation to judges.

That is true, but better safe than sorry. At least I'm not interested in fighting any lawsuit whatsoever, nor in having to throw away tons of work because we weren't careful enough.

Jonas

VP sources aren't available (except for a small group of people who were granted the right to work on fixes and updates in the past). Alan officially rejected all requests to make VP sources publicly available (only RTL sources were published) - most probably because his own rights wouldn't allow that, or possibly because he might have been afraid of possible troubles with Borland (pure speculation here). VP would be certainly my preference (especially with regard to the compatibility level with TP/BP and thus high reuseability potential for FPC).

BTW, I obviously forgot to mention OpenWatcom as another (OS/2) debugger where the sources are available too.

Most of this was done via chat though, so some confirmation from Alan that I can pass the src on would be nice.

I explicitely asked him via e-mail in the past whether he would be willing to give us sources of the debugger part (immediately after he announced official death of VP), but I didn't receive any response... :-(

Tomas

Tomas Hajny wrote

binutils). As already pointed out by Peter, FPC currently has code generator for neither Alpha nor Itanium CPUs, and there's no RTL for

If somebody offers an usable account on a linux itanium machine, I'll continue with the ia64 code generator.

Op Wed, 16 Aug 2006, schreef Florian Klaempfl:

Are you sure about that? In that case I'll try to arrange something using our company

Yes, iA64 will be a real stress test for our code generator design :)

In that case I'll try to arrange something using our company contacts at Intel.