| # 00:15:47 | plfiorini | quits : Quit: Leaving |
| # 01:15:39 | codyps | quits : Ping timeout: 240 seconds |
| # 02:45:07 | codyps | joins #crosstool-ng |
| # 05:02:38 | alan_o | quits : Quit: Leaving |
| # 07:42:37 | diorcety | quits : Read error: Connection reset by peer |
| # 07:43:51 | diorcety | joins #crosstool-ng |
| # 07:45:07 | diorcety | quits : Read error: Connection reset by peer |
| # 07:45:43 | diorcety | joins #crosstool-ng |
| # 08:22:45 | smartin | joins #crosstool-ng |
| # 08:33:00 | lazzer | joins #crosstool-ng |
| # 09:32:58 | Net147 | joins #crosstool-ng |
| # 09:36:00 | sh4rm4 | quits : Ping timeout: 276 seconds |
| # 09:38:54 | sh4rm4 | joins #crosstool-ng |
| # 11:16:05 | mingwandroid | joins #crosstool-ng |
| # 11:37:35 | mingwandroid | diorcety: hey! |
| # 11:45:28 | diorcety | quits : Quit: Leaving. |
| # 13:21:15 | Net147 | quits : Quit: HydraIRC -> http://www.hydrairc.com <- Like it? Visit #hydrairc on EFNet |
| # 15:12:43 | lazzer | Hi! I am trying to create a PPC32 toolchain and get an error: |
| # 15:12:45 | lazzer | cstdio:136:11: error: '::tmpnam' has not been declared |
| # 15:13:05 | lazzer | during the stage "building the final compiler, compiling GCC" |
| # 15:14:03 | lazzer | something anyone know something about? |
| # 16:07:37 | lazzer | seems like https://github.com/kraj/ct-scripts/commit/9a5c0237b6c5841c5593cd6abf5c796c54d8beec fixed the problem |
| # 16:14:54 | tkil | lazzer -- which host, and which ppc32 target? i am using ... dunno, probably 1.16, to generate toolchain for e300c3... |
| # 16:15:03 | tkil | on a x86_64 linux box as host. |
| # 16:16:06 | lazzer | tkil: it is x86_64 host, and e500 target |
| # 16:16:42 | tkil | ah, but you're using uclibc? i'm using eglibc... |
| # 16:16:57 | lazzer | tkil: Yes, it was an uClibc problem :D |
| # 16:17:11 | tkil | ah. did you get it fixed, then? |
| # 16:17:19 | lazzer | https://github.com/kraj/ct-scripts/commit/9a5c0237b6c5841c5593cd6abf5c796c54d8beec |
| # 16:17:31 | lazzer | those options, I had missed them in uClibc configuration |
| # 16:17:34 | tkil | oh, ok. was mislead by "seems like...". glad it's working for you. :) |
| # 16:17:38 | lazzer | :P |
| # 16:18:31 | lazzer | tkil: whould like to build with eglibc :( but it is to big, seems that uClibc cause a lot of problems :( |
| # 16:21:57 | tkil | i'm spoiled, my "embedded" platform is pretty beefy (think late 1990s ppc desktop -- 256MiB RAM, 1GiB NAND, etc.) |
| # 16:22:07 | tkil | so i'm not hurting for space... |
| # 16:31:52 | lazzer | tkil: oh, 64MiB Ram, 32MiB NOR flash here |
| # 17:11:44 | diorcety | joins #crosstool-ng |
| # 17:53:14 | plfiorini | joins #crosstool-ng |
| # 18:06:44 | tkil | stupid floating point. i'll search, but in case anyone knows offhand, should i get same results with 'float' math on x86_64 as on ppc32? or is there a different default rounding mode or something? |
| # 18:08:11 | imMute | tkil: you should get similar results, but I wouldn't be surprised if theye weren't *exactly* the same |
| # 18:09:46 | tkil | that's what i was suspecting. (and it's exactly that kind of issue -- ppc32 is giving me 0.0374273, x86-64 is giving me 0.0374268, difference of 5 in the last digit. so smells like fast-math.) |
| # 18:10:30 | tkil | and it's not important, i was just hoping to be able to do char-by-char comparisons to make sure i was unpacking my file correctly on the host (it's packed and unpacked on the target, which is the "reference implementation" of the file format). |
| # 18:10:54 | imMute | ~uh, why are you using floating point then? |
| # 18:11:53 | tkil | imMute -- convenience, i suppose. actual source sensor for that number only has 12 or 16 bits of precision *anyway*. right answer is probably do only significant bits. oh well, live and learn. |
| # 18:12:24 | imMute | why not just use a 16 bit int (uint16_t)? integer math is much faster than floating point math.. |
| # 18:13:08 | tkil | in this particular instrument, one of the focuses has been on making it more human-friendly. it's actually stored in raw 16-bit values; i'm converting it to engineering units (volts, in this case) for human consumption. |
| # 18:13:32 | tkil | previous instruments in this field have erred on the "keep it easy for the instrument, even if it's awkward for the human". so one of the goals here is to change that around... |
| # 18:14:13 | tkil | anyway, the actual data is in fact stored as an integer, pretty much the value read out of the ADC. but on the web interface to the instrument, you can ask for it to display the data file in human-readable terms. |
| # 18:14:27 | tkil | i'm trying to replicate that readout on the host (x86-64), hence my original question. |
| # 18:14:40 | tkil | anyway. :) sorry for going into lecture mode. |
| # 18:14:54 | imMute | aha, that makes sense. best of luck! |
| # 18:16:15 | tkil | thanks! :) |
| # 18:40:11 | smartin | quits : Quit: leaving |
| # 18:56:08 | codyps | quits : Ping timeout: 255 seconds |
| # 19:26:24 | mingwandroid | parts #crosstool-ng |
| # 19:29:13 | codyps | joins #crosstool-ng |
| # 19:29:34 | smartin | joins #crosstool-ng |
| # 19:46:06 | y_morin | joins #crosstool-ng |
| # 20:00:17 | mingwandroid | joins #crosstool-ng |
| # 20:33:04 | y_morin | quits : Quit: See you at FOSDEM! :-) |
| # 21:00:07 | mingwandroid | diorcety: hey |
| # 21:09:26 | mingwandroid | http://oi49.tinypic.com/34rhzf5.jpg |
| # 22:20:51 | smartin | quits : Quit: leaving |
| # 22:55:30 | sh4rm4 | quits : Ping timeout: 276 seconds |
| # 23:10:07 | sh4rm4 | joins #crosstool-ng |