Thanks for the detailed feedback Tomas,
I ran the command 'pacman -Syuu' again, just to be sure, and this time
it
says "there is nothing to do."
It appears that gdb is working. I was spooked by the diagnostics that you
say is a known (not serious) issue.
My mistake was not setting a breakpoint on main, so I confused problems
with gdb with problems with the program I'm trying to debug!
Incidentally, my remark about mingw-w64 problems in other communities
alluded to the Haskell development
community, where an ABI incompatibility was discovered about a year ago. It
is discussed by Ben Gamari here
https://gitlab.haskell.org/ghc/ghc/-/issues/19945.
Dominick
On Wed, Jan 18, 2023 at 12:56 PM Tomas Kalibera <tomas.kalibera at
gmail.com>
wrote:
> On 1/18/23 17:39, Dominick Samperi wrote:
>
> Thanks,
>
> But this didn't work. It installs msys2 along with lots of other stuff,
> and gdb would not start as before (missing DLL's).
>
> Then I tried to run the command you suggested again, and there was a
> warning from the package manager about a cycle detected, but now gdb starts
> with the following messages...
>
> Well, so it did work in the end. You didn't share what was the output
from
> the command the first and second time around. Actually you have even
> deleted the command from the thread, so now nobody can see it (it was
> "pacman -Syuu").
>
> In principle, sometimes one has to re-run the update the second time when
> the runtime needs to be updated, and the output says that in that case.
> This is because you are updating Msys2 from Msys2 itself. These things are
> harder on Windows due to file locking, hence the need for re-running this.
>
> What happened is probably (but again, I have to be guessing as you
didn't
> show the context) that you have installed gdb to an outdated Msys2
> installation, getting a new version of gdb depending on some new runtime
> shared libraries. By updating Msys2, you got the new shared libraries gdb
> needed and you could run it.
>
>
> Traceback (most recent call last):
> File "<string>", ine 3, in <module>
> ModuleNotFoundError: No module named 'libstdcxx'
> /etc/gdbinit:5: Error in sourced command file:
> Error while executing Python code.
>
> It is safe and best to ignore this. It is a bug in Msys2 which has been
> reported.
> https://github.com/msys2/MSYS2-packages/issues/2923
>
> Please also note it is documented in
> https://cran.r-project.org/bin/windows/base/howto-R-4.2.html
> (see Additional debugging hints)
>
>
> There is also a line...
>
> This GDB was configured as "x86_64_pc-msys".
>
> (Shouldn't that be msys2?)
>
> No. Msys2 is the name for the whole project. "msys" is the name
of one of
> subsystem, one which uses the msys (cygwin) runtime. It is not necessary to
> understand these details for using Msys2/Rtools42, but if you are still
> interested to know more, please refer to Msys2 documentation.
>
> If I ignore the messages and try to debug a terminal application, there
> are messages
> stating that multiple threads are started, and the application accepts no
> keyboard
> input, and ultimately must be terminated by closing the window.
>
> Please really you need to show more context to get help. I am using this
> every day and it works for me, as well as for other people. Also, please
> read the documentation especially if you are running into problems:
>
> https://cran.r-project.org/bin/windows/base/howto-R-4.2.html
> https://cran.r-project.org/bin/windows/base/howto-R-devel.html
>
> Problems with keyboard input are probably related to which terminal you
> are using. In some terminals, you would have to use winpty (run gdb with
> winpty) for line editing to work. Please see "Additional debugging
hints"
> in the documentation.
>
> In a clean, updated install of Rtools42, with gdb installed as documented,
> no additional tweaks are needed to run gdb from the "Rtools42
bash" (mintty
> terminal running bash from Msys2).
>
> It appears there are other development communities negatively impacted by
> the fork to mingw-w64. This did not go smoothly.
>
> I don't understand what you mean. As far as I know, R has been using
> MinGW-W64 (and before that MinGW) from the beginning, certainly it has been
> using MinGW-W64 for many years now. The official builds never used MSVC,
> there was no switching to MinGW/MinGW-W64 in the case of R afair, at least
> not in the recent past.
>
> But, in either case, the choice of MinGW-W64 is orthogonal to the choice
> of Msys2 as the provider of the build tools. Rtools42/43 come also in a
> compiler toolchain+libraries bundle, without Msys2, which in theory you
> could use with a different set of build tools. But you would be on your own
> to figure out the details.
>
>
> Perhaps it would be safer to simply provide a version of Rtools42 that
> comes with
> gdb and msys2?
>
> Rtools42 comes with Msys2. gdb is not installed there by default, because
> most people don't need it, but it is documented how to install it.
I've now
> updated the documentation to always remind to update the system before
> installing any Msys2 packages.
>
> Tomas
>
>
> Dominick
>
>
>
>
> On Wed, Jan 18, 2023 at 2:40 AM Tomas Kalibera <tomas.kalibera at
gmail.com>
> wrote:
>
>>
>> On 1/18/23 04:33, Dominick Samperi wrote:
>> > Hello,
>> >
>> > I tried installing gdb into Rtools42 following the instructions
here
>> > https://cran.r-project.org/bin/windows/base/howto-R-4.2.html
>> >
>> > I ran 'pacman -Sy gdb', and the installation seemed to
complete without
>> > problems.
>> >
>> > But gdb could not be started because incorrect DLL versions were
>> installed,
>> > in particular, the missing DLL's are: msys-ffi-8.dll and
>> > msys-unistring-5.dll.
>>
>> Try upgrading Msys2 using
>>
>> pacman -Syuu
>>
>> Tomas
>>
>> > Is there an alternative way to install gdb for use with Rtool42?
>> >
>> > Thanks,
>> > Dominick
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > ______________________________________________
>> > R-devel at r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
[[alternative HTML version deleted]]