[Top][All Lists]

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

problem: sys_lib_search_path_spec for MinGW

From: Jon Leichter
Subject: problem: sys_lib_search_path_spec for MinGW
Date: Thu, 20 Dec 2001 21:56:37 -0800

Hi all.

Cygwin is a distribution that comes with a GCC suite capable of producing
"cygwin" binaries, i.e. binaries dependent on the Cygwin DLL, which gives
the binaries an illusion that they're on UNIX.

MinGW is a distribution that comes with a GCC suite capable of producing
"mingw" binaries, i.e. binaries that are dependent only on the native
Windows DLLs.

Libtool attempts to set sys_lib_search_path_spec when it is configured. It
is not dynamically determined every time libtool is ran. To determine
sys_lib_search_path_spec at configure time, libtool (1.4.2) employs the
following rules:

        Cygwin sets this variable to the global default:
                sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"

        MinGW executes the following command:
            sys_lib_search_path_spec=`$CC -print-search-dirs | grep 
"^libraries:" |
sed -e "s/^libraries://" -e "s/;/ /g"`

Here's the problem: Cygwin GCC can be used to produce "cygwin" OR "mingw"
binaries. It depends on whether or not it was given the -mno-cygwin switch.
Furthermore, Cygwin GCC will return the same output for
the -print-search-dirs switch whether or not the -mno-cygwin switch is
specified. The output of -print-search-dirs contains colon(:) separated
paths. Thus, the 'sed' command has no chance of doing the right thing when
one uses Cygwin GCC in "mingw" mode. Also, the search dirs returned is what
GCC uses in "cygwin" mode. It doesn't attempt to report different paths for
"mingw" mode.

I exclusively use Cygwin GCC to produce "mingw" binaries. Thus, when I
configure libtool in my Cygwin environment, I do so with the following
command line:

        $ env CC=mgcc ./configure --prefix=/usr/local/mingw 

mgcc is a wrapper script that executes gcc with the -mno-cygwin switch. The
reason that I have this wrapper script is a whole other discussion.

The thing about this configuration is that it is not really native MinGW.
It's MinGW support provided by Cygwin GCC.

I happen to not know the answer to the following question: is there a better
way to indicate to libtool what I'm trying to configure, i.e. MinGW
(provided by Cygwin GCC)? If there is, perhaps my problem is due to the way
that I configure.

It seems to me that if you want to get the correct sys_lib_search_path at
configure time, you need to compile a bogus program, spawn the compiler
with -v, and parse the -L arguments from the link line, e.g.:

        cat > conftest.c <<EOF
        int main() { return 0; }
        link_out=`$CC -v -o conftest.exe conftest.c 2>&1 | grep collect2`
        for i in `echo $link_out`
                path=`expr $i : "-L\(.*\)"`
                if test -n "$path"
                        lib_search_path_spec="$lib_search_path_spec $path"
        rm -f conftest.exe
        # and always add GCC's generic hard-coded defaults
        lib_search_path_spec="$lib_search_path_spec /lib /usr/lib"

This method would get the right path for Cygwin GCC in "cygwin" mode, Cygwin
GCC in "mingw" mode, and MinGW GCC.

It's also too bad that libtool can be configured for only one mode. But I
can live with having to configure two different libtools that live in two
different places.

Comments, opinions?


reply via email to

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