libtool compiler_lib_search_paths

[Richard PALO <richard.palo%free.fr@localhost>]

I've noticed recently that libtool returns strange 
compiler_lib_search_paths now, that is without the trailing DOT 
suppressed -- that is, at least on solaris.

For example, with Jonathans gcc 4.7.3 build from the 2013Q2 bits (on 
illumos) looking in ${LOCALBASE}/bin/libtool:
> compiler_lib_search_dirs="-R/opt/local/lib 
> /opt/local/gcc47/lib/gcc/i386-sun-solaris2.11/4.7.3 
> /opt/local/gcc47/lib/gcc/i386-sun-solaris2.11/4.7.3/../../.. 
> -R/opt/local/gcc47/i386-sun-solaris2.11/lib/. -R/opt/local/gcc47/lib/."
> compiler_lib_search_path="-R/opt/local/lib 
> -L/opt/local/gcc47/lib/gcc/i386-sun-solaris2.11/4.7.3 
> -L/opt/local/gcc47/lib/gcc/i386-sun-solaris2.11/4.7.3/../../.. 
> -R/opt/local/gcc47/i386-sun-solaris2.11/lib/. -R/opt/local/gcc47/lib/."

Looks similar with gcc 4.8.1 on current bits.

This wasn't like that before... certainly not in Q1..

Paths in shared libraries look like the following:
> richard@omni1:~$ ldd -d /opt/local/lib/libintl.so
>         libiconv.so.2 =>      /opt/local/lib/libiconv.so.2
>         libc.so.1 =>  /lib/libc.so.1
>         libumem.so.1 =>       /lib/libumem.so.1
>         libgcc_s.so.1 =>      
> /opt/local/gcc47/i386-sun-solaris2.11/lib/./libgcc_s.so.1
>         libm.so.2 =>  /lib/libm.so.2

Seems ugly and potentially wrong to have DOT in the path above.

Do any other platforms experience this?