(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.)
-traditional flag; you need to use "gcc -E" to get sane behavior.
Override sys.mk's definition of CPP in defs.Darwin.mk, and don't
re-override CPP in gcc.mk if ${OPSYS} == Darwin.
banner the use of "#include" over "#import" when including headers.
This generates a _huge_ number of warnings when building practically all
Objective-C code where it is convention to use "#import". Suppress
the warning if we're building Objective-C code using GCC by passing
-Wno-import to the compiler.
was:
1% make show-var PKG_STAGE=configure VARNAME=FC
g77
2% make show-var PKG_STAGE=configure VARNAME=F77
/usr/pkgsrc-current/math/scilab/work/.gcc/bin/g77
is:
3% make show-var PKG_STAGE=configure VARNAME=FC
g77
4% make show-var PKG_STAGE=configure VARNAME=F77
g77
fixes some buildlink spillover noted in the scilab package.
lists, then just assume that we need gcc3. The rest of the code in the
file assumes that we either need gcc2 or gcc3, so this provides a
fall-through, default value.
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.