Subject: Re: libtool fails w/o c++ compiler
To: grant beattie <grant@NetBSD.org>
From: Todd Vierling <email@example.com>
Date: 11/28/2004 00:50:49
On Sun, 28 Nov 2004, grant beattie wrote:
> > I found this was also case on Tru64 where you get a c compiler but no
> > c++ compiler in base (though the failure is slightly different, the
> > command to extract symbols from libraries fails for me).
> try replacing patch-ab with the attached version. it changes where
> $CXX gets used, and fixes the "extract symbols" test on osf1 for me.
> it should fix other problems that happen when a c++ compiler isn't
> found, too.
Please don't commit as-is, yet. The change may be needed, to make it work
correctly without C, but doing so will bork C++ later on if it is used.
The problem here is that C++ needs a separate section in the generated
script with tweaked link options, and if it's not there when libtool is
finally used on C++ code, Strange Things Can Happen.
It may be that a separate libtool-base-c package (for compilations where
USE_LANGUAGES="c" exactly) is needed, changing libtool-base to depend on C++
and F77 with its own USE_LANGUAGES setting. So, anything using more than
just C would get the more "full-featured" libtool-base version, but building
of that full-featured version could be deferred until a suitable compiler is
available. Whether or not a C-only version is built and used at all could
be influenced by PKGSRC_COMPILER and/or mk/platform/OPSYS.mk settings to
determine if the C++ compiler's presence can be guaranteed.
I'll look into all this next week and draft a plan to fix the problem more
permanently along these lines.
-- Todd Vierling <firstname.lastname@example.org> <email@example.com>