which are the full option names used to set rpath directives for the
linker and the compiler, respectively. In places were we are invoking
the linker, use "${LINKER_RPATH_FLAG} <path>", where the space is
inserted in case the flag is a word, e.g. -rpath. The default values
of *_RPATH_FLAG are set by the compiler/*.mk files, depending on the
compiler that you use. They may be overridden on a ${OPSYS}-specific
basis by setting _OPSYS_LINKER_RPATH_FLAG and _OPSYS_COMPILER_RPATH_FLAG,
respectively. Garbage-collect _OPSYS_RPATH_NAME and _COMPILER_LD_FLAG.
some packages (for example ntp4) have configure scripts that try to be
clever and insert their own if they don't find any. This would be wrong
on a system that relies on /etc/compiler.defaults to choose the correct
ABI.
(Not having this set caused various rpath related problems, as the compiler
was passed ' -rpath,/path' instead of '-Wl,-rpath,/path', leading to
a rpath of ",path", which of course wouldn't work.)
Package Makefiles may now directly include compiler.mk.
* Don't include compiler.mk within bsd.prefs.mk any longer. It was only
included for the purposes of defining CC_VERSION. Packages that want
to test the value of CC_VERSION should now first include
"../../mk/compiler.mk". Any GCC_REQD statements in package Makefiles
should be set before compiler.mk is included.
* Simpllfy pkgsrc/mk/compiler/*.mk files as a result of not needing to
be included indirectly by bsd.prefs.mk. We remove the special handling
associated with detecting whether the file was included from within
bsd.prefs.mk. These files are now much more straightforward to write
and understand.
* G/C the BSD_PREFS_MK stack mechanism as the only users (compiler/*)
no longer need it.
* Ensure that directories are prepended to the PATH only from within
bsd.pkg.mk.
compiler set. This will cause the libtool configuration found in several
packages to use the correct C++ compiler even though the package doesn't
use C++. This was causing bugs when CXXFLAGS contained flags not
understood by the system gcc-2.95.3.
building of software. For packages that use either buildlink2 or
buildlink3, this would be the wrapper script in ${BUILDLINK_DIR}.
* Garbage-collect _BLNK_WRAP_SETENV.* as those are not needed after
the above changes. Configure and make processes will automatically
find the right compilers in the PATH.
* PKGLIBTOOL and PKGSHLIBTOOL are no longer needed since LIBTOOL and
SHLIBTOOL point to the correct libtools regardless of any
USE_BUILDLINK[23] definitions.
the compiler and that it's behind .tools/bin and .buildlink/bin, regardless
of whether or not we're using gcc3-c or not, or whether it's been installed
yet in the process of satisfying dependencies, etc.
due to a type on gcc.mk that causes the ${_GCC_PREFIX}/bin to always be
prepended to the PATH. The problem that was hiding was "make" resolving
to ${TOOLS_DIR}/bin/make if the package used GNU make, which broke
building since the package Makefile is a BSD Makefile and we passed
PATH to some phases of the build. Fix this by expanding MAKE to the
full path to ${MAKE} in bsd.prefs.mk. We also garbage collect the now
useless checks for PHASES_AFTER_BUILDLINK that cluttered the PREPEND_PATH
code.
(by checking PREPEND_PATH) and only for those phases of the build that
care about the PATH (buildlink or later). We also pass the PATH to
those same phases of the build so that executing ${CC} will work correctly
from custom {pre,do,post}-* targets that occur at buildlink time or
later.
Any additions to DEPENDS/BUILD_DEPENDS or inclusions of buildlink[23].mk
files are deferred till bsd.compiler.mk is included by bsd.pkg.mk. We
allow bsd.compiler.mk to be included by bsd.prefs.mk solely for the purpose
of setting CC_VERSION properly for use by package Makefiles.
There is the surprising behaviour that CC_VERSION won't necessarily have
the correct value at all times until after "make extract" has been
completed (dependencies are installed before "make extract"), so package
Makefile writers should keep that in mind. Just to note that this is
_existing_ behaviour that's preserved by these changes.
USE_LANGUAGES
Lists the languages used in the source code of the package,
and is used to determine the correct compilers to install.
Valid values are: c, c++, fortran, java, objc. The default
is "c".
Packages that don't need any compilers and set this variable to an
empty value, e.g. "USE_LANGUAGES=".
This can probably be combined in some smart way with setting
USE_GCC_SHLIBS and USE_FORTRAN automatically.
changes from the old compiler.mk are:
* Split apart the compiler-specific logic into separate files. This
should make supporting other compilers a bit easier.
* Deprecate all of the USE_* compiler.mk variables, e.g. USE_GCC[23],
USE_SUNPRO, etc. It's all replaced with a new PKGSRC_COMPILER
variable.
* Clean up the GCC handling so that it's all controlled by a single
variable GCC_REQD. The following behaviour is expected:
(a) If USE_PKGSRC_GCC is defined, then pretend there is no GCC on
the system.
(b) If there is no GCC, then the appropriate GCC corresponding to
GCC_REQD is installed and used.
(c) If there is a GCC, if it satisfies GCC_REQD, then use it;
otherwise install and use the appropriate GCC package.
(d) If lang/gcc is installed and GCC_REQD > 2.95.3, then lang/gcc3
is installed and used.
(e) If lang/gcc3 is installed and GCC_REQD = 2.95.3, then gcc3 is
still used instead of installing lang/gcc.
New features include:
* PKGSRC_COMPILER takes a list of values specifying the chain of
compilers to call when building packages. Valid values are:
distcc distributed C/C++ (chainable)
ccache compiler cache (chainable)
gcc GNU
mipspro Silicon Graphics, Inc. MIPSpro
sunpro Sun Microsystems, Inc. WorkShip/Forte/Sun
ONE Studio
The default is "gcc". You can use ccache and/or distcc with an
appropriate PKGSRC_COMPILER setting, e.g. "ccache distcc gcc".
* Change GCC_REQD to hold a list of values that we scan through to
find the highest version of GCC required by the build. Package
Makefiles should now do "GCC_REQD+=..." instead of "GCC_REQD=...".
