Patchwork [2/2] libtool: normalize link paths before considering for RPATH

Libtool may be passed link paths of the form "/usr/lib/../lib", which fool
its detection code into thinking it should be included as an RPATH in
the generated binary.  Normalize before comparision.

Signed-off-by: Andy Ross <andy.ross@windriver.com>
---
 meta/recipes-devtools/libtool/libtool-2.4.2.inc    |  1 +
 .../libtool/libtool/norm-rpath.patch               | 42 ++++++++++++++++++++++
 2 files changed, 43 insertions(+)
 create mode 100644 meta/recipes-devtools/libtool/libtool/norm-rpath.patch

On Fri, 2012-08-17 at 08:53 -0700, Andy Ross wrote:
> Libtool may be passed link paths of the form "/usr/lib/../lib", which fool
> its detection code into thinking it should be included as an RPATH in
> the generated binary.  Normalize before comparision.
> 
> Signed-off-by: Andy Ross <andy.ross@windriver.com>
> ---
>  meta/recipes-devtools/libtool/libtool-2.4.2.inc    |  1 +
>  .../libtool/libtool/norm-rpath.patch               | 42 ++++++++++++++++++++++
>  2 files changed, 43 insertions(+)
>  create mode 100644 meta/recipes-devtools/libtool/libtool/norm-rpath.patch
> 
> diff --git a/meta/recipes-devtools/libtool/libtool-2.4.2.inc b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> index 5b9557e..691427e 100644
> --- a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> @@ -19,6 +19,7 @@ SRC_URI = "${GNU_MIRROR}/libtool/libtool-${PV}.tar.gz \
>             file://avoid_absolute_paths_for_general_utils.patch \
>             file://fix-rpath.patch \
>  	   file://respect-fstack-protector.patch \
> +           file://norm-rpath.patch \
>            "
>  
>  SRC_URI[md5sum] = "d2f3b7d4627e69e13514a40e72a24d50"
> diff --git a/meta/recipes-devtools/libtool/libtool/norm-rpath.patch b/meta/recipes-devtools/libtool/libtool/norm-rpath.patch
> new file mode 100644
> index 0000000..03a7667
> --- /dev/null
> +++ b/meta/recipes-devtools/libtool/libtool/norm-rpath.patch
> @@ -0,0 +1,42 @@
> +libtool: normalize link paths before considering for RPATH
> +
> +Libtool may be passed link paths of the form "/usr/lib/../lib", which
> +fool its detection code into thinking it should be included as an
> +RPATH in the generated binary.  Normalize before comparision.
> +
> +Signed-off-by: Andy Ross <andy.ross@windriver.com>
> +Upstream-Status: Pending
> +
> +diff -ru a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
> +--- a/libltdl/config/ltmain.m4sh	2012-08-16 13:58:55.058900363 -0700
> ++++ b/libltdl/config/ltmain.m4sh	2012-08-16 16:34:54.616627821 -0700
> +@@ -7288,8 +7288,13 @@
> + 	      else
> +                 # We only want to hardcode in an rpath if it isn't in the
> +                 # default dlsearch path.
> ++                libdir_norm=`echo $libdir \
> ++                  | sed 's/\/\+\.\(\/\+\|$\)/\//g' \
> ++                  | sed 's/[^\/]\+\/\+\.\.\(\/\+\|$\)//g' \
> ++                  | sed 's/\/\+/\//g' \
> ++                  | sed 's/\(.\)\/$/\1/g'`
> + 	        case " $sys_lib_dlsearch_path " in
> +-	        *" $libdir "*) ;;
> ++	        *" $libdir_norm "*) ;;
> + 	        *) eval flag=\"$hardcode_libdir_flag_spec\"
> +                    func_append dep_rpath " $flag"
> +                    ;;

Can't we use func_norm_abspath here?

Cheers,

Richard

On 08/19/2012 03:06 AM, Richard Purdie wrote:
> On Fri, 2012-08-17 at 08:53 -0700, Andy Ross wrote:
>> ++                libdir_norm=`echo $libdir \
>> ++                  | sed 's/\/\+\.\(\/\+\|$\)/\//g' \
>> ++                  | sed 's/[^\/]\+\/\+\.\.\(\/\+\|$\)//g' \
>> ++                  | sed 's/\/\+/\//g' \
>> ++                  | sed 's/\(.\)\/$/\1/g'`
>
> Can't we use func_norm_abspath here?

I have to admit I got a little confused reading that code (not that my
sed mess is significantly better, but at least I trust it because I
wrote it); but it looks to me like it's an abspath implementation on
the host filesystem (not the use of `pwd` in a few places).  That will
work for pruning in this case, since the problem case is already an
absolute path to a host directory.  But I don't see how it won't in
principle break things by expanding host paths.

Andy

On Mon, 2012-08-20 at 09:59 -0700, Andy Ross wrote:
> On 08/19/2012 03:06 AM, Richard Purdie wrote:
> > On Fri, 2012-08-17 at 08:53 -0700, Andy Ross wrote:
> >> ++                libdir_norm=`echo $libdir \
> >> ++                  | sed 's/\/\+\.\(\/\+\|$\)/\//g' \
> >> ++                  | sed 's/[^\/]\+\/\+\.\.\(\/\+\|$\)//g' \
> >> ++                  | sed 's/\/\+/\//g' \
> >> ++                  | sed 's/\(.\)\/$/\1/g'`
> >
> > Can't we use func_norm_abspath here?
> 
> I have to admit I got a little confused reading that code (not that my
> sed mess is significantly better, but at least I trust it because I
> wrote it); but it looks to me like it's an abspath implementation on
> the host filesystem (not the use of `pwd` in a few places).  That will
> work for pruning in this case, since the problem case is already an
> absolute path to a host directory.  But I don't see how it won't in
> principle break things by expanding host paths.

As I read it, it will only use pwd if the path is relative or empty. I
can't think of a case where you'd encode something like that into an
rpath...

Libtool can't expect the directory to exist on the filesystem when it
makes these calls so we should be safe from that perspective.

Cheers,

Richard