clang-specific or gcc-specific flags, introduce the following new
variables for use in Makefiles:
CFLAGS.clang
CFLAGS.gcc
CXXFLAGS.clang
CXXFLAGS.gcc
In bsd.sys.mk, these get appended to the regular CFLAGS or CXXFLAGS for
the right compiler.
MFC after: 1 week
errors when you enable WITH_GNUCXX to build libstdc++, since it will
include C++ headers from the libc++ installation under ${WORLDTMP}, and
those are not compatible with libstdc++ at all.
To fix this, add -stdlib=libstdc++ to CXXFLAGS when building libstdc++
(and its companion libsupc++) with clang.
Approved by: re (delphij)
ARM EABI support is disabled by default and can be enabled by setting
WITH_ARM_EABI when building, however only the kernel-toolchain target will
work with this flag until the rest of the support is added.
-std= flags above c++98 or gnu++98 from CXXFLAGS *after* including
bsd.lib.mk, otherwise some additions to CXXFLAGS done in bsd.*.mk might
not be preserved.
MFC after: 1 week
option from CXXFLAGS, otherwise these libraries will not build.
Similarly, filter out any -std=xxx options that aren't supported.
Submitted by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>
MFC after: 2 weeks
to be gcc's default before r198344, calls to atomic builtins will not be
expanded inline. Instead, they will be generated as calls to external
functions (e.g. __sync_fetch_and_add_N), leading to linking errors later
on.
Put in a seatbelt that disables use of atomic builtins in libstdc++ and
llvm, when tuning specifically for the real i386 CPU. This does not
protect against all possible issues, but it is better than nothing.
Because FreeBSD no longer supports the 80386 cpu all code targeting
FreeBSD/i386 necessarily runs on i486 or higher so the compiler
built-ins can be used by default inside libstdc++ and in C++ headers.
This allows newly compiled C++ code to inline some atomic operations.
Old binaries continue to use libstdc++ functions.
PR: 148926
Tested by: Yuri Karaban <tech askold net>
Reviewed by: kan
Approved by: kib (mentor)
MFC after: 2 weeks
Also:
Switch FreeBSD to use libgcc_s.so.1.
Use dl_iterate_phdr to locate shared objects' exception frame
info instead of depending on older register_frame_info machinery.
This allows us to avoid depending on libgcc_s.so.1 in binaries
that do not use exception handling directly. As an additional
benefit it breaks circular libc <=> libgcc_s.so.1 dependency too.
Build newly added libgomp.so.1 library, the runtime support
bits for OpenMP.
Build LGPLed libssp library. Our libc provides our own
BSD-licensed SSP callbacks implementation, so this library
is only built to benefit applications that have hadcoded
knowledge of libssp.so and libssp_nonshared.a. When linked
in from command line, these libraries override libc
implementation.
library. As the value suggests, this allows the library to be built repeatably;
without this flag, gcc uses a random value in its parsing.
Since the random seed is only used when handling files which do not have any
externally-visible symbols, this change is not needed for any other libraries
in the FreeBSD base system.
Discussed on: freebsd-arch (in early November)
Approved by: kan
MFC after: 1 week
shared library being built for amd64. The problem is that libstdc++.so
is produced with 'cc -shared'. This has an internal -lgcc, which is
not PIC. libstdc++.so uses exceptions and the dwarf2 unwinder, which
are in libgcc.a. As a result, non-PIC code gets pulled into libstdc++.so.
This is fatal on amd64 when certain relocation types cannot be used in
PIC mode. The official FSF solution to this is to have libgcc.so with
internal ELF symbol versioning to solve the ABI problem, but I dont want
to fight that battle yet. I tried making libgcc_pic.a (which worked
fine), but thats not something for the 11th hour before a release.
Approved by: re (amd64 "safe" stuff)
not to blindly undef isnan() and other functions that became macros in C99.
Enable use of newly grown C99 functions: strtof(), strtold(), wcstof()
Submitted by: das
