Hello FPC developers.

Sad but we found a new (really very old) bug with spaces: http://bugs.freepascal.org/view.php?id=9964

If you pass -o"some file with spaces.exe" or "-osome file with spaces.exe" fpc generates only a file with only "some" part.

Why I write here. Well, lazarus team hope to have a version of fpc which can work with spaces and 2.4.2 is in the preparation steps. We already made some steps in this direction during the current lazarus and fpc releases. So maybe there is a chance (not too late) to fix this error too?

Best regards,
Paul Ishenin.

Are you sure the bug is in FPC ? I mean, as far as I know there is nothing that prevents the internal linker or option handling from having spaces in a filename. However, if the options are passed as
-osome file with spaces.exe
then FPC only sees the "some".

Michael.

In our previous episode, Paul Ishenin said:

Can you validate that the called binary really gets this parameter ?

D:\testing>fpc -o"test 1 2 3.exe" boundtest
Free Pascal Compiler version 2.5.1 [2010/07/03] for i386 Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Win32 for i386
Compiling boundtest.pp
Linking test 1 2 3.exe
14 lines compiled, 1.1 sec , 127808 bytes code, 26568 bytes data

D:\testing>dir "test 1 2 3.exe"
Volume in drive D is DATA
Volume Serial Number is D0C7-7322

Directory of D:\testing

06-07-2010 14:35 157.960 test 1 2 3.exe 1 File(s) 157.960 bytes
0 Dir(s) 78.327.300.096 bytes free

D:\testing>

(2.4.0 reacts the same)

It looks to me more a problem with TProcess argument (related to e.g. #14446)

Why I write here. Well, lazarus team hope to have a version of fpc which can work with spaces and 2.4.2 is in the preparation steps. We already made some steps in this direction during the current lazarus and fpc releases. So maybe there is a chance (not too late) to fix this error too?

Then better start finding something really soon. This morning I generated the source from rc1, so unless a fix it comes today or tomorrow, RC1 is already gone.

Michael Van Canneyt wrote

Are you sure the bug is in FPC ?

Yes, look at the quotes - they are ignored or so.

C:\WINDOWS\Temp>programming\lazarus\lcl\units\i386-win32\gtk2\ -FuC:\programming\lazarus\packager\units\i386-win32\ -Fu. -FUlib\i386-win32\ -o"My Test Project.exe" C:\WINDOWS\TEMP\project1.lpr Hint: Start of reading config file
C:\programming\fpc_2_4\bin\i386-win32\fpc.cfg
Hint: End of reading config file
C:\programming\fpc_2_4\bin\i386-win32\fpc.cfg
Warning: Only one source file supported, changing source file to compile from "Test" into "Project.exe"
Warning: Only one source file supported, changing source file to compile from "Project.exe" into "C:\WINDOWS\TEMP\project1.lpr" Free Pascal Compiler version 2.4.1 [2010/05/23] for i386 Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Win32 for i386
Compiling C:\WINDOWS\TEMP\project1.lpr
Compiling unit1.pas
unit1.pas(18,28) Hint: Parameter "Sender" not used unit1.pas(19,28) Hint: Parameter "Sender" not used Compiling resource lib\i386-win32\project1.or
Linking C:\WINDOWS\TEMP\My
67 lines compiled, 2.6 sec , 1400512 bytes code, 367432 bytes data 2 warning(s) issued
4 hint(s) issued

Best regards,
Paul Ishenin.

C:\temp\fpc>C:\programming\fpc\bin\i386-win32\fpc.exe -o"My Test Project.exe" test.pas
Warning: Only one source file supported, changing source file to compile from "Test" into "Project.exe"
Warning: Only one source file supported, changing source file to compile from "Project.exe" into "test.pas"
Free Pascal Compiler version 2.5.1 [2010/07/04] for i386 Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Win32 for i386
Compiling test.pas
Linking My
3 lines compiled, 0.1 sec , 25776 bytes code, 1576 bytes data 2 warning(s) issued

06.07.2010 20:56 <DIR> .
06.07.2010 20:56 <DIR> ..
06.07.2010 20:56 309 124 My
06.07.2010 20:56 4 039 test.o
06.07.2010 20:54 28 test.pas

We are using the different compilers or what?

Best regards,
Paul Ishenin.

See the mail from Marco for an explanation of this output.

Michael.

No, different shells is more likely to be the cause.

Michae

Michael Van Canneyt wrote

No, different shells is more likely to be the cause.

I made a small bat file:

@echo off
echo 1 %1
echo 2 %2

C:\>test -o"My Test Project.exe" C:\WINDOWS\TEMP\project1.lpr 1 -o"My Test Project.exe"
2 C:\WINDOWS\TEMP\project1.lpr

So quotes are passed right.

Best regards,
Paul Ishenin.

This is not bulletproof;
Windows cmd may do the handling for the batch interpreter.

Do not use a batch file, but a plain executable to test:

program mytest;
Var
  i : integer;
begin
   For I:=1 to ParamCount do
    Writeln(I,' : ',Paramstr(i));
end.

and test then with

mytest -o"My Test Project.exe" C:\WINDOWS\TEMP\project1.lpr

Only then we'll know who does the interpreting of the quotes.

In case it still differs, this doesn't explain why Marco's example works fine. He seems to be using the same executable. Maybe different windows versions handle it differently...

Michael.

In our previous episode, Michael Van Canneyt said:

Or better even, sysutils.commandline, since doesn't that iirc reflect what the binary gets before FPC parses it?

Yes, I tried adding paths and other parameters, no difference.

It is W7 here btw.

C:\temp\fpc>test.exe -o"My Test Project.exe" C:\WINDOWS\TEMP\project1.lpr 1 : -oMy Test Project.exe
2 : C:\WINDOWS\TEMP\project1.lpr

Best regards,
Paul Ishenin.

Michael Van Canneyt wrote

and test then with mytest -o"My Test Project.exe" C:\WINDOWS\TEMP\project1.lpr

I found the problem. The reason is old fpc.exe which probably passes arguments to ppc386.exe

As Marco has found the bug report has the same date as my old fpc.exe.

Sorry for the false alarm. It was nice to search the problem together.

Best regards,
Paul Ishenin.

Glad to hear FPC is not at fault, for once.

So we can expect a new FPC and lazarus hopefully soon :-)

Michael.

[...]

Right, the filename should be quoted.

I just found another annoying behaviour, namely that FPC cannot handle relative pathes and macros in file specifications. When I want to add an unit ../some.pas to a project or package, FPC doesn't find that file. In the uses clause the "in 'some.pas'" only accepts absolute pathes (useless) or files in the search path - no directory macros, no relative names :-(

This should not be hard to cure, but I could not yet find out where. Should I file an feature request?

DoDi

In our previous episode, Hans-Peter Diettrich said:

Does Lazarus set the working directory for the compiler as you expect it to be? Keep in mind that a relative path is always dependant on the working directory, not relative to the project.

Many people using Delphi have made the same mistake.

Michael Van Canneyt wrote

Glad to hear FPC is not at fault, for once. So we can expect a new FPC and lazarus hopefully soon :-)

I am sorry for hijacking this thread, but while I see someone is interested in proper command-line spaces handling, I would like to draw some attention to http://bugs.freepascal.org/view.php?id=14767

Maybe it could be fixed too?

Lazarus sets the working directory to the project directory when calling the compiler.
The 'in' modifier works here.

Many people using Delphi have made the same mistake.

Mattias

In our previous episode, Mattias Gaertner said:

Isolating it in a console program would be best, or, less interesting, -vt output (or -va output) could shed some light on this.

Does Lazarus set the working directory for the compiler as you expect it to be? Keep in mind that a relative path is always dependant on the working directory, not relative to the project.

I'd expect that the "working directory" is set to the directory of the project to build, or unit to compile. This may be a Lazarus problem, but dunno how to verify this.

Nonetheless path macros like $(FPCSrcDir) should be acceptable, too, instead of other (absolute) path specifiers.

DoDi

Lazarus sets the working directory to the project directory when calling the compiler.

Fine :-)

The 'in' modifier works here.

It didn't work for me with relative pathes, like

   uses myUnit in '..\myUnit.pas';

(Windows, obviously ;-)

While Lazarus could find that unit, FPC could not :-(

There might be a problem with "uses" in the project file, where "in" is allowed, and with uses of the same file in other units?

DoDi

Zitat von Hans-Peter Diettrich :

Hint: Both compiler and lazarus automatically changes the path delimiter and searches exact/lower/upper case for the file name (not path).

While Lazarus could find that unit, FPC could not :-( There might be a problem with "uses" in the project file, where "in" is allowed, and with uses of the same file in other units?

The 'in' modifier is troublesome and is always the inferior solution compared to search paths.
Lazarus searches relative to the unit, the compiler relative to its working directory. The reason is that the IDE has not a single working directory, but each project, each package and each tool have their own working directories, so units can have 0..n different working directories.
Delphi uses the 'in' modifier mostly to mark units as part of the project.

Mattias

In the concrete case the filename was all lowercase, and the Windows filesystems are case-insensitive.

Unfortunately I have to replace some files in the compiler directory, what suggests *not* to add that directory to the searchpath - otherwise I suspect that a used unit could be found in the wrong directory.

Perhaps somebody has a better solution?

Lazarus searches relative to the unit, the compiler relative to its working directory. The reason is that the IDE has not a single working directory, but each project, each package and each tool have their own working directories, so units can have 0..n different working directories.

I understand the complications in Lazarus, but not in FPC with a single (unique) working directory :-(
That's why I ask in the FPC list.

DoDi

Zitat von Hans-Peter Diettrich :

Yes, it was a hint how 'in' works platform independent.

How do you replace units with the 'in' modifier?

Perhaps somebody has a better solution?

Replacing units can be done with the search path.

Maybe start another mail thread for this?

Mattias

Replacing units can be done with the search path.

But only when the search for used units exactly follows the search path, and does not look into the directory of the using unit first. Is this guaranteed?

DoDi