>Number:         35307
>Category:       pkg
>Synopsis:       libtool vs compiler.mk
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 21 17:10:01 +0000 2006
>Originator:     Dan McMahill
>Release:        pkgsrc as of 2006-12-21
>Organization:
NetBSD
>Environment:
	
	
>Description:

compiler.mk uses the list of compilers in PKGSRC_COMPILER along with various
variables like NOT_FOR_COMPILER to decide which compiler to use for a particular
package.

One problem here is that libtool-base is compiled with a particular compiler
and becomes customized to that compiler.  Consider the following example now:

You want to generally use sunpro for the compiler since the binaries tend
to run faster on sparcs and also that seems to be the way to getting a working
firefox.  Libtool is built around sunpro.

Now you want to build something else that is simply not compatible with sunpro
because it relies too much on g++ or for whatever reason is not easy to 
fix for sunpro.  Ok, put NOT_FOR_COMPILER+= sunpro in that packages Makefile
and in /etc/mk.conf make sure you have PKGSRC_COMPILER= sunpro gcc

The magic in the compiler and wrapper framework now tries to use gcc for this
particular package but unfortunately if the particular package has USE_LIBTOOL,
you get a libtool which is not compatible with the gcc toolchain.

	
>How-To-Repeat:
	
>Fix:

I'm thinking that perhaps when PKGSRC_COMPILER is set to multiple choices that 
there needs to be a /usr/pkg/bin/libtool-gcc as well as a /usr/pkg/bin/libtool-sunpro.
Then bsd.wrapper.mk would pick out the correct libtool for the currently 
selected toolchain.

Now the question is the best way to implement that.  Perhaps devel/libtool-base-sunpro,
devel/libtool-base-gcc, etc should be created and they would all point to the same files
but just set ONLY_FOR_COMPILER to get the right one.

	

>Unformatted: