To start the current lazarus trunk, I had to delete ~/.fppkg, as otherwise lazarus crashed after trying to execute a compiler that didn't exist. Traceback is:

[FORMS.PP] ExceptionOccurred
  Sender=EProcess
  Exception=Executable not found:
"/home/me/fpc-3.0.2-64/lib/fpc/../../bin/fpc"
  Stack trace:
  $0000000000754320  EXECUTE,  line 345 of fcl-process/src/unix/process.inc   $0000000000FB39B8  GETCOMPILERINFO,  line 370 of fppkg/src/pkgglobals.pp   $0000000000FB863B  CHECKCOMPILERVALUES,  line 1084 of fppkg/src/pkgoptions.pp
  $0000000000FABECF  INSTANCE,  line 90 of ../packager/fppkghelper.pas   $0000000000AAA134  OPENDEPENDENCY,  line 5840 of ../packager/packagesystem.pas
  $0000000000A965C7  ADDPACKAGE,  line 2122 of
../packager/packagesystem.pas
  $0000000000A91C0E  OPENDEPENDENCYWITHPACKAGELINK,  line 998 of ../packager/packagesystem.pas
  $0000000000AA9C30  OPENDEPENDENCY,  line 5787 of ../packager/packagesystem.pas
  $0000000000AAAEBB  OPENINSTALLEDDEPENDENCY,  line 5997 of ../packager/packagesystem.pas
  $0000000000A96D4E  LOADLAZARUSBASEPACKAGE,  line 2213 of ../packager/packagesystem.pas
  $0000000000A96BBF  LOADSTATICBASEPACKAGES,  line 2217 of ../packager/packagesystem.pas
  $0000000000AB6A56  LOADINSTALLEDPACKAGES,  line 3086 of ../packager/pkgmanager.pas
  $00000000004A9203  CREATE,  line 1590 of main.pp   $000000000041F256  main,  line 140 of lazarus.pp

I am not aware of using .fppkg specifically, and the file ~/.fppkg/config/default did indeed reference a invalid compiler (a test version I had installed at some point). I suspect a test for the compiler file existing needs adding somewhere.

Colin

On Wed, Jan 2, 2019 at 12:46 PM C Western via lazarus <

The same problem here. In my case, 'Executable not found: "/home/silvioprog/fpc-3.0.4/lib/fpc/../../bin/fpc"'.

silvioprog wrote

The same problem here. In my case, 'Executable not found: "/home/silvioprog/fpc-3.0.4/lib/fpc/../../bin/fpc"'.

Today I saw the "Could not find a fpc executable in the PATH" error when starting Lazarus. It came in in r59934, the preceding revision, r59933, is still working correctly. Maybe a different issue, because for me, it happens only with FPC trunk.

See also:
http://forum.lazarus-ide.org/index.php/topic,43764.msg306795.html or https://bugs.freepascal.org/view.php?id=34792

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190102/4bfc8399/attachment-0001.html>

On Wed, Jan 2, 2019 at 2:25 PM Werner Pamler via lazarus <

After a new update (Wed Jan 2 14:28:53 -03 2019) from trunk the IDE raises "Lazarus instance is running but not responding" and need a kill to close.

Op 02-01-19 om 16:46 schreef C Western via lazarus:

Thanks for the stacktrace, even with debug-info for fppkg! These tests 'in the wild' help me a lot.

Should be fixed. In FPC (added the check if the compiler exists) and in Lazarus (do not choke on it when an exception occurs)

Can you re-test?

Regards,

Joost.

Joost van der Sluis wrote

Should be fixed. In FPC (added the check if the compiler exists) and in Lazarus (do not choke on it when an exception occurs)

This may be a stupid question, but why do I now have to click through a message "An error occured during the initialization of Fppkg: Could not find a fpc executable in the PATH.
Check your Fppkg configuration and restart Lazarus to be able to use Fppkg's functionality." ever time I start Lazarus?

I'm not aware of ever installing/enabling/whatever-one-does any sort of package manager, neither fppkg nor OPM...

Op 03-01-19 om 03:23 schreef Martok via lazarus:

The same holds if you remove gdb, make or the source-files of fpc's packages. While in principle Lazarus could be used without those.

There are a lot of features in Lazarus and almost no-one will ever use all of them. But they have to be configured properly so that when someone wants to use this particular feature, he or she does not drown in a swamp of vague problems.

Like with the other configuration problems that pop-up frequently, this functionality should be checked during startup with a pop-up to fix it. That's all work in progress. (Install the fppkg-package, and you can see how it could be done)

I'm not aware of ever installing/enabling/whatever-one-does any sort of package manager, neither fppkg nor OPM...

That's because it's build-in into fpc. You can not compile fpc without using at least fpmake (not entirely true, but it's the default). So you've never configured it yourself, this is done for you. Question is where it did go wrong. You probably altered the configuration yourself, and thought that you did that properly, because no-one ever noticed you that there was a mistake somewhere. Lazarus now notifies you about the mistake.

Then the question remains: why should Lazarus warn you when you do not use the functionality? Well, see above.

Ok, and one more answer to a question that you did not pose: the new changes in Lazarus make it possible to integrate the build-system (fpmake) that Free Pascal uses into Lazarus. This opens a lot of oppurtunities, like compiling LCL-based applications on the command-line or other IDE's. Or even IDE-less environments like with Studio Code. Other ways to do dependency-checking (this is what Lazarus is currently having troubles with, checking the dependencies on Free Pascal packages, which was not done previously) and improved compilation times.

It's just some new functionality, needs some time to mature.

Regards,

Joost.

That seems to have fixed the issue - restoring the config file with the invalid compiler present no longer causes an issue. (This is updating to both trunk fpc and lazarus).

Colin

I don't see this message (either before or after the update)?

Colin

But this is handled in one dialog. And the dialog searches in all common places and checks for common mistakes.

[...] Then the question remains: why should Lazarus warn you when you do not use the functionality? Well, see above.

If if it something I don't need then I would expect that it asks only once and it can be disabled/uninstalled.

[...] like compiling LCL-based applications on the command-line

That's not new.
It's new that you can use fpmake instead of lazbuild.

[...] and improved compilation times.

Please elaborate.

Mattias

Op 03-01-19 om 11:37 schreef Mattias Gaertner via lazarus:

Yes, that's what I meant. It has to be added there. But ideally I want to have it added by a package. But this is not possible at the moment. But on the other side: even without the fppkg package you can get into these troubles, so maybe just add this check within the IDE itself.

When I remove fpc's sources, it will ask me again and again and again... See the response above.

When the problem is fixed, you won't see it anymore.

> [...] like compiling LCL-based applications on the command-line That's not new. It's new that you can use fpmake instead of lazbuild.

[joost at fed4k laztestpackage]$ ppcx64 project1.lpr Free Pascal Compiler version 3.3.1 [2018/12/29] for x86_64 Copyright (c) 1993-2018 by Florian Klaempfl and others Target OS: Linux for x86-64
Compiling project1.lpr
Compiling unit1.pas
Compiling resource project1.or
Linking project1
project1.lpr(21,1) Warning: "crtbegin.o" not found, this will probably cause a linking failure
project1.lpr(21,1) Warning: "crtend.o" not found, this will probably cause a linking failure
48 lines compiled, 3.2 sec
2 warning(s) issued
[joost at fed4k laztestpackage]$

And yes, project1 in this case is the default project1 Lazarus comes up with, with one simple form.

But, yes. I had to adapt fpc.cfg to tell it which widgetset it has to use: -Fu~/.fppkg/lib/fpc/$fpcversion/units/$FPCTARGET/*/gtk2

> [...] and improved compilation times. Please elaborate.

This one needs more work and proof. In principle fpmake does almost the same as lazbuild. We have to experiment if it's any better in using multiple threads to compile packages.

But in principle fpmake should be better in detecting which packages it should re-compile.

And it passes less search-paths to the compiler, a thing of which Florian always ways it helps compilation times a lot.

But it's debatable, yes.

Regards,

Joost.

There was no project yet that didn't need the fpc sources. With pas2js this has changed. So this needs an ignore button now.

Are there any plans to make fppkg a requirement for all fpc projects?

You cheater! ;)

Mattias

Op 03-01-19 om 14:35 schreef Mattias Gaertner via lazarus:

No, not at all.

Yeah, but now I think of it....

At first I tried to keep the directory-structure similar to Lazarus' file-structure. But I decided to let this go and use just what's the easiest... Nothing forbids me to place the units of the default packagevariant (widgetset in this case) in the root.... Then I don't need this trick anymore.

Regards,

Joost.

Joost van der Sluis wrote

The same holds if you remove gdb, make or the source-files of fpc's packages. While in principle Lazarus could be used without those.

Okay, now I feel even more confused than before...

I didn't remove anything?

I build clean Lazarus (not even bigide) + FPC from trunk using fpclazup, start it, and now receive a warning that wasn't there on last week's build. What steps do I need to take to fix this? I will most definitely *not* put fpc in my %PATH%, which the dialog wants me to do. Can't it just use the $(CompPath) macro?

Question is where it did go wrong. You probably altered the configuration yourself, and thought that you did that properly, because no-one ever noticed you that there was a mistake somewhere. Lazarus now notifies you about the mistake.

Nope. Even tested with a new clean Lazarus profile dir (so there is absolutely nothing left from previous versions), same result.

Also, you write about fpmake but the problem is fppkg?

like compiling LCL-based applications on the command-line

lazbuild?

Seriously confused regards,
Martok

Op 03-01-19 om 21:17 schreef Martok via lazarus:

You could add it to the path, start Lazarus once, and then remove it again. Will that do?

On unices (Linux/Darwin) you can use the 'samplecfg' script to create a new configuration. (It wil also create a new fpc.cfg, so if you modified that one, be carefull. Samplecfg will create a backup, though.)

I actually don't know how to create the configuration files on Windows. (Except from letting Lazarus create them automatically based on the path, as described above. Or create them manually, or use fpcmkcfg... well... damn..)

There is another option: install the Lazarus fppkgpackagemanager package. Then select from the menu 'package' -> 'extra packages' -> 'Show Fppkg Package Manager'. It will present a dialog to create the right configuration files.

Or, maybe, just wait for a better solution.

Regards,

Joost

Joost van der Sluis wrote

I actually don't know how to create the configuration files on Windows. (Except from letting Lazarus create them automatically based on the path, as described above. Or create them manually, or use fpcmkcfg... well... damn..)

Calling fpcmkcfg for all provided compilers is part of the procedure for my snapshots anyway - if there is a way to generate one for fppkg as well, I'll be happy to include that.

Or, maybe, just wait for a better solution.

Will do.
Non-actionable messages are just always bugging me ;-)

Joost van der Sluis wrote

I actually don't know how to create the configuration files on Windows.

So, I checked the source, and it seems you actually do ;-) The Lazarus side generates a config if none is found (in a weird place, but that is just GetAppConfigFile being what it is). The problem is in fppkg on the the compiler side. My preferred fix would be also checking the fppkg exe path, because that's where "make install" puts it on windows, i.e.:

packages\fppkg\src\pkgoptions.pp:1119:
    FCompiler:=ExeSearch('fpc'+ExeExt,ExtractFilePath(ParamStr(0)) +
PathSeparator + GetEnvironmentVariable('PATH'));

The shared config file is still wrong if more than one full platform is installed (not usually done on unices, but that's how the Lazarus Windows installer sets things up -- see also --primary-config-path), but that's a different issue.

Op 06-01-19 om 17:29 schreef Martok via lazarus:

Am 03.01.2019 um 22:27 schrieb Joost van der Sluis via lazarus: > I actually don't know how to create the configuration files on Windows. So, I checked the source, and it seems you actually do ;-)

Oh, I do know how to do it in code... (b.t.w. if you really want to know how to do it, 'fpcmkcfg -3' and 'fpcmkcfg -4' could help.

The Lazarus side generates a config if none is found (in a weird place, but that is just GetAppConfigFile being what it is). The problem is in fppkg on the the compiler side. My preferred fix would be also checking the fppkg exe path, because that's where "make install" puts it on windows, i.e.:

That's more a coincidence. Because all executables are installed into the same location.

packages\fppkg\src\pkgoptions.pp:1119: FCompiler:=ExeSearch('fpc'+ExeExt,ExtractFilePath(ParamStr(0)) + PathSeparator + GetEnvironmentVariable('PATH'));

That won't work here, because pkgoptions is part of the fppkg-library. In this particular case it will retrieve the path of the Lazarus-executable.

The shared config file is still wrong if more than one full platform is installed (not usually done on unices, but that's how the Lazarus Windows installer sets things up -- see also --primary-config-path), but that's a different issue.

That sounds strange, it should use the normal configuration that is used by fpc to allow cross-platform setups? But I'm not sure exactly how the configuration files look like if they are generated this way on Windows.

Regards,

Joost.

Joost van der Sluis wrote

That's more a coincidence. Because all executables are installed into the same location.

For some values of "coincidence"...

On Windows, fpc lives in the Lazarus dir:
Lazarus\fpc\$FPCVer\bin\$HostCPU-$HostOS\
- fpc.exe
- fpmkcfg.exe
- fppkg.exe
- ppc whose $TargetCPU-$TargetOS is $HostCPU-$HostOS
- possibly crosscompilers and their binutils
Lazarus\fpc\$FPCVer\units\$TargetCPU-$TargetOS\
- .o and .ppu for any possible target

One may have other host compilers, although the only useful combination is using native win64 and native win32 compilers in parallel. Both will have their own non-cross-binutils etc. Both paths will have their own fpc.exe -- it's basically having done "make install" with different prefixes.

That won't work here, because pkgoptions is part of the fppkg-library. In this particular case it will retrieve the path of the Lazarus-executable.

Huh? Then can't it just get the Lazarus configured compiler path? I thought that part was in the fppkg binary.

That sounds strange, it should use the normal configuration that is used by fpc to allow cross-platform setups? But I'm not sure exactly how the configuration files look like if they are generated this way on Windows.

Ah, sorry, I was unclear.
If it worked, fppkg would put its configuration in %appdata%\FreePascal\fppkg\, whereas Lazarus would be in %appdata%\lazarus\. On Windows, the FPC installation "belongs to" the Lazarus installation and will be removed/replaced on updates. There may also be more than one of these. I would expect Lazarus to tell fppkg what paths to use when it needs it to rebuild something, because only the running Lazarus instance can know what setup it was told to work with.

Joost van der Sluis wrote

Should be fixed. In FPC (added the check if the compiler exists) and in Lazarus (do not choke on it when an exception occurs)

I just found out something else -- the exception also breaks Lazbuild, which, since it doesn't have a GUI, can't do anything about it (by the way - the IDEMessageDialog title is using the wrong string constant).

Lazbuild doesn't even have theoretical facilities to be a fppkg frontend (that is, install the ide package), so that makes no 's completely unneeded for building - fpc finds its own fpc.cfg, therefore it would find the units to use.

Oh, and unrelated: "fppkg list" just prints an error 404. Wherever that comes from.

Op 09-01-19 om 18:27 schreef Martok via lazarus:

Lazbuild doesn't even have theoretical facilities to be a fppkg frontend (that is, install the ide package), so that makes no 's completely unneeded for building - fpc finds its own fpc.cfg, therefore it would find the units to use.

Also LazBuild has the ability to use fppkg. It is not different then compiling from within Lazarus.

Regards,

Joost.