For now the GCC "c99 == gnu99" override is kept, but gnu99 is now supported as
a specific value for USE_LANGUAGES, so we may want to be specific where
required.
c11 and c17 (and the corresponding gnu11/gnu17 versions) are newly supported.
Looks like maybe the -Wl,-rpath-link business isn't necessary after
all -- will leave this as is until I find evidence otherwise. (joerg
says it was a workaround for NetBSD toolchain parts that weren't
properly adapted to use sysroot.)
With this, revert cwrappers version dependency to what it was before.
But keep it as TOOL_DEPENDS, not BUILD_DEPENDS.
For USE_LANGUAGES there is already a pkglint warning, but for GCC_REQD it
is missing. It's better to have this check directly in the
infrastructure since it is more reliable.
This check is disabled by default, to not cause any new breakage.
It should be enabled in bulk builds.
Platform support is determined by _OPSYS_SUPPORTS_CTF from mk/platform, the
user enables support by setting PKGSRC_USE_CTF=yes, and packages can
explicitly disable support with CTF_SUPPORTED=no or skip certain files with
CTF_FILES_SKIP.
The path to ctfconvert is configured via TOOLS_PLATFORM.ctfconvert.
If all of the requisite variables are enabled, a compiler-specific debug flag
is passed via the wrappers to ensure we have DWARF information to convert,
_INSTALL_UNSTRIPPED is explicitly defined to avoid binaries being stripped
prior to conversion, and the conversion is performed during the install stage.
It is recommended that users who enable the feature also set STRIP_DEBUG=yes
to reduce the final binary size once the conversion has been performed.
This has been used for the past year in Joyent SmartOS builds. FreeBSD is
marked as supported but is untested.
Reference the notion of making compilers visible to the build
environment. Mention setting --std flags. Note that the text is
currently aspirtational relative to gcc and C++.
(Comment change only.)
The ccache.mk file was checking for languages "c" and "c++".
New framework for C++ dialects (or revisions) was setting implicitly c++,
translating e.g. c++11 to c++.
compiler.mk set this c++ after including ccache.mk, so c++ was undefined
and ccache was ignored.
This helps to build large projects like LLVM+Clang+LLDB with ccache.
Sponsored by <The NetBSD Foundation>
This allows packages to specify the version of the standard that they
require, and the infrastructure then distils that down in a similar way
to GCC_REQD to the newest standard, avoiding clashes with different -std
requirements based on CXXFLAGS.
Broad concensus on tech-pkg and tested in bulk builds.
Only one compiler is used when "ada" is listed in LANGUAGES, and that
is the one built by the lang/gcc-aux source package. When PKGSRC_COMPILER
is defined as anything else other than "gcc", the Ada packages fail to
build. This can be seen when clang is used with CLANGBASE=${LOCALBASE}.
This straight-forward fix is to override the user specification of
PKGSRC_COMPILER when Ada is specified and define it as "gcc" in all cases.
Tested on NetBSD 6.1 amd64 with CLANGBASE=${LOCALBASE}
DragonFly has two compilers in base, GCC 4.4.7 and GCC 4.7.2.
The way one switches between them for userland programs is to set
CCVER in the environment.
However, to set this via make.conf is tricky. I've been using the
low level "ALL_ENV+= CCVER=gcc47", but this trick fails to properly
identify the compiler which results in _GCC_VERSION being incorrectly
defined.
Additionally, there are some prominent packages that do not build on
gcc 4.7 and the fix is either not fully understood or would require a
large amount of work to implement. In these cases, it is desireable
to specify the package be built on gcc 4.4 regardless of CCVER setting.
To address these issues, a new directive is added: DRAGONFLY_CCVER.
It is only effective if OPSYS equals "DragonFly", and it will properly
set CCVER and properly define _GCC_VERSION. It will also allow a
per package specification of a particular compiler in the pkg makefile.
All recent packages featuring Ada code have a hard dependency on the
lang/gnat-aux compiler package. The valid values for USE_LANGUAGES
are c, c99, c++, fortran, fortran77, java, objc, so specifying a
specific compiler was necessary up into now.
One problem with lang/gnat-aux is that it is installed at ${LOCALBASE}
where the lang/gccXX compilers are installed at ${LOCALBASE}/gccXX.
The latter compilers have no possibility of sharing conflicting files
unlike lang/gnat-aux. Rather than fundamentally update the GCC 4.6-based
lang/gnat-aux to avoid these conflicts, a new Ada-capable compiler
based on GCC 4.7 was created with the intent of being supported by
mk/compiler.mk and mk/compiler/gcc.mk.
The Ada packages will be effectively migrated from lang/gnat-aux to the
new lang/gcc-aux compiler, but lang/gcc-aux will remain as a standalone
package as it is the only GCC 4.6-based compiler that builds on
DragonFly and serves it as a world and kernel compile option.
In addition to the current language wrappers, lang/gcc-aux adds
wrappers for "ada" (unique to gcc-aux, hardlinked to gcc driver),
and the gnat, gnatmake, gnatbind, gnatlink, gnatchop, gnatprep,
and gnatls programs. Supporting all of these allows the wrapper
system to be used with Ada packages; currently wrappers are mostly
disabled on them.
The lang/gcc47 implicitly adds support for the "objc-c++" language by
adding it to the USE_LANGUAGES list, but it wasn't really supported.
An attempt was made to better support objc-c++, but this new enumeration
probably still needs work or needs to be removed completely.
Logic for Ada support:
1) All lang/gccXX compilers have version numbers ranging from 2.8.1 to 9.
2) lang/gcc-aux uses the release date as its version number in the form of
YYYYMMDD with a minimum value of 20120614, so there is no version
overlap.
3) When at least one element of USE_LANGUAGES is "ada", the value of
20120614 is added to the set of GCC_REQD which selects lang/gcc-aux.
4) The _NEED_NEWER_GCC check is disabled. It fails and isn't relevant;
unless a package sets GCC_REQD over 20120614, the only way to select
lang/gcc-aux is to specify the Ada language and only one compiler
known to gcc.mk can support it.
- Use PGKSRC-WARNING to note it's coming from pkgsrc and not always fatal.
- Describe more precisely what's happening when you get this warning.
Hopefuly this will stop the misundersanding of the error message I could
see quite often amongst users.
I bet 'c99' support in USE_LANGUAGES was only tested on -current. On -current
there is no g77 command so mk/compiler/gcc.mk includes mk/compiler/f2c.mk which
adds 'c' to USE_LANGUAGES ;)
package said USE_LANGUAGES=#none or USE_LANGUAGES=fortran. Added a
c-fail-wrapper that works like the other fail-wrappers. The default
value for USE_LANGUAGES is still "c". Some problems are expected with
packages that say USE_LANGUAGES+=c++ or with packages containing GNU
configure scripts and setting USE_LANGUAGES=c++, as those scripts always
need a working C compiler.
are generated for a target and output them all at once at the conclusion
of the target's invocation. The implementation is in bsd.pkg.error.mk,
which defines a macro target "error-check" that will print out any
non-empty warning and error files in ${WARNING_DIR} and ${ERROR_DIR}
and exit appropriately if there were errors.
Convert some targets that were just long sequences of ${ERROR_MSG} or
${WARNING_MSG} within a single shell statement to use the new delayed
error output via error-check.
Modify the compiler "fail" wrappers for C++ and Fortran to be less
verbose during invocation. Instead collect the warnings and only
print them at the end of the completed phase, e.g. after "configure"
and/or "build" completes.
Makefile, which means it occurs before bsd.tools.mk is included and
thus misses the definition of TOOLS_DIR. We now create a new subdirectory
of ${WRKDIR} to house the wrappers instead of re-using ${TOOLS_DIR}.
Problem noted by Roland Illig on tech-pkg:
http://mail-index.netbsd.org/tech-pkg/2006/05/12/0011.html
