[Top][All Lists]

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

Re: [PATCH] cygwin sharedlib build fixes, terminfo

From: Nicholas Wourms
Subject: Re: [PATCH] cygwin sharedlib build fixes, terminfo
Date: Sun, 03 Aug 2003 17:51:27 -0400
User-agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

address@hidden wrote:

Charles Wilson wrote:

Yes, this is the libtool bug I referred to. Libtool-1.5 *requires* that the --tag=XXX parameter be present, when using any language other than C. However, libtool-1.5 neglects to *record* that value in the uninstalled .la file, for use when relinking-to-install.

Nope, this was wrong. libtool only requires the tag parameter when it cannot infer the correct one. This is how it infers:

look at the compiler specified on libtool's command line (in this case, "c++"). Now, search through all of the tagged sections in the libtool script itself, looking for the tag in which "$CC" is set to that same compiler.

In this particular case, /usr/bin/libtool's CXX tagged section has 'CC=g++' -- but for some reason the Makefile has 'CC=c++'. Therefore, the libtool command line is

/usr/bin/libtool --mode=link c++ ....

But c++ != g++. So, libtool can't infer the tag, and complains.

I hand-edited my c++/Makefile (removing --tag=CXX from LIBTOOL, and setting CXX=g++), and tried again -- and everything worked fine. So, I just need to figure out how to get the autoconfigured stuff to generate a Makefile like that. Why is c++ "preferred" over g++....

So, that leaves two questions:

#1) why is ncurses configure determining that CXX should be 'c++' when libtool's build procedure auto-found 'g++'?

I wonder if this stanza in ncurses configure.in is somehow the culprit:

        if test "$CXX" = "g++" ; then
        if test "$CXX" = "g++" ; then
                AC_MSG_WARN(ignoring hardcoded g++)
                cf_with_cxx=no; CXX=""; GXX="";

#2) How can we make this foolproof in ncurses? What we really want is "if --with-libtool, then make sure that CC,CXX are set to the same value as that used by the libtool script we will be using."

Ok, how about this:

When checking for version, also check to see if libtool supports --tag=CC, which is always true for the multilang libtools:

1)check to see if user wants to build with libtool

2)check for libtool with "libtool --version"

3)if that works, then check to see if libtool
  supports "libtool --tag=CC --version"

4)if no, then we know libtool is "dumb" and can build like it currently
  does, if yes then goto 4.

5a)if user does not request c++, then just note to use --tag=CC.

5b)if user requests c++, then check to see if multi-lang libtool is
  configured to handle C++ with "libtool --tag=CXX --version"

6)if no, abort configure and advise user to install a libtool capable of
  compiling c++ or compile without libtool support**, otherwise proceed
  to step 7.

7)Run the following to get the respective compilers:
  "libtool --tag=CXX --config | egrep '^CC='"

Step 7 will return 2 instances of CC on two lines, which will correspond as follows:
CC=<the c compiler>
CC=<the c++ compiler>

**This is very rare and would only happen iff the user compiled the system libtool on a machine without a c++ compiler and then later either put a c++ compiler on the machine or moved the libtool script to another machine which had one.

Now how to handle this information. I suggest having makefile variables for the following attributes (only assigning values iff libtool is to be used, that way they won't interfere with non-libtool builds):

Autoconf subst values
$LTCLINKMODE="--mode=link" or ""
$LTCEXTRACPPFLAGS="any os/plat-specific c/cxx preprocessor flags"
$LTCEXTRALDFLAGS"any os/plat-specific linking flags"

Again, all of these would be subst into the templates and then passed to the Makefile lines as $(VAR). If nothing is assigned to any of the VARS, then nothing gets passed to the compile/link/install line. Of course, it would be easier if we could use am_conditional, but I know how you hate automake, so I won't push my luck here ;-P.

This should be fairly fool-proof, at least for libtools built since the turn of the century (can't say it will work with versions less then 1.4).


reply via email to

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