[fpc-pascal] fpc in symlinked directory

[Michael Van Canneyt]

On Wed, 26 Mar 2014, Jonas Maebe wrote:

> On 26/03/14 17:23, Michael Van Canneyt wrote:
>> At the very least I think that we should be consistent and use the same
>> filenames in link script and debug info ?
>
> How directories are stored in the debug info is generally defined by the 
> debug info format itself. E.g. the DWARF standard explicitly mentions that 
> search directories for source files can be either relative or absolute to the 
> current working directory (there's even an attribute to specify a default 
> CWD, so that the files can be easily found on the compilation system itself 
> even when the program is started from another location). Specifying the 
> directories in a relative way means that you can easily copy over a debug 
> binary and all related source code from one system to another (or move things 
> around) without breaking anything. For that reason, we explicitly add 
> relative directory names to the DWARF debug info rather than absolute ones.

As I wrote to Tomas:
This assumes that the directory structure on the other system is identical.

An assumption that doesn't hold between e.g. 64-bit debian and fedora.

But I am not asking to change the way things are done unconditionally,
I understand your reasoning.

> For linking, we use absolute paths in link.res to ensure that the parameters 
> given by the programmer to the compiler (such as -Fl and -XR) are taken into 
> account when linking, and that the linker doesn't accidentally link in some 
> other library with the same name that it found in its default search path.
>
> I don't see what the advantage of being "consistent" between the generation 
> of debug info and linker scripts would be. Making the paths in the debug info 
> absolute would make things less flexible without increasing usability (I've 
> never seen bug reports about problems with the wrong source files being 
> found). Making the paths in the linker script relative would add a lot of 
> complexity (the compiler first searches for the library files on the files 
> system, and then it would have to make the paths relative to the CWD for no 
> gain) and special cases (when linking on a remote system, the compiler has no 
> clue about what the relative position of e.g. /usr/lib will be compared to 
> the CWD, so then you would still have to use absolute paths).

The problem is easy to reproduce, as Mattias demonstrated.

During debugging, Lazarus consistently opens a file twice (or doesn't find it at all) 
when symlinks are used in the path to the project file, because there is a mismatch
between the relative path as lazarus sees it (logical), and the relative path as FPC 
sees it (physical), and lazarus uses the debug info to open the file.

That's what started this whole thread.

Specifying source files in the debug info using full paths would solve the issue.

I'm not advocating to always do this, I understand your reasoning for having the current behaviour.

I'm advocating to make this behaviour configurable:

Most people do not copy the files to another system to debug, for them the current exercise is pointless.
I suspect much more people use symlinks, for them it would be a convenience to have everything absolute.
It would avoid problems. You have the names in absolute form available anyway (for the linker), so it should
not be a major problem to make the behaviour configurable.

The alternative is that Lazarus also resolves the directory of the project, as FPC does.
(It probably needs to resolve all other files in the process, which is a big effort, 
but that is conjecture on my part)

Michael.