>Number:         28445
>Category:       pkg
>Synopsis:       devel/libtool needs lang-specific version
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 28 20:24:00 +0000 2004
>Originator:     Todd Vierling
>Release:        NetBSD 2.0_RC4
>Organization:
	DUH.ORG:  Pointing out the obvious since 1994.
>Environment:
>Description:

An e-mail I sent to tech-pkg follows; this PR is mainly a reminder to myself
to get this fixed.

Date: Sun, 28 Nov 2004 00:50:49 -0500 (EST)
From: Todd Vierling <tv@duh.org>
To: grant beattie <grant@NetBSD.org>
Cc: Julio M. Merino Vidal <jmmv@menta.net>, tech-pkg@NetBSD.org
Subject: Re: libtool fails w/o c++ compiler

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>

>How-To-Repeat:
>Fix: