Re: [PATCH] cygwin sharedlib build fixes, terminfo

[Nicholas Wourms]

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
>                 AC_PATH_PROG(CXX,g++)
>         fi
>         if test "$CXX" = "g++" ; then
>                 AC_MSG_WARN(ignoring hardcoded g++)
>                 cf_with_cxx=no; CXX=""; GXX="";
>         fi

> #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
$LTCCOMPILEMODE="--mode=compile"
$LTCLINKMODE="--mode=link" or ""
$LTCINSTALLMODE="--mode=install"
$LTCUNINSTALLMODE="--mode=uninstall"
$LTCCCTAG="--tag=CC"
$LTCCXXTAG="--tag=CXX"
$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).

Cheers,
Nicholas