[2/2] Fix source file not found when part of the path does not exist but that a canonicalized path exists.

  On 03/27/2015 08:24 AM, Pedro Alves wrote:
> On 02/03/2015 08:28 PM, Antoine Tremblay wrote:
>> Hi,
>>     Unfortunately the 1/2 patch of this patchset failed because it's
>> about 1M , and mailman is only accepting < 400k emails...
>>
>>     The patch is large since I'm replacing canonicalize-lgpl from
>> binutils with canonicalize and that triggers a few dependencies..
>
> Eh, so large...  What is it exactly pulling?

It is pulling the following modules as dependencies to canonicalize :

areadlink-with-size,bitrotate,chdir-long,cloexec,close,closedir,d-ino,dirname,dup,dup2,error,exitfail,fchdir,fcntl,fcntl-h,fd-hook,fdopendir,file-set,filename,filenamecat-lgpl,fstat,fstatat,getcwd,getcwd-lgpl,getdtablesize,gettext-h,hash,hash-pjw,hash-triple,intprops,mempcpy,memrchr,msvc-inval,msvc-nothrow,open,openat,openat-die,openat-h,opendir,readdir,realloc-posix,rewinddir,same,save-cwd,strdup-posix,strerror,strerror-override,strndup,strnlen,unistd-safer,xalloc,xalloc-die,xalloc-oversized,xgetcwd,xstrndup

>
>>
>>     Any ideas on how I should proceed ?
>>
>>     I could send a patch with only the change to the update-gnulib.sh maybe ?
>
> Yes, please, along with any other changes outside import/.
> I assume you'll need to change gdb/gnulib/Makefile.in too.
> And be sure to explain why canonicalize-lgpl doesn't work
> for what we need.

I will add the changes outside of import at the end of this mail, 
however I think I should commit the whole thing otherwise someone else 
will have to do it... Maybe exceptionally you can review the patch on 
github ? (I've included the link later in the email)

As to why canonizlize-gpl doesn't work :

Since canonicalize-lgpl uses the system's realpath implementation, we 
can't canonicalize a path that does not exist on the current file system 
in it's uncanonicalized form.

However this path may exist on the system in it's canonicalized form, 
this is actually common with some IDEs that use outside of tree builds 
and relative paths as documented in PR breakpoints/17497.

I can add this to the patch comments....

>
> Could you push the patches as a branch somewhere?  That'd
> make it trivial to pull/try them.

Yes I've uploaded my patchset at : https://github.com/hexa00/binutils-gdb

Regards,

Antoine

Patch outside of import (Note that Makefile.in is generated 
automatically so the only manual change is gdb/gnulib/update-gnulib.sh
  

On 03/27/2015 02:48 PM, Antoine Tremblay wrote:
> On 03/27/2015 08:24 AM, Pedro Alves wrote:
>> On 02/03/2015 08:28 PM, Antoine Tremblay wrote:
>>> Hi,
>>>     Unfortunately the 1/2 patch of this patchset failed because it's
>>> about 1M , and mailman is only accepting < 400k emails...
>>>
>>>     The patch is large since I'm replacing canonicalize-lgpl from
>>> binutils with canonicalize and that triggers a few dependencies..
>>
>> Eh, so large...  What is it exactly pulling?
>
> It is pulling the following modules as dependencies to canonicalize :
>
> areadlink-with-size,bitrotate,chdir-long,cloexec,close,closedir,d-ino,dirname,dup,dup2,error,exitfail,fchdir,fcntl,fcntl-h,fd-hook,fdopendir,file-set,filename,filenamecat-lgpl,fstat,fstatat,getcwd,getcwd-lgpl,getdtablesize,gettext-h,hash,hash-pjw,hash-triple,intprops,mempcpy,memrchr,msvc-inval,msvc-nothrow,open,openat,openat-die,openat-h,opendir,readdir,realloc-posix,rewinddir,same,save-cwd,strdup-posix,strerror,strerror-override,strndup,strnlen,unistd-safer,xalloc,xalloc-die,xalloc-oversized,xgetcwd,xstrndup
>
>
>>
>>>
>>>     Any ideas on how I should proceed ?
>>>
>>>     I could send a patch with only the change to the update-gnulib.sh
>>> maybe ?
>>
>> Yes, please, along with any other changes outside import/.
>> I assume you'll need to change gdb/gnulib/Makefile.in too.
>> And be sure to explain why canonicalize-lgpl doesn't work
>> for what we need.
>
> I will add the changes outside of import at the end of this mail,
> however I think I should commit the whole thing otherwise someone else
> will have to do it... Maybe exceptionally you can review the patch on
> github ? (I've included the link later in the email)
>
> As to why canonizlize-gpl doesn't work :
>
> Since canonicalize-lgpl uses the system's realpath implementation, we
> can't canonicalize a path that does not exist on the current file system
> in it's uncanonicalized form.
>
> However this path may exist on the system in it's canonicalized form,
> this is actually common with some IDEs that use outside of tree builds
> and relative paths as documented in PR breakpoints/17497.
>
> I can add this to the patch comments....
>
>>
>> Could you push the patches as a branch somewhere?  That'd
>> make it trivial to pull/try them.
>
> Yes I've uploaded my patchset at : https://github.com/hexa00/binutils-gdb
>
> Regards,
>
> Antoine
>
> Patch outside of import (Note that Makefile.in is generated
> automatically so the only manual change is gdb/gnulib/update-gnulib.sh
>
> diff --git a/gdb/gnulib/update-gnulib.sh b/gdb/gnulib/update-gnulib.sh
> index 5c7238f..5845f09 100644
> --- a/gdb/gnulib/update-gnulib.sh
> +++ b/gdb/gnulib/update-gnulib.sh
> @@ -31,7 +31,7 @@
>   # The list of gnulib modules we are importing in GDB.
>   IMPORTED_GNULIB_MODULES="\
>       alloca \
> -    canonicalize-lgpl \
> +    canonicalize \
>       dirent \
>       dirfd \
>       errno \

I forgot to mention if you have a recent debian or ubuntu with perl > 
5.6 you will have problems running update-gnulib.sh you need to patch 
your automake 1.11.1 with the patch at : 
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=aclocal-function-prototypes.debdiff;att=1;bug=752784

Actually this patch contains a quilt patchset you need to apply the 
patch inside this patchset...