Re: cygport may not create debug info if top directory contains a symlink

[Christian Franke <Christian.Franke@t-online.de>]

Brian Inglis wrote:
> On 2023-09-18 04:41, Christian Franke via Cygwin-apps wrote:
>> Brian Inglis wrote:
>>> On 2023-09-17 08:01, Jon Turney via Cygwin-apps wrote:
>>>> On 16/09/2023 15:17, Christian Franke via Cygwin wrote:
>>>>> Found during tests of busybox package:
>>>>> If the path of the top build directory contains a symlink and the 
>>>>> project's build scripts normalize pathnames, no debug info is 
>>>>> created by cygport.
>>>>>
>>>>> This is because options like
>>>>>   -fdebug-prefix-map=${B}=/usr/src/debug/${PF}
>>>>> have no effect because ${B} contains a symlink but the compiler is 
>>>>> run with the real source path.
>>>>
>>>> I think that there was some historical bug with gcc where a 
>>>> relative path for the old path in this mapping wasn't correctly 
>>>> handled, which is why were using an absolute path here at all.
>>>>
>>>> So changing it to something like [1] (if that works), might be better.
>>>>
>>>> [1] 
>>>> https://github.com/jon-turney/cygport/commit/4175d456a9184c5cdebd8bfb4b5ba30583cedd66
>
> Should bin/cygport.in:534: not have $B between the == as in line 531:
>
>     declare ${flags}+=" -fdebug-prefix-map=${B}=/usr/src/debug/${PF}"
>     ...
>     declare ${flags}+=" -fdebug-prefix-map==/usr/src/debug/${PF}"
>
> or be hoist above the condition if identical, unless that is some 
> undocumented default for cwd?

I guess the == without ${B} is intentional because it makes the debug 
source path relative to ${B} as lines 535-536 also do.


> ...
>>> An STC script which creates test dirs to demonstrate the issue and 
>>> show the alternative outputs would be nice so anyone can see.
>
>> $ ln -s /usr/src /tmp/source
>>
>> $ cd /tmp/source
>>
>> $ pwd
>> /tmp/source
>>
>> $ /bin/pwd
>> /usr/src
>>
>> $ pwd -P
>> /usr/src
>>
>> $ /bin/pwd -L
>> /tmp/source
>
> Thanks, looks good - care to submit a patch, including above 
> suggestions, to cover all bases?
>

Users may have a good reason to use a symlinked directory, e.g. fake the 
original build path during a rebuild. So I'm still not sure how to 
handle this.

- Simply warn the user:

   declare -r top=$(cd ${_topdir}; pwd);
  +if [ "${top}" != "$(cd ${_topdir}; pwd -P)" ]
  +then
  +       warning "symlinks in ${top} do not work with some build systems."
  +fi
   unset _topdir;

- or enforce the real path:

  -declare -r top=$(cd ${_topdir}; pwd);
  +declare -r top=$(cd ${_topdir}; pwd -P);
  +if [ "${top}" != "$(cd ${_topdir}; pwd -L)" ]
  +then
  +       inform "using real path ${top} as top level directory."
  +fi
   unset _topdir;

Projects using GNU autotools and cyg{conf,make,install} in cygport are 
usually not affected by symlinks in ${top}.

-- 
Regards,
Christian