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 <tv@duh.org> <tv@pobox.com>