On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt <mich...@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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
