[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] cygwin sharedlib build fixes, terminfo
From: |
Charles Wilson |
Subject: |
Re: [PATCH] cygwin sharedlib build fixes, terminfo |
Date: |
Sun, 03 Aug 2003 16:02:12 -0400 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 |
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."
But, we can't just find the libtool script and do a grep on it --
because it might be a wrapper script.
Maybe this is just a user warning: "When using --with-libtool, you may
need to manually set CC and CXX to the values expected by libtool"
However, libtool-1.4.x doesn't really support ANY language other than C
at all, so it doesn't work (or only works via luck; I haven't tried) in
the c++ directory either.
So, it's a libtool-1.5 bug. I'll be reporting it to the libtool list
when I take care of a few other things. I might even be able to come up
with a patch...
Actually, I guess this isn't really a libtool bug; it's more of a design
flaw. Which is unlikely to be changed, because it works fine in most
cases -- the likely response is going to be "don't do that" (e.g. don't
'switch compilers' for a given language, when building libtool itself,
and when building a library that uses libtool).
--
Chuck
- Re: [PATCH] cygwin sharedlib build fixes, terminfo, Thomas Dickey, 2003/08/02
- Re: [PATCH] cygwin sharedlib build fixes, terminfo, Charles Wilson, 2003/08/03
- Re: [PATCH] cygwin sharedlib build fixes, terminfo,
Charles Wilson <=
- Re: [PATCH] cygwin sharedlib build fixes, terminfo, Charles Wilson, 2003/08/03
- Re: [PATCH] cygwin sharedlib build fixes, terminfo, Thomas E. Dickey, 2003/08/03
- Re: [PATCH] cygwin sharedlib build fixes, terminfo, Charles Wilson, 2003/08/03
- Re: [PATCH] cygwin sharedlib build fixes, terminfo, Nicholas Wourms, 2003/08/03
- Re: [PATCH] cygwin sharedlib build fixes, terminfo, Charles Wilson, 2003/08/03
- Re: [PATCH] cygwin sharedlib build fixes, terminfo, Nicholas Wourms, 2003/08/03
- Re: [PATCH] cygwin sharedlib build fixes, terminfo, Thomas E. Dickey, 2003/08/03
- Re: [PATCH] cygwin sharedlib build fixes, terminfo, Charles Wilson, 2003/08/04