Forum > Lazarus

We are planning the next release: Lazarus 2.0.2

<< < (16/16)


--- Quote from: Martin_fr on April 17, 2019, 01:53:22 pm ---Could either of you test the following patch (with your original environment)?

--- End quote ---
Unfortunately, your patch did not fix the bug. I got the same error: "Fatal: Unable to open file C:UsersUserAppDataLocallazarusidemake.cfg -dx86_64".

In seems that make (the make in fpc) looks for an sh.exe (or maybe other shells). Findind one, it will use it, and that screws the build process.

No idea how to prevent it.

It may be able to force it to use cmd.exe, but that is ridiculously slow.

I made a fake sh.exe in the "c:\MinGW\msys\1.0\bin\" folder. It writes the received parameters to the file (ParamStr(0) .. ParamStr(ParamCount)). This is what he gets when rebuilding Lazarus 2.0.2.

--- Code: ---c:\MinGW\MSYS\1.0\bi\sh.exe -c C:/lazarus/fpc/3.0.4/bin/x86_64-win64/fpc.exe -gl -vbqewnhi -Sci -dlclwin32 -Fu../designer -Fu../debugger -Fu../debugger/frames -Fu../converter -Fu../packager -Fu../packager/frames -Fu../components/custom -Fuinclude/win -Fuframes -Fu. -Fiinclude -Fiinclude/win64 -Fi../images -FE.. -FU../units/x86_64-win64/win32 -WG \@C:\Users\User\AppData\Local\lazarus\idemake.cfg\ -dx86_64 lazarus.pp

--- End code ---
Version 2.0.0 does not use sh.exe at all. Any idea why version 2.0.2 uses sh.exe? And why do double quotes become backslashes?

It is something that make does. You can specify a shell to make
make target SHELL=...

But that does not help. According to my tests, if it does not find one, then it uses a build in shell (or so it seems). But I found no way to force that.

You can give it cmd.exe. But that is dead slow.

Check the makefile, there is one target that just echos all sorts of info "make". You can use that to play around.

I did not found any real solution.

One could put a shell into the fpc folder, and then use the patch to add that to the start of the PATH. Then the shell provided by lazarus would be used.
It would still be an external shell, not the builtin. And could be a problem. This is called on many different versions of windows, with all sort of different other settings..... Who knows if or what it may break.

Also some people may have fpc in their path. So ia fake shell could be disastrous. Because while it might work for the make scenario, it would break probably anything else that would use it as a shell.

In any case, I am not the expert on the whole make business. If this topic stands a chance of getting attention then probably on the mail list. So if interested, I suggest to try there, and see if anyone else from the team wants to take this on. If they believe a fake shell is not as risky as I assumed, then maybe someone is willing to go that path.

As I said, unfortunately not my area of expertise. So I am opting out. (unless make can be given an argument to force it to the internal shell)


--- Quote from: Martin_fr on April 19, 2019, 05:14:40 pm ---So I am opting out. (unless make can be given an argument to force it to the internal shell)

--- End quote ---
Anyway, thanks for your help. Removing a shell from a path is in most cases an acceptable solution. I think this solution can be advised to those who face a similar problem.
Maybe one day the cause of the problem will be found.


[0] Message Index

[*] Previous page

Go to full version