libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sys_lib_search_patch_spec/path_separator (Re: Suggested pathes to CV


From: Gary V. Vaughan
Subject: Re: sys_lib_search_patch_spec/path_separator (Re: Suggested pathes to CVC libtool: Mingw improvement, .rc support)
Date: Sat, 22 Sep 2001 15:28:45 +0100
User-agent: Mutt/1.3.22.1i

On Sat, Sep 15, 2001 at 05:06:54PM +0200, Guido Draheim wrote:
> Tor Lillqvist wrote:
> > 
> > -- Small improvement for mingw-hosted tool support (while still
> > running libtool on cygwin). In that case PATH_SEPARATOR is ':', but
> > gcc -print-search-dirs still prints its search path with ';' as
> > separator.
> > 
> >    yes,mingw*)
> >      library_names_spec='${libname}`echo ${release} | sed -e 
> > 's/[[.]]/-/g'`${versuffix}.dll'
> > -    sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" 
> > | sed -e "s/^libraries://" -e "s/$PATH_SEPARATOR/ /g"`
> > +    sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" 
> > | sed -e "s/^libraries://"`
> > +    if echo "$sys_lib_search_path_spec" | [egrep ';[C-Z]:/' >/dev/null]; 
> > then
> > +       # It is most probably a Windows format PATH printed by
> > +       # mingw gcc, but we are running on Cygwin. Gcc prints its search
> > +       # path with ; separators, and with drive letters. We can handle the
> > +       # drive letters (cygwin fileutils understands them), so leave them,
> > +       # especially as we might pass files found there to a mingw objdump,
> > +       # which wouldn't understand a cygwinified path. Ahh.
> > +       sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | sed -e 
> > 's/;/ /g'`
> > +    else
> > +       sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | sed  
> > -e "s/$PATH_SEPARATOR/ /g"`
> > +    fi
> >      ;;
> 
> being the one to look into cross-mingw, I do support the idea to have a closer
> look for a dosish pathstyle reported by gcc itself. However I have a few 
> questions 
> (which should make you know I do not know about cygwin-hosted 
> ming-compiling)...
> 
> a) why is it just "C:/" - with a forward-slash? no backward-slash possible?

Purely due to the way that mingw `gcc -print-path-dirs' formats its
output I think.

> b) why is it just bigcaps drive-letters?

Ditto.  Although I guess this comes from the spec file, so maybe more
care _is_ needed after all?

> c) a singular path (where the ";" fails) is 99,99% improbable, I second that.
> well....
> 
> In one of my pre-submitted patch-files on my disk, I did just check for the
> existence of a ";" under the assumption that unix-pathlists will never ever
> contain that character inside a dirpath-element - or atleast it can be 
> rightfully
> called insane. The thing could look like the following, so *hmm* what would 
> YOU 
> think of a style like this:
> 
> case "$sys_lib_search_path_spec" in
>   # unixshell pathlists are not supposed to contain any ";" in its path 
> elements
>   *;*) sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | sed -e 
> 's/;/ /g'` ;;
>   *)   sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | sed  -e 
> "s/$PATH_SEPARATOR/ /g"` ;;
> esac

If you find that it passes your torture tests (whatever they may be
;-)), please roll a patch and post it to libtool-patches.

Cheers,
        Gary.
-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]