I have compiled cvs from the latest CVS in SuSE linux v 9.0. When I type the command fpc i get the response
Error: /usr/local/bin/ppc386 cannot be executed

However ppc386 is present in the same directory as fpc, with the same date and time stamp and the same date and time stamp as the file in ~/FreePascal/fpc/compiler. The file marked fpc is considerably smaller than ppc386
The file ppc386 (in either location) executes perfectly correctly as the freepascal compiler, so what is the matter with my fpc command? (Incidentally, the compiler functions correctly from lazarus compiled from the most recent cvs).

I could probably live with invoking ppc486 instaed of fpc, but it is an annoyance.

We haven't figured this problem out entirely yet. On some systems it works, on some it doesn't.

The file "fpc" is a frontend binary that selects the right processor backend (ppc386), and its use is limited to compiling.

Removing fpc and symlinking fpc to ppc386 is the best for now I think.

We haven't figured this problem out entirely yet. On some systems it works, on some it doesn't.

can confirm this problem for Debian 3.0

I can further confirm that the problem exists in Fedora Core 1.

Thanks, deleting FPC and reconstructing the symlink solved the problem (for the time being).

Chris

I can further confirm that the problem exists in Fedora Core 1. Thanks, deleting FPC and reconstructing the symlink solved the problem (for the time being).

Can you explain what you did exactly. It might help us to find the problem?

OK, I just figured out what was the cause of this problem.

In SysUtils.ExecuteProcess you were wrapping ppcbin compiler filename (like '/usr/local/ppc386') inside quotes (to make it something like '"/usr/local/ppc386"') but you were not stripping those quotes anywhere before passing this to execve (i.e. FpExecVE). So it shouldn't work (since execve should not tolerate any additional quotes in filename, even if it does on some UNIXes).

Patch to rtl/unix/unixutil.pp attached with (too many?) comments, it modifies StringToPPChar behavior so that it strips those quotes.

Regards,
Michalis

While this is a solution in theory, I think this is only "hacking" a broken design.

I today commited fixes that keeps commandline and program to execute separately.

However that only solves the case for the program that is to be executed.

Arguments containing spaces will still go wrong. (Unix is very strict in this regard, arguments must be separated by the application). The best solution is to not have an interface that requires the arguments to be separated, iow, the primary function should be of the form

function execute(programtobeexecuted:ansistring);const arg : array of ansistring):cint;

This because there are several kinds of escaping spaces. Windows traditionally uses quotes, but unix uses escaping with backspaces.

However I will review your changes anyway, since at least they make sense for applications using the old interfaces.

OK, I just figured out what was the cause of this problem.

The submitted patch only strips quotes, but a new version should honour the quotes. I'll see what I can hack up :)