[lazarus] fpc1.9.0 beta and lazarus problem!

[Marco van de Voort]

> On Sun, 9 Nov 2003 19:19:56 -0800
> "GongYu" <425009 at sina.com> wrote:
> 
> > I installed the  fpc1.9.0 beta and compiled lazarus under fpc1.9.0,
> > it can sucessful build.
> > 
> > I start lazarus and create new  project,
> > but when I  run the project, the  lazarus IDE said "can not create pipe " 
> > can anyone  tell me how to avoid this error?
> 
> Avoid 1.9. ;)
> 
> I'm also interested in the solution. Is this a bug in the fcl or in the
> compiler?

IMHO lazarus/fcl/rtl it can be either one.

If I saw the experimental "fix" floating by, and Peter's difficulties 
reporducing it, I suspect the reason is the changed "errno" behaviour.


The problem is the old linuxerror (which is nothing but Linux units errno)
was cleared for every call, and the errorcode stored in it by the syscall.

This is not what C does for errno. The proper (unix/C) way is similar
to  what is done in the fix, is

- You are only allowed to check errno/linuxerror if a library call 
	returns -1 (check <0)
- errno is updated only when an error occurs. It is usually never reset to
	zero.  (only at program start)

There are both sound reasons why C does this, and why we have to follow,
(even for Kylix compability), so there is no escape. The reasons have
to do with being able to vary the granularity of errorchecking and nesting
library levels. (putting a breakpoint on errno makes a lot more sense)

The current 1.9 system calls already have this behaviour, this can clash
with certain unix unit code that assumes the old conventions.

So what could be the case is that an earlier call fails (e.g. a STAT
for ~/.fpc.cfg) and that that "polutes" errno, and while the PIPE call
fails, linuxerrno:=fperrno is still non zero. (value of the previous call)

----
This is one of the reasons the 1.1 Unix rtl was so horribly changed. Since 
the result would be somewhat incompatible anyway, and people would have to
check their code anyway, I decided to fix all unix rtl problems at once too,
resulting in a radical break.
(e.g. naming according to C rules, unix typing, and fix the mixing of 
portable and less portable and linuxisms)

linuxerror will disappear in time(read: before 2.0), but I didn't want to do
that before Lazarus is entirely over, and I'll fix that gradually, and
invisible from behind the scenes, and some unix unit functions prototypes
might also change btw.

Maybe the "oldlinux" unit could also  get improved a bit before 1.0, but
since oldlinux will not be in the 2.0 distribution for anything else then
linux/i386, I'll leave that to a more motivated person :-) (the current unix
and oldlinux unit both suffer from having to share includefiles, and in
retrospect, I think unit oldlinux can better be done by inlining all
includefiles in the 1.0.x, and moving that as unit "oldlinux" in rtl/linux)

However this is not possible at the moment because Peter wants to debug
1.9.x fully compiled by a 1.0.x system (compiler+rtl). As soon as
1.9.x/2.0.x is fully selfhosting, and Lazarus is roughly over to the 1.9.x
branch, we can start by doing these final cleanups.