Subject: pkg/35307: libtool vs compiler.mk
To: None <email@example.com, firstname.lastname@example.org,>
From: None <email@example.com>
Date: 12/21/2006 17:10:01
>Synopsis: libtool vs compiler.mk
>Arrival-Date: Thu Dec 21 17:10:01 +0000 2006
>Originator: Dan McMahill
>Release: pkgsrc as of 2006-12-21
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
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.
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
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.