./configure --prefix=/tmp/loc2 make make install strace -fFeunlink /tmp/loc2/bin/gdb Output: unlink("/tmp/loc2/share/gdb/python/gdb/command/__init__.pyc") = 0 unlink("/tmp/loc2/share/gdb/python/gdb/command/explore.pyc") = 0 unlink("/tmp/loc2/share/gdb/python/gdb/command/prompt.pyc") = 0 unlink("/tmp/loc2/share/gdb/python/gdb/prompt.pyc") = 0 unlink("/tmp/loc2/share/gdb/python/gdb/command/pretty_printers.pyc") = 0 Starting or running gdb shall never unlink files in the fs subtree where software is installed. gdb at least of version 7.3.1 performs some additional unlinks in the part of the filesystem where the compiler is installed when the "run" command is issued: unlink </.../gcc-4.6.4/lib64/../share/gcc-4.6.4/python/libstdcxx/__init__.pyc> unlink </.../gcc-4.6.4/lib64/../share/gcc-4.6.4/python/libstdcxx/v6/__init__.pyc> unlink </.../gcc-4.6.4/lib64/../share/gcc-4.6.4/python/libstdcxx/v6/printers.pyc> which cannot be straced but be intercepted with a preloaded shared object. All this can be circumvented by using "--with-python=no" as configuration parameter.
These unlinks come from libpython, not gdb. They are part of Python's byte-compilation approach. I don't think there is anything we can do about them. So, I'm closing this.
(In reply to Tom Tromey from comment #1) > These unlinks come from libpython, not gdb. libpython is compiled/linked into gdb therefore these unlinks come from gdb. > They are part of Python's byte-compilation approach. And who has "bought" that? > I don't think there is anything we can do about them. You can to lots of different things only limited by your imagination: 1. You may warn the user who compiles gdb or the end user about this side effects. 2. You can make --with-python=no the default. 3. You can remove the python support. > So, I'm closing this. Can you tell me a side effect in libpython which would be strong enough to motivate you not to close this bug?
My point is that this is a generic problem with Python. If a fix must be made, it must be made there. I don't think any of your proposed solutions are realistic. Please don't reopen this bug.
(In reply to Tom Tromey from comment #3) > My point is that this is a generic problem with Python. I doubt that python considers its own documented behavior [1] as problem. The problem stems from the integration of python into gdb. > I don't think any of your proposed solutions are realistic. This fixes the issue: gdb/python/python.c: 1230 setenv ("PYTHONDONTWRITEBYTECODE", "1", 1); 1231 Py_Initialize (); 1232 PyEval_InitThreads (); [1] http://docs.python.org/2/tutorial/modules.html#compiled-python-files
>> setenv ("PYTHONDONTWRITEBYTECODE", "1", 1); Why should gdb in particular do this? I think most things linked against libpython do not.
(In reply to Tom Tromey from comment #5) > >> setenv ("PYTHONDONTWRITEBYTECODE", "1", 1); > > Why should gdb in particular do this? In order to switch off the undesired side effect which may even be a security issue (i.e. symlink attack, have not checked this yet). > I think most things linked against libpython do not. I think most of the things linked against libpython are not debuggers run by root.