Recent

Author Topic: debugger did not install  (Read 3540 times)

graemejc

  • New Member
  • *
  • Posts: 33
debugger did not install
« on: December 12, 2021, 05:57:52 am »
I downloaded lazarus-2.2.0RC1-fpc-3.2.2-win64.exe and executed it, following all instructions, including closing all other applications and accepting all defaults. On trying to use it, I get the error ...

The debugger executable typically has the name "gdb.exe". Please give the full file path. A useful setting on Windows system is:
$(LazarusDir)\mingw\bin\$(TargetCPU)-$(TargetOS)\gdb.exe

After a bit of searching, I found gdb.exe in C:\lazarus\mingw\x86_64-win64\bin and so entered C:\lazarus\mingw\x86_64-win64\bin\gdb.exe.

My question is why on earth does such a thing happen. Surely the downloadable files should be functioning properly and tested. Have others had this problem? I assume that the lazarus developers can easily fix it, but surprised that this error slipped through. Or did I make a mistake?

dbannon

  • Hero Member
  • *****
  • Posts: 2019
    • tomboy-ng, a rewrite of the classic Tomboy
Re: debugger did not install
« Reply #1 on: December 12, 2021, 06:20:40 am »
Graham, just guessing. I am not a windows user.

Firstly, Lazarus is gradually changing over from using gdb to fpdebug by default (but both will work for you). So, perhaps you are caught in the transition ?  I'd suggest that RC2 did have a number of fixes in that area so, I its probable that you would do a lot better with RC2, its been available for some time now.

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng

graemejc

  • New Member
  • *
  • Posts: 33
Re: debugger did not install
« Reply #2 on: December 12, 2021, 07:56:59 am »
Okay, thanks.

It's working now, so despite my "dirty solution" to the program, I think I'll stop spending time on it.

Do appreciate your help.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7865
  • Debugger - SynEdit - and more
    • wiki
Re: debugger did not install
« Reply #3 on: December 12, 2021, 09:36:03 am »
Of course I do a test install before shipping the installer (well, I do for the Win installers, the others are build and tested by someone else)

That worked. But, its not that simple.
My test usually is a new install, with no old config to update from.
If you update an existing installation, you already have configuration, which will be kept or upgraded.

There are a huge number of different setting that can be in place, even if you never made a change yourself.
Say, you updated from 2.0.12. Was your config originally created by 2.0.12 (i.e., was this your first instal)l? Or was it gradually upgraded from an much older version?
Usually, if config changes are introduced they are tested when they get introduced, not when the installer is tested.

So much for the background....

This time (from Laz 2.0.x or older upgrading to 2.2)  the change is indeed bigger, at least if you upgrade.
- If you make a new install, it will set up the new FpDebug for you, and you are not using gdb.
   (Actually it will also setup gdb, but not activate this config, you can then chose...)
- But if you upgrade, it will check. And keep any settings you have. (Ok, true, then an existing presumingly correct path should have existed...)

And, well yeah..., if you upgrade, it must to some guessing (some internal detail about the order in which the IDE loads different parts of the config). So there is a chance things will not go as smooth as they should...





Now, first of all: The mismatch you spotted: "mingw\bin" vs "mingw\...\...\bin".

That indeed is a bug, that did not get spotted. And that has been in there for ages. It has been like this, since the text was added in July 2012.

The location on disk "mingw/cpu/os/bin/" also exists since 2012, before that it was "mingw/bin" (so back then, you could only have one gdb, and couldn't debug a 32 bit app from a 64 bit IDE or vice versa).

So that bug is really old. Thanks for spotting. I will update those texts.

However, that is just the descriptive text. The dialog should fill a suggestion into the dropdown/edit. And in all my tests it has done the correct one....
It should be choosing from (and those can still be found under menu Tools > Options > Debugger Backend)
  $(LazarusDir)\mingw\$(TargetCPU)-$(TargetOS)\bin\gdb.exe
  $(LazarusDir)\mingw\bin\gdb.exe    // The pre 2012 location
  C:\lazarus\mingw\bin\gdb.exe         // good question how long ago that had been used....
 
Since you had to try and rely on the text (text above the dropdown), I assume the automatic fill-in also did not work for you... very strange.






I went back and re-installed an old 1.8 version (from Dec 2017) => gdb was in "C:\lazarus\mingw\x86_64-win64\bin", configured as "$(LazarusDir)\mingw\$(TargetCPU)-$(TargetOS)\bin\gdb.exe". => So as expected: the "bin" at the end.
I then updated it to 2.2RC2. And it kept that setting. It gave me no error, nor warning. (Well it asked me, if it was ok to update my config to the new version).

But that much for testing. Yet it broke for you, which it should not have done. Unfortunately I can not reproduce that.

And, since you fixed your install by setting the correct path, if you did an upgrade your old conf files would now have been overwritten, I guess? So they can't be inspected any more.

If you can still give as much detail as you have, then I can see if I can spot anything that helps explaining it.
Also include your "environmentoptions.xml" if you can.
To be found in the "primary config path". Usually: C:\Users\<YOURNAME>\AppData\Local\lazarus
But, you can check under menu: View > IDE internals > About IDE




Ok, that's been a lot of info.

One issue found: Wrong text in label.
For the rest, well lets see if we can turn up any detail to narrow it down.

 

TinyPortal © 2005-2018