[fpc-pascal] fpc in symlinked directory

[Michael Van Canneyt]

On Wed, 26 Mar 2014, Mattias Gaertner wrote:

> On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
> Michael Van Canneyt <michael at freepascal.org> wrote:
>
>> [...]
>>> AFAIK the PWD is the official thing and used by other console tools as
>>> well. For example when I compile a file with gcc in a symlinked
>>> directory it creates debugging info with the unresolved file name.
>>
>>
>> This is not correct.
>> You seem to think bash-specific behaviour is the correct way to do things.
>> It is not, it is specific to bash.
>>
>> I use tcsh:
>>
>> cadwal: >cd /tmp
>> cadwal: >ls -ld src1 link
>> lrwxrwxrwx 1 michael michael    4 Mar 26 11:09 link -> src1/
>> drwxrwxr-x 2 michael michael 4096 Mar 26 11:12 src1/
>> cadwal: >cd link
>> cadwal: >pwd
>> /tmp/src1
>>
>> As you see, it has "resolved" the link.
>
> 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.

> tcsh uses -P as default, while bash uses -L as default:
>
> pwd -L
> /tmp/link
>
> And using gcc in tcsh uses /tmp/link for debugging info as well.

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.

>

cadwal: >objdump -g a.o

a.o:     file format elf64-x86-64

>
>> [...]
>>>>> 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 ?

> 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.

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.

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.

Michael.