some existing COMPILER lines with arch restrictions etc. In the usual
case this is now using "COMPILER = base-clang ports-gcc base-gcc" on
ports with c++ libraries in WANTLIB.
This is basically intended to be a noop on architectures using clang
as the system compiler, but help with other architectures where we
currently have many ports knocked out due to building with an unsuitable
compiler -
- some ports require c++11/newer so the GCC version in base that is used
on these archirtectures is too old.
- some ports have conflicts where an executable is built with one compiler
(e.g. gcc from base) but a library dependency is built with a different
one (e.g. gcc from ports), resulted in mixing incompatible libraries in the
same address space.
devel/gmp is intentionally skipped as it's on the path to building gcc -
the c++ library there is unused in ports (and not built by default upstream)
so intending to disable building gmpcxx in a future commit.
a separate file rather than directly in icudata.so to avoid the symbol
size warnings from ld.so.
As this data file is needed at runtime, provide a subpackage containing
a second copy installed under /var/www for use with chrooted web
applications (notably php-intl) that use icu4c. (Applications using
chroot jails other than /var/www will need a further copy of the data
file).
Feedback/ok ajacoutot@, bumps to follow.
patch that triggered the symbol(icudt58_dat) size mismatch warning...
We can now use --with-data-packaging=archive only on powerpc and arm which means
using php-intl or anything linked to icu in a chroot will work.
* as per upstream recommendation
- use --with-data-packaging=archive on all archs
- pass -DICU_NO_USER_DATA_OVERRIDE
- pass --disable-renaming (fixes the infamous symbol mismatch)
* don't duplicate libicutest installation
* don't strip static libraries (from FreeBSD)
* when not in POSIX/C mode, assume UTF-8 by default like Darwin (from FreeBSD)
* sync config/mh-bsd-gcc with config/mh-linux
* build extra tool
* remove uneeded patches / chunks
* bump major
Big thanks to miod@ for tracking down the area in which the problem lies
and suggesting this workaround.
Unbreaks a big chunk of the ports tree on arm.
