It seems to be an error in the run time library.
I can fix this by changing AssignPipe in rtl/linux/unixsysc.inc

Function AssignPipe(var pipe_in,pipe_out:longint):boolean; [public,
alias : 'FPC_SYSC_ASSIGNPIPE'];
{
  Sets up a pair of file variables, which act as a pipe. The first one can
  be read from, the second one can be written to.
  If the operation was unsuccesful, linuxerror is set.
}
var
  pip  : tpipe;
begin
  AssignPipe := do_SysCall(SysCall_nr_pipe,longint(@pip)) = 0;
  if AssignPipe then begin
    pipe_in:=pip[1];
    pipe_out:=pip[2];
  end else
    linuxerror:=fpgeterrno;
end;

though there seems to be other problems (with text boxes?) so I have gone back to 1.0.10

Colin

I think this is a FCL error ,because it show "can not create pipe",this is FCL's AssignPipe or POpen Function.

= = = = = = = = = = = = = = = = = = = =

��
��

GongYu

2003-11-09

Avoid 1.9. ;)

I'm also interested in the solution. Is this a bug in the fcl or in the compiler?

Mattias

I can on FreeBSD, but that is a known problem.

I'm now looking into this, had experience with all this before.

Will test on Linux too.

i use kernel 2.6.0-test9-mm2 and logged as root,the problem is still there :) I use the release 1.9.0beta

GongYu

2003-11-09

got the same problem here :(

does any body uses 1.1 or 1.9 with/for lazarus?

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?

����������������������������GongYu

����������������������������������2003-11-08

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?

����������������������������GongYu

����������������������������������2003-11-08

The problem is that it seems that Peter can't reproduce it?

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.

----- Original Message -----