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

[Antoine Tremblay]

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