--- Log opened Mon Oct 18 00:00:58 2010 00:37 -!- sajack [~khezef@rrdhcp144-122.redrover.cornell.edu] has quit [Ping timeout: 240 seconds] 02:52 -!- sajack [~khezef@rrdhcp146-285.redrover.cornell.edu] has joined #t2 04:57 -!- cb88 [~cb88@244.charlotte-04rh15-16rt.nc.dial-access.att.net] has joined #t2 05:35 < cb88> been trying to build sparc32 not getting very far though... there do seem to be some incorrect options passed to the gcc configure 05:41 < cb88> or I'm probably mising something ... ;-) 06:12 -!- sajack [~khezef@rrdhcp146-285.redrover.cornell.edu] has quit [Ping timeout: 250 seconds] 07:06 -!- cb88 [~cb88@244.charlotte-04rh15-16rt.nc.dial-access.att.net] has quit [Ping timeout: 252 seconds] 07:07 -!- sajack [~khezef@rrdhcp146-285.redrover.cornell.edu] has joined #t2 09:04 -!- sajack [~khezef@rrdhcp146-285.redrover.cornell.edu] has quit [Ping timeout: 272 seconds] 10:40 -!- mjungwirth [~mjungwirt@213.174.234.68] has quit [Quit: Nettalk6 - www.ntalk.de] 10:43 -!- mjungwirth [~mjungwirt@213.174.234.68] has joined #t2 12:30 < rogermason> hello. 12:35 < rogermason> rxr: regarding root, it _is_ rootcint_tmp that fails:Program received signal SIGSEGV, Segmentation fault. 12:35 < rogermason> 0x00000000101b6a3c in .G__tovalue () 12:37 < rogermason> gdb does not identify the file or line, but G__tovalue() is defined in cint/cint/src/value.cxx, which (I think) contains some assembler macros. 12:43 < rxr> there is no PPC assembly, though 12:45 < CIA-27> rene * r37842 /trunk/package/network/bluez/bluez.desc: * updated bluez (4.75 -> 4.76) 12:49 < rxr> you do use root actively? 12:49 < rxr> have you continued to chat with the root dev's about this? 12:54 < rogermason> yes, I use root almost exclusively for data processing. I have not had further discussuion with the root devs after their statement about not supporting 64 bit compilation on ppc. 13:06 < rxr> well, I do not know much about root 13:07 < rxr> the developers may (should) se some offender at a glance, ... 13:07 < rxr> Program received signal SIGSEGV, Segmentation fault. 13:07 < rxr> G__tovalue (p=...) at cint/cint/src/value.cxx:413 13:07 < rxr> 413 result.obj.in = (*(int *)(p.obj.i)); 13:07 < rxr> (gdb) p result 13:07 < rxr> $1 = 13:07 < rxr> (gdb) p p 13:07 < rxr> $2 = {obj = {d = 0, i = 0, reftype = {i = 0, reftype = 0}, ch = 0 '\000', sh = 0, in = 0, fl = 0, uch = 0 '\000', ush = 0, uin = 0, ulo = 0, ll = 0, ull = 0, ld = 0}, 13:07 < rxr> ref = 0, type = 73, tagnum = -1, typenum = -1, isconst = 0 '\000', dummyForCint7 = {fTypeName = 0x0, fModifiers = 0}} 13:07 < rxr> (gdb) p p.obj 13:07 < rxr> $3 = {d = 0, i = 0, reftype = {i = 0, reftype = 0}, ch = 0 '\000', sh = 0, in = 0, fl = 0, uch = 0 '\000', ush = 0, uin = 0, ulo = 0, ll = 0, ull = 0, ld = 0} 13:07 < rxr> (gdb) p p.obj.i 13:07 < rxr> $4 = 0 13:10 < rogermason> rxr: thank you. I will pass this back to them. How did tou get gdb to give you a line number? 13:11 < rxr> I run the line from the log in gdb 13:11 < rxr> gdb core/utils/src/rootcint_tmp 13:11 < rxr> r -cint -f ... ... 13:11 < rxr> r for "ruN" 13:13 < rogermason> OK. I used gdb --args core/utils/src/rootcint_tmp -cint -f ... 13:14 < rogermason> then run. That did not specify where the segfault happened. 13:14 < rxr> oh 13:14 < rxr> I switch on the CONFIG_DEBUG in the t2 config so that all binaries are built with debug symbols :-) 13:16 < rogermason> Ah. Yes, gdb told me that there were no debug symbols. Silly me. I'll do likewise. 13:28 < rxr> :-) 13:28 < rxr> lunch 14:34 < rxr> cu 14:34 < rxr> err re 15:04 < rogermason> This is what the root guys have to say: yes, I know *why* it's failing. That's precisely the reason why we can 15:04 < rogermason> clearly state: not supported :-) CINT has an assumption on endianess, 15:04 < rogermason> and works around it for 32 bit by using int and long as interchangeable 15:04 < rogermason> types. On 64 bit that's not the case, and CINT uses the "wrong part" of 15:04 < rogermason> the byte group. Changing that would be major surgery that we much prefer 15:04 < rogermason> investing in replacing CINT altogether. 15:06 < rxr> don't see how they work around endianess issues with long and int, .. 15:10 < rogermason> Me neither. I did once write some byte-swapping code, but it is so long ago that I don't even remember why it was needed. 15:12 < rogermason> I know that CINT (a C/C++ interpreter is going to be replaced at some point by something (CLING? CLANG) derived from llvm, so I understand their point of view. 15:23 < rxr> well the byte swapping is trivial 15:24 < rxr> I even have my own C++ templates in my projects that do so automatically based on specified in-memory order, like native, big- or little-endian 15:25 < rxr> the only way I can imageine right now is that they add some template glue and miss-use the long type to have some conversion function match those assignments, ... 15:25 < rxr> the question is how pervasive their use is, if that is the only thing root is missing on ppc64 then we may even able to patch it up 15:25 < rxr> if the next, other issue is just lingering ahead then it may not worth to even look at it, .. 15:26 < rxr> and just build 32bit userland for your root use, .. 15:32 < rogermason> I get the sense from the devs that no help will be forthcoming, so patching may not be the best option. 17:21 -!- mqueiros_ [~mqueiros@a83-132-0-130.cpe.netcabo.pt] has quit [Quit: Ex-Chat] 21:53 -!- old_gaffer [~quassel@211.238.240.87] has quit [Quit: No Ping reply in 180 seconds.] 21:59 -!- gluemonkey [~gluemonke@67.137.235.168] has joined #t2 --- Log closed Tue Oct 19 00:00:58 2010