[fpc-pascal] fpc in symlinked directory

[Mattias Gaertner]

On Wed, 26 Mar 2014 12:07:01 +0100 (CET)
Michael Van Canneyt <michael at freepascal.org> wrote:

> On Wed, 26 Mar 2014, Mattias Gaertner wrote:
>[...]
> > You seem to think tcsh-specific behaviour is the correct way to do
> > things. ;)
> 
> Well, actually I don't think in such terms. I think that the system is right.
> And the system (the linux kernel) has resolved the symlink to find the correct file/dir.
> which is the only correct behaviour in my opinion.

The system finds the right file by itself. That's why programs can work
on a higher level.

 
>[...]
> Maybe they cater for it. I think this is a noble, but misplaced, intention.
> If they would specify full pathnames, there would not be a problem.

What problem do they have? /tmp/link is a valid file name.

 
> cadwal: >objdump -g a.o
> 
> a.o:     file format elf64-x86-64

objdump -g a.out  | grep tmp
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x7d): /tmp/link


>[...]
> >>>>> compiler uses its current directory.
> >>>>
> >>>> What does that mean ? Can you give a command-line example ?
> >>>
> >>> I used this one:
> >>> cd /tmp/link
> >>> /usr/bin/fpc -g -gl -vb -Fi/tmp/link -Fu/tmp/link/
> >>> -FU/tmp/link/ /tmp/link/project1.lpr
> >>
> >> cadwal: >fpc -g -gl -vb -Fi/tmp/link -Fu/tmp/link -FU/tmp/link /tmp/link/p.pp
> >> /usr/bin/ld: warning: link.res contains output sections; did you forget -T?
> >>
> >> So your example works fine here.
> >
> > It compiles, but it creates wrong debugging info.
> 
> Eh ? You didn't say anything about debugging info ?

Yes, sorry. The wrong file names appear in error messages and debug
info.
Just add a syntax error to unit1.pas and compile once in /tmp/link and
once outside. You see once the physical directory and once the
logical.

 
> > What shows "objdump -g unit1.o | grep tmp" for you?
> > /tmp/link/ or /tmp/orig/?
> 
> cadwal: >objdump -g a.o
> 
> a.o:     file format elf64-x86-64
> 
> :)
> 
> Aha... 
> I suspect the "leading to wrong source file names." of your initial post is 
> referring to the source filenames in debug info.

It's both. Syntax errors and debug info.

 
> If this is the case: it is just an additional indication that Lazarus must 
> simply resolve all filenames. If it does so, then there is no problem, since FPC 
> and the OS do the same.

The problem is the following:
The user opens /tmp/link/project1.lpr in the source editor and runs
it. When there is a syntax error or when the debugger stops they report
a source file name '/tmp/orig/unit1.pas' and the user wonders why.
The IDE automatically opens the file '/tmp/orig/unit1.pas', but since
it shows in the tab only the 'unit1.pas' the user may confuse that
with the right file.
It is possible to implement some heuristic search to find the file that
was "meant". But it would be nicer if fpc would use the
logical directory, as it does for all other paths.

 
> As a consequence, It will get rid of the annoying myfile.pp(2) when opening a source 
> file during a debug session.
> 
> BTW: The Firebird database server also does this when resolving database 
> filenames. It checks the inode number. If it didn't, it would open the 
> same DB file twice, thinking they are different DBs - and corrupting them 
> in the process. So it needs to uniquely identify each file, to make sure 
> it opens each DB file only once.
> 
> Which, again, I think is the only sensible behaviour.

That's about writing to a file. I already wrote, that the source
editor does that too. Some places of the IDE does not do the check.

For instance:
One include file used in different contexts. Depending on its file
name different units use it and parse it differently. FPC reports the
logical file name on an error and so the IDE knows the right context.
The IDE opens the file two times and with different settings.


Mattias