powerpc64 10.1-STABLE [WITH_DEBUG] context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it
Mark Millard
markmi at dsl-only.net
Wed Mar 18 06:49:08 UTC 2015
Looks like I forgot to forward Brad King's 2015-Mar-11 note that KWSys and CMake have the "static" fix that allows non-inlining debug builds of ctest and other programs to handle the TOC register usage appropriately:
> The change is now in KWSys 'master' and I've updated
> the copy within CMake:
>
> KWSys 2015-03-10 (4a698414)
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a427f86
>
> Merge branch 'upstream-kwsys' into update-kwsys
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e433223d
>
> -Brad
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-10, at 01:11 PM, Mark Millard <markmi at dsl-only.net> wrote:
Brad King is adding the missing static to _stl_next_prime in KWSys and from there it will eventually propagate into CMake's code base. Actually in KWSys both static's are to be added. ( http://review.source.kitware.com/#/c/19465/ )
Brad wrote that CMake's code base had added the static to _get_stl_prime_list to handle a linking problem in some environment. (Despite not knowing of KWSys I had guessed that there was some reason why that static was there: that is why I suggested the direction of making _stl_next_prime match instead of suggesting removing the static on _get_stl_prime_list.) Once propagated the updates will make KWSys and CMake's code again match in this area.
So eventually FreeBSD should pick up a fix that should allow WITH_DEBUG= to be better behaved for CMake's programs that use it's hashtable.hxx .
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-9, at 08:09 AM, Mark Millard <markmi at dsl-only.net> wrote:
I've discovered why/how WITH_DEBUG= ends up with cmake's /usr/local/bin/ctest messed up for PIC code generation (powerpc64 context). A source code fix that avoids the problem is likely to change cmake's hashtable.hxx that has
inline size_t _stl_next_prime(size_t __n)
{
const unsigned long* __first = get_stl_prime_list();
const unsigned long* __last = get_stl_prime_list() + (int)_stl_num_primes;
const unsigned long* pos = cmsys_stl::lower_bound(__first, __last, __n);
return pos == __last ? *(__last - 1) : *pos;
}
to also indicate static for it like the .hxx file has for
static inline const unsigned long* get_stl_prime_list() {
static const unsigned long _stl_prime_list[_stl_num_primes] =
{
5ul, 11ul, 23ul,
53ul, 97ul, 193ul, 389ul, 769ul,
1543ul, 3079ul, 6151ul, 12289ul, 24593ul,
49157ul, 98317ul, 196613ul, 393241ul, 786433ul,
1572869ul, 3145739ul, 6291469ul, 12582917ul, 25165843ul,
50331653ul, 100663319ul, 201326611ul, 402653189ul, 805306457ul,
1610612741ul, 3221225473ul, 4294967291ul
};
return &_stl_prime_list[0]; }
NOTE: _stl_next_prime has the only calls to _get_stl_prime_list that exist in the source code.
The details for what is going on follow...
There are 7 instances of get_stl_prime_list's code in my /usr/local/bin/ctest, each with differing %r2 offsets for differing %r2 values to allow finding appropriate _stl_prime_list addresses in various places that include the header file. Each code instance from my build's /usr/local/bin/ctest is shown below. (Note that the ._ZN5cmsysL18get_stl_prime_listEv name does not vary despite the distinct addresses.)
But there is only 1 instance of _stl_next_prime's code in /usr/local/bin/ctest, also shown below. This routine directly calls the first of the ._ZN5cmsysL18get_stl_prime_listEv routines below, effectively forcing the %r2 offset from that code to always be used --and so generating garbage addresses for 6 of the 7 static contexts.
6 of the ._ZN5cmsysL18get_stl_prime_listEv's are completely unused.
But most of the initial usage of _stl_next_prime in execution order happens to have the %r2 value that goes with the first ._ZN5cmsysL18get_stl_prime_listEv routine. That is why /usr/local/bin/ctest dies as late as it does.
I have observed the indicated behavior leading up to the crash under gdb as well.
00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1)
00000000101751c4 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu r1,-64(r1)
00000000101751c8 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1
00000000101751cc <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld r0,-2976(r2)
00000000101751d0 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0
00000000101751d4 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld r1,0(r1)
00000000101751d8 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld r31,-8(r1)
00000000101751dc <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
00000000101751e0 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
00000000101751e4 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
00000000101751e8 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz r0,1(r1)
000000001017c028 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1)
000000001017c02c <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu r1,-64(r1)
000000001017c030 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1
000000001017c034 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld r0,-2720(r2)
000000001017c038 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0
000000001017c03c <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld r1,0(r1)
000000001017c040 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld r31,-8(r1)
000000001017c044 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
000000001017c048 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
000000001017c04c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
000000001017c050 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz r0,1(r1)
00000000101f4ae8 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1)
00000000101f4aec <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu r1,-64(r1)
00000000101f4af0 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1
00000000101f4af4 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld r0,2088(r2)
00000000101f4af8 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0
00000000101f4afc <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld r1,0(r1)
00000000101f4b00 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld r31,-8(r1)
00000000101f4b04 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
00000000101f4b08 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
00000000101f4b0c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
00000000101f4b10 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz r0,1(r1)
000000001029161c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1)
0000000010291620 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu r1,-64(r1)
0000000010291624 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1
0000000010291628 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld r0,11344(r2)
000000001029162c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0
0000000010291630 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld r1,0(r1)
0000000010291634 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld r31,-8(r1)
0000000010291638 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
000000001029163c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
0000000010291640 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
0000000010291644 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz r0,1(r1)
00000000103cde60 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1)
00000000103cde64 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu r1,-64(r1)
00000000103cde68 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1
00000000103cde6c <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld r0,-32728(r2)
00000000103cde70 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0
00000000103cde74 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld r1,0(r1)
00000000103cde78 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld r31,-8(r1)
00000000103cde7c <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
00000000103cde80 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
00000000103cde84 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
00000000103cde88 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz r0,1(r1)
000000001041bf4c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1)
000000001041bf50 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu r1,-64(r1)
000000001041bf54 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1
000000001041bf58 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld r0,-26608(r2)
000000001041bf5c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0
000000001041bf60 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld r1,0(r1)
000000001041bf64 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld r31,-8(r1)
000000001041bf68 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
000000001041bf6c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
000000001041bf70 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
000000001041bf74 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz r0,1(r1)
00000000104719ec <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1)
00000000104719f0 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu r1,-64(r1)
00000000104719f4 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1
00000000104719f8 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld r0,-21280(r2)
00000000104719fc <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0
0000000010471a00 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld r1,0(r1)
0000000010471a04 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld r31,-8(r1)
0000000010471a08 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
0000000010471a0c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
0000000010471a10 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000
0000000010471a14 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz r0,1(r1)
And here is the only _stl_next_prime routine:
0000000010176174 <._ZN5cmsys15_stl_next_primeEm> mflr r0
0000000010176178 <._ZN5cmsys15_stl_next_primeEm+0x4> std r31,-8(r1)
000000001017617c <._ZN5cmsys15_stl_next_primeEm+0x8> std r0,16(r1)
0000000010176180 <._ZN5cmsys15_stl_next_primeEm+0xc> stdu r1,-176(r1)
0000000010176184 <._ZN5cmsys15_stl_next_primeEm+0x10> mr r31,r1
0000000010176188 <._ZN5cmsys15_stl_next_primeEm+0x14> std r3,224(r31)
000000001017618c <._ZN5cmsys15_stl_next_primeEm+0x18> bl 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv>
0000000010176190 <._ZN5cmsys15_stl_next_primeEm+0x1c> mr r0,r3
0000000010176194 <._ZN5cmsys15_stl_next_primeEm+0x20> std r0,128(r31)
0000000010176198 <._ZN5cmsys15_stl_next_primeEm+0x24> bl 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv>
000000001017619c <._ZN5cmsys15_stl_next_primeEm+0x28> mr r9,r3
00000000101761a0 <._ZN5cmsys15_stl_next_primeEm+0x2c> addi r0,r9,248
00000000101761a4 <._ZN5cmsys15_stl_next_primeEm+0x30> std r0,120(r31)
00000000101761a8 <._ZN5cmsys15_stl_next_primeEm+0x34> ld r3,128(r31)
00000000101761ac <._ZN5cmsys15_stl_next_primeEm+0x38> ld r4,120(r31)
00000000101761b0 <._ZN5cmsys15_stl_next_primeEm+0x3c> addi r0,r31,224
00000000101761b4 <._ZN5cmsys15_stl_next_primeEm+0x40> mr r5,r0
00000000101761b8 <._ZN5cmsys15_stl_next_primeEm+0x44> bl 0000000010176090 <._ZSt11lower_boundIPKmmET_S2_S2_RKT0_>
00000000101761bc <._ZN5cmsys15_stl_next_primeEm+0x48> crmove 4*cr7+so,4*cr7+so
00000000101761c0 <._ZN5cmsys15_stl_next_primeEm+0x4c> mr r0,r3
00000000101761c4 <._ZN5cmsys15_stl_next_primeEm+0x50> std r0,112(r31)
00000000101761c8 <._ZN5cmsys15_stl_next_primeEm+0x54> ld r9,112(r31)
00000000101761cc <._ZN5cmsys15_stl_next_primeEm+0x58> ld r0,120(r31)
00000000101761d0 <._ZN5cmsys15_stl_next_primeEm+0x5c> cmpd cr7,r9,r0
00000000101761d4 <._ZN5cmsys15_stl_next_primeEm+0x60> bne- cr7,00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78>
00000000101761d8 <._ZN5cmsys15_stl_next_primeEm+0x64> ld r9,120(r31)
00000000101761dc <._ZN5cmsys15_stl_next_primeEm+0x68> addi r9,r9,-8
00000000101761e0 <._ZN5cmsys15_stl_next_primeEm+0x6c> ld r9,0(r9)
00000000101761e4 <._ZN5cmsys15_stl_next_primeEm+0x70> std r9,144(r31)
00000000101761e8 <._ZN5cmsys15_stl_next_primeEm+0x74> b 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84>
00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> ld r9,112(r31)
00000000101761f0 <._ZN5cmsys15_stl_next_primeEm+0x7c> ld r9,0(r9)
00000000101761f4 <._ZN5cmsys15_stl_next_primeEm+0x80> std r9,144(r31)
00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> ld r0,144(r31)
00000000101761fc <._ZN5cmsys15_stl_next_primeEm+0x88> mr r3,r0
0000000010176200 <._ZN5cmsys15_stl_next_primeEm+0x8c> ld r1,0(r1)
0000000010176204 <._ZN5cmsys15_stl_next_primeEm+0x90> ld r0,16(r1)
0000000010176208 <._ZN5cmsys15_stl_next_primeEm+0x94> mtlr r0
000000001017620c <._ZN5cmsys15_stl_next_primeEm+0x98> ld r31,-8(r1)
0000000010176210 <._ZN5cmsys15_stl_next_primeEm+0x9c> blr
0000000010176214 <._ZN5cmsys15_stl_next_primeEm+0xa0> .long 0x0
0000000010176218 <._ZN5cmsys15_stl_next_primeEm+0xa4> .long 0x90001
000000001017621c <._ZN5cmsys15_stl_next_primeEm+0xa8> lwz r0,1(r1)
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-8, at 06:35 PM, Mark Millard <markmi at dsl-only.net> wrote:
Thanks for the note. It is useful to know the variation from my context.
You were not explicit but because you mention POWER8 I'd guess that you were reporting based on 11.0-CURRENT. I have not yet established an 11.0-CURRENT boot-context, although I plan to at some point.
powerpc64 vs. powerpc builds give different results...
For powerpc64 I decided to "pkg delete '*'", check /usr/local/... and /var/db/pkg/..., and start a rebuild of all my ports to see what happens. For powerpc I'm just establishing a boot-SSD context now.
The activity for both has gotten past cmake and I get the following results for ctest on the G5s where the builds are running:
powerpc64 build: ctest still messed up with std::length_error from vector::reserve.
powerpc build: ctest works fine.
Both are being run on PowerMac G5s. Both are still building more ports.
As for potential HW problems and HW configuration problems:
I have access to 3 PowerMac G5's and they all behaved the same for each specific build:
PowerMac11,2 (Quad-Core) G5 with 16GBytes ECC RAM
PowerMac11,2 (Quad-Core) G5 with 12GBytes RAM
PowerMac7,2 (Dual-processor) G5 with 8GBytes RAM
All of these have only one board installed: the video board. Normally there is only one "disk" present when in use: a boot SSD on ada0.
The only common HW element in my testing G5 behavior is my moving my boot SSD that I'm testing.
Non-SSD hardware is rarely the issue with anything that I report unless I'm reporting differences in behavior between the PowerMacs that I have access to for the type of build involved: I have a compare/contrast environment available for my testing and I use it.
[I have access to multiple G4 PowerMacs of various vintages and a G3 PowerMac as well, similarly minimal configurations. But I'm only now re-establishing having a FreeBSD context for these after mostly abandoning them for much of the 9-10 months while I was investigating the frequent PowerMac G5 early-boot-crash problems as my primary FreeBSD activity.]
The powerpc64 PowerMac G5 boot-SSD content that I use for 10.1-STABLE and 10.1-RELENG could certainly be suspect in some way. :) I mostly use 10.1-STABLE, currently:
$ freebsd-version -ku; uname -a
10.1-STABLE
10.1-STABLE
FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 23:08:59 PST 2015 root at FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc powerpc
As for other configuration points:
See my original note for more details on the difference from the official world/kernel materials. There is also /boot/loader.conf picking out a kernel (I use INSTKERNNAME= with non-default names mostly) and picking out vt vs. sc, /etc/fstab, /etc/rc.conf (hostname, ifconfig_<?> for ethernet, ntpd_<?>, dumpdev, hald_enable, dbus_enable), /etc/sysctl.conf for /var/crash/ related items. Counting the original note's list of differences: Not much else is different from the default/official materials.
For ports configurations: Before I had suspended trying to track the ports status I historically had used almost every default selection, something like 2 to 6 non-default selections. (I keep a snapshot of /var/db/ports/... as a reference/reminder.) I've got the same policy for trying to re-establish the ports now that I can reliably boot the G5s.
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:
This works fine for me. Are you sure you don't have some weird configuration or hardware problem?
-Nathan
On 03/07/15 22:56, Mark Millard wrote:
> powerpc64 context (more details are listed much later):
>
> $ freebsd-version -ku; uname -a
> 10.1-STABLE
> 10.1-STABLE
> FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 23:08:59 PST 2015 root at FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc powerpc
>
> Ports Revision 380683 via svnlite update. I've been using portmaster.
>
>
> The problem (which I've not figured out yet)...
>
> When png-1.6.16 has PNGTEST enabled (default and "recommended") it tries to use cmake's /usr/local/bin/ctest. But in my context ctest is broken, trying to reserve 2305843009213693952 Hashtable_node<...>*'s [see #8's ...::reserve (..., __n=...) below] when _M_initialize_buckets(..., __n=100) in #9. (Note: 2305843009213693952 == 0x2000000000000000.) I have yet to figure out how that magic number is becoming involved. See below from one of the crash dumps:
>
> #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7
> [New Thread 51c06400 (LWP 100091/ctest)]
> (gdb) bt
> #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7
> #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7
> #2 0x0000000050d15788 in .abort () from /lib/libc.so.7
> #3 0x00000000514c9ae0 in ._ZN9__gnu_cxx27__verbose_terminate_handlerEv () from /usr/lib/libsupc++.so.1
> #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from /usr/lib/libsupc++.so.1
> #5 0x00000000514cf230 in ._ZSt9terminatev () from /usr/lib/libsupc++.so.1
> #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1
> #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from /usr/lib/libstdc++.so.6
> #8 0x000000001024659c in std::vector<cmsys::_Hashtable_node<std::pair<std::string const, cmDefinitions::Def> >*, std::allocator<cmsys::_Hashtable_node<std::pair<std::string const, cmDefinitions::Def> >*> >::reserve (this=0xffffffffffffb108, __n=2305843009213693952) at vector.tcc:72
> #9 0x00000000104749bc in cmsys::hashtable<std::pair<std::string const, cmDefinitions::Def>, std::string, cmsys::hash<std::string>, cmsys::hash_select1st<std::string const, cmDefinitions::Def>, std::equal_to<std::string>, std::allocator<char> >::_M_initialize_buckets (this=0xffffffffffffb100, __n=100) at hashtable.hxx:797
> #10 0x0000000010474ae4 in hashtable (this=0xffffffffffffb100, __n=100, __hf=@0xffffffffffffaeb2, __eql=@0xffffffffffffaeb1, __a=@0xffffffffffffaeb0) at hashtable.hxx:545
> #11 0x0000000010474bb8 in hash_map (this=0xffffffffffffb100) at hash_map.hxx:113
> #12 0x0000000010472ba4 in cmDefinitions (this=0xffffffffffffb0f8, parent=0x0) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinitions.cxx:19
> #13 0x000000001020dc40 in cmMakefile (this=0x51cb1800) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefile.cxx:56
> #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator (this=0x51c3f480, gg=0xffffffffffffc138) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGenerator.cxx:244
> #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator (this=0xffffffffffffc138) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalGenerator.cxx:1906
> #16 0x00000000100224dc in cmCTest::Initialize (this=0xffffffffffffcf50, binary_dir=0x51c890f8 "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", command=0x0)
> at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.cxx:511
> #17 0x000000001002c704 in cmCTest::Run (this=0xffffffffffffcf50, args=@0xffffffffffffcb80, output=0xffffffffffffcb98) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.cxx:2474
> #18 0x0000000010010c10 in main (argc=2, argv=0x51c1a040) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx:189
> #19 0x000000001000fc9c in ._start ()
> #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1
>
> The specific Makefile code to invoke ctest is...
>
> # Special rule for the target test
> test:
> @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan "Running tests..."
> /usr/local/bin/ctest --force-new-ctest-process $(ARGS)
> .PHONY : test
> # Special rule for the target test
> test/fast: test
> .PHONY : test/fast
>
> which because of ctest's problem leads to...
>
> ...
> Linking C executable pngvalid
> [100%] Built target pngvalid
> (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! /usr/bin/env XDG_DATA_HOME=/usr/obj/portswork/usr/ports/graphics/png/work XDG_CONFIG_HOME=/usr/obj/portswork/usr/ports/graphics/png/work HOME=/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR="/tmp" XDG_DATA_HOME=/usr/obj/portswork/usr/ports/graphics/png/work XDG_CONFIG_HOME=/usr/obj/portswork/usr/ports/graphics/png/work HOME=/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR="/tmp" DONTSTRIP=yes NO_PIE=yes SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local LIBDIR="/usr/lib" CC="cc" CFLAGS="-pipe -g -fno-strict-aliasing" CPP="cpp" CPPFLAGS="" LDFLAGS="" LIBS="" CXX="c++" CXXFLAGS="-pipe -g -fno-strict-aliasing " MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -o root -g wheel -m 555" BSD_INSTALL_LIB="install -o root -g wheel -m 444" BSD_INSTALL_SCRIPT="install -o root -g wheel -m 555" BSD_INSTALL_DATA="install -o root -g wheel -m 0644" BSD_INSTALL_MAN="instal!
> l -o roo
> t -g wheel -m 444" /usr/bin/make -f Makefile -j4 DESTDIR=/usr/obj/portswork/usr/ports/graphics/png/work/stage test; then if [ x != xTry to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. ] ; then echo "===> Compilation failed unexpectedly."; (echo Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi)
> Running tests...
> terminate called after throwing an instance of 'std::length_error'
> what(): vector::reserve
> Abort trap (core dumped)
> *** [test] Error code 134
>
> make[2]: stopped in /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16
> 1 error
>
> make[2]: stopped in /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16
> [: xTry: unexpected operator
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/graphics/png
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/graphics/png
>
>
> Even just ctest as a command gets the vector::reserve size problem from the large magic number:
>
> $ ctest
> *********************************
> No test configuration file found!
> *********************************
> terminate called after throwing an instance of 'std::length_error'
> what(): vector::reserve
> Abort trap (core dumped)
>
>
> [So far I've only sidestepped having graphic/png run ctest to allow some things that depend on graphics/png to not be blocked by this.]
>
>
>
>
> For my context the overall environment has (but ports might force other ports as alternatives to):
>
> # more /etc/make.conf
> #CPP=clang-cpp
> #CC=clang
> #CXX=clang++
> WRKDIRPREFIX=/usr/obj/portswork
> WITH_DEBUG=
> MALLOC_PRODUCTION=
>
> # more /etc/src.conf
> #CPP=clang-cpp
> #CC=clang
> #CXX=clang++
> #CFLAGS+=-DELF_VERBOSE
> #WITH_DEBUG_FILES=
> #WITHOUT_CLANG=
>
> # which cc
> /usr/bin/cc
>
> # cc --version
> cc (GCC) 4.2.1 20070831 patched [FreeBSD]
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> # which clang
> /usr/bin/clang
>
> # clang --version
> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
> Target: powerpc64-unknown-freebsd10.1
> Thread model: posix
>
>
>
>
>
> Other context details:
>
> $ cd /usr/ports
> $ svnlite info
> Path: .
> Working Copy Root Path: /usr/ports
> URL: https://svn0.us-west.freebsd.org/ports/head
> Relative URL: ^/head
> Repository Root: https://svn0.us-west.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 380683
> Node Kind: directory
> Schedule: normal
> Last Changed Author: demon
> Last Changed Rev: 380683
> Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015)
>
> $ svnlite st --no-ignore
> ? .snap
> I distfiles
> M graphics/libGL/bsd.mesalib.mk
> I packages
> ? restoresymtable
>
> $ svnlite diff graphics/libGL/bsd.mesalib.mk
> Index: graphics/libGL/bsd.mesalib.mk
> ===================================================================
> --- graphics/libGL/bsd.mesalib.mk (revision 380683)
> +++ graphics/libGL/bsd.mesalib.mk (working copy)
> @@ -136,6 +136,10 @@
> CONFIGURE_ARGS+=--enable-vdpau
> .endif
>
> +.if ${ARCH} == powerpc64
> +CFLAGS+= -mminimal-toc
> +.endif
> +
> post-patch:
> @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e 's|x86_64|amd64|' \
> ${WRKSRC}/configure
>
> $ cd /usr/src
> $ svnlite info
> Path: .
> Working Copy Root Path: /usr/src
> URL: https://svn0.us-west.freebsd.org/base/stable/10
> Relative URL: ^/stable/10
> Repository Root: https://svn0.us-west.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 279507
> Node Kind: directory
> Schedule: normal
> Last Changed Author: ngie
> Last Changed Rev: 279507
> Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015)
>
> $ svnlite st --no-ignore
> ? .snap
> ? restoresymtable
> M sys/ddb/db_main.c
> M sys/ddb/db_script.c
> I sys/powerpc/conf/GENERIC64vtsc
> I sys/powerpc/conf/GENERICvtsc
> M sys/powerpc/ofw/ofw_machdep.c
> M sys/powerpc/ofw/ofwcall64.S
> M sys/powerpc/powerpc/dump_machdep.c
>
> sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to avoid intermittent boot problems.
>
> sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get evidence if I do end up with another early-boot failure. DDB and GDB are listed in sys/powerpc/conf/GENERIC64vtsc for the same reason.
>
> sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer size for dumps to be small enough not to be rejected as too large of a DMA request size.
>
> sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both vt and sc. It includes the standard GENERIC64.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> _______________________________________________
> freebsd-ppc at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"
>
More information about the freebsd-ports
mailing list