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.
in struct _machdep_state from libpthread.
The offset is hardcoded in boehm-gc because it's a private struct so we
cannot use offsetof(). This will probably not change soon again but I am
writing this as a note for people who will run into the same problem in
the future.
All the regression tests are passing now and mono builds fine too.
Thanks to kurt@ for pointers.
The latter contains libatomic_ops-1.2, which is developed inside boehm-gc,
as stated on libatomic_ops homepage. No change on -main subpackage.
libatomic_ops may be used by a future eventual pulseaudio port, which is
being worked on.
Feedback, tweaks and ok kurt@
and adjust boehm-gc to deal with any number of holes that may appear
between __data_start and _end. (requires -current binutils)
- work-around libpthread bugs that prevent sigsuspend() from working
in a signal handler by using pthread_suspend_np() + an arch/libpthread
specific offset to obtain the suspended thread's stack pointer.
thanks to sthen@ and jasper@ for access to other arches. discussed
with todd@
Most work done by kurt@, who got bleeding eyes and has been trapped
into pthread issues because some of us (me and Stuart Henderson)
were slopyy and applied some patches only partial. A big sorry to
kurt@ for this waste of time!
Tested by many. Intermediate ok's (IIRC) from kurt@, naddy@ and todd@.
