| # 00:10:37 | y_morin | quits : Quit: Nighty Night! |
| # 01:01:21 | devcoder | joins #crosstool-ng |
| # 01:07:20 | codyps | quits : Ping timeout: 252 seconds |
| # 01:19:22 | devcoder | quits : Quit: devcoder |
| # 01:34:38 | devcoder | joins #crosstool-ng |
| # 01:38:40 | imMute | quits : Ping timeout: 265 seconds |
| # 01:44:47 | imMute | joins #crosstool-ng |
| # 01:44:48 | imMute | quits : Changing host |
| # 01:44:48 | imMute | joins #crosstool-ng |
| # 01:48:07 | codyps | joins #crosstool-ng |
| # 02:08:01 | alan_o | quits : Remote host closed the connection |
| # 02:20:54 | diorcety | quits : Read error: Connection reset by peer |
| # 02:29:55 | mingwandroid | quits : Quit: Leaving. |
| # 03:05:39 | alan_o | joins #crosstool-ng |
| # 03:06:48 | dprice | quits : Quit: Leaving. |
| # 03:34:29 | devcoder | quits : Quit: devcoder |
| # 04:23:59 | dprice | joins #crosstool-ng |
| # 04:30:43 | dprice1 | joins #crosstool-ng |
| # 04:32:36 | dprice | quits : Ping timeout: 240 seconds |
| # 06:08:47 | alan_o | quits : Remote host closed the connection |
| # 07:45:35 | boucman_work | joins #crosstool-ng |
| # 08:33:36 | dprice1 | quits : Ping timeout: 240 seconds |
| # 08:43:03 | dprice | joins #crosstool-ng |
| # 08:49:05 | dprice1 | joins #crosstool-ng |
| # 08:51:06 | dprice | quits : Ping timeout: 240 seconds |
| # 09:19:33 | smartin | joins #crosstool-ng |
| # 09:24:21 | dprice | joins #crosstool-ng |
| # 09:25:48 | dprice | quits : Client Quit |
| # 09:26:36 | dprice1 | quits : Ping timeout: 240 seconds |
| # 09:44:50 | Net147 | joins #crosstool-ng |
| # 09:46:47 | ssspiff | joins #crosstool-ng |
| # 10:40:17 | Net147 | quits : Quit: HydraIRC -> http://www.hydrairc.com <- Go on, try it! |
| # 10:51:31 | sspiff | joins #crosstool-ng |
| # 10:53:30 | ssspiff | quits : Ping timeout: 264 seconds |
| # 11:09:37 | Nemykal | joins #crosstool-ng |
| # 12:55:36 | Net147 | joins #crosstool-ng |
| # 13:14:49 | devcoder | joins #crosstool-ng |
| # 13:28:47 | devcoder | quits : Quit: devcoder |
| # 13:53:01 | Net147 | quits : Quit: HydraIRC -> http://www.hydrairc.com <- Go on, try it! |
| # 14:34:55 | alan_o | joins #crosstool-ng |
| # 14:53:47 | mingwandroid | joins #crosstool-ng |
| # 15:11:08 | diorcety | joins #crosstool-ng |
| # 16:00:40 | sfan5|OFF | is now known as: sfan5 |
| # 17:02:13 | diorcety | quits : Quit: Leaving. |
| # 17:36:31 | diorcety | joins #crosstool-ng |
| # 17:55:58 | abique|work | quits : Quit: Leaving |
| # 18:02:53 | ssspiff | joins #crosstool-ng |
| # 18:03:56 | ssspiff | hi, I'm trying to build an ARM toolchain (using the default cortex a8 config) and while it says it built successfully, and I get some tools (as, ar, objdump, ...) I don't get any gcc/g++/ld binaries |
| # 18:04:03 | ssspiff | does anyone know why that could be? |
| # 18:04:25 | abique|work | joins #crosstool-ng |
| # 18:13:42 | diorcety1 | joins #crosstool-ng |
| # 18:16:48 | diorcety | quits : Ping timeout: 246 seconds |
| # 18:36:14 | diorcety1 | quits : Quit: Leaving. |
| # 18:36:28 | diorcety | joins #crosstool-ng |
| # 19:19:38 | smartin | quits |
| # 19:32:34 | thewonderidiot | joins #crosstool-ng |
| # 19:35:59 | thewonderidiot | hello! |
| # 19:36:33 | thewonderidiot | I've got an old PReP-based PPC machine that I'm trying to build a cross-compiler for |
| # 19:37:04 | thewonderidiot | unforunately PReP was never ported from /arch/ppc to /arch/powerpc -- is there any chance of getting crosstool-ng to work? |
| # 19:37:35 | thewonderidiot | I got the old crosstool-0.43 to work (with the demo-powerpc-750.sh script), but I need a newer compiler than 4.1.0 |
| # 19:38:47 | thewonderidiot | oh, and it's running linux kernel version 2.6.18 |
| # 19:54:58 | y_morin | joins #crosstool-ng |
| # 20:04:42 | mingwandroid | parts #crosstool-ng |
| # 20:08:47 | papalazarou | joins #crosstool-ng |
| # 20:17:37 | thewonderidiot | actually, I've gotten ct-ng past the point of trouble before -- but it used arch=powerpc instead of arch=ppc to install headers. So new question: does it matter if ct-ng builds the kernel headers using arch=powerpc when my target board is only supported by arch=ppc? If not, then can I make ct-ng use arch=ppc? |
| # 20:24:36 | smartin | joins #crosstool-ng |
| # 20:43:31 | mingwandroid1 | joins #crosstool-ng |
| # 20:50:05 | y_morin | thewonderidiot: kernel 2.6.18 is very, very ancient, indeed. |
| # 20:50:40 | y_morin | thewonderidiot: what C library are you using: glibc, eglibc, or uClibc? |
| # 20:51:18 | thewonderidiot | I've been going back and forth between trying glibc and eglibc |
| # 20:51:33 | y_morin | thewonderidiot: if using glibc (or eglibc, they are pretty much alike in this respect), you can instruct it to include backward support for kernel older than the one used for the headers. |
| # 20:51:36 | y_morin | OK |
| # 20:52:18 | y_morin | thewonderidiot: For example, you can use linux-3.6.6 (latest) to get the headers from. And then you tell glibc to include support for way back up to 2.6.18. |
| # 20:52:22 | thewonderidiot | well, the trouble is, /arch/ppc disappears from the kernel headers after somewhere around 2.6.18, so I've been trying to build it against the headers I pulled from 2.6.18 |
| # 20:52:41 | sfan5 | is now known as: sfan5|OFF |
| # 20:53:10 | thewonderidiot | does it matter if it uses arch=powerpc instead though? |
| # 20:54:10 | y_morin | thewonderidiot: No, that's perfectly OK. |
| # 20:54:20 | thewonderidiot | ah, awesome |
| # 20:54:44 | y_morin | thewonderidiot: the ARCH=ppc or =powerpc is only used during kernel headers install, to (basically) know what directory to get headers from. |
| # 20:55:08 | y_morin | thewonderidiot: but in the sysroot (eg. the /usr/include for the target), that directory os not replicated. |
| # 20:55:25 | y_morin | thewonderidiot: yes, life can be shiny from time to time! ;-) |
| # 20:55:57 | thewonderidiot | haha, cool, I'm going to give it another go then. Thanks for the help! |
| # 20:56:44 | y_morin | thewonderidiot: look in the C library sub-menu, there's a entry where you can set the 'kernel compatibility' |
| # 20:58:11 | thewonderidiot | found it |
| # 20:58:29 | thewonderidiot | alright, it's chugging away |
| # 20:59:17 | thewonderidiot | I was concerned that installing headers with ARCH=powerpc instead of ARCH=ppc would cause incompatibility with this board -- good to know that that's not the case |
| # 21:06:00 | thewonderidiot | y_morin: is there any handy reference for which versions of binutils, gcc, and eglibc play together nicely? |
| # 21:12:07 | alan_o | quits : Ping timeout: 246 seconds |
| # 21:13:50 | diorcety | y_morin: hi |
| # 21:14:15 | diorcety | y_morin: have you to explain me the wanted behaviour in binutils config |
| # 21:14:17 | diorcety | ? |
| # 21:14:25 | diorcety | have you time |
| # 21:16:18 | y_morin | diorcety: Hello! |
| # 21:17:05 | y_morin | diorcety: what's the issue with the binutils? |
| # 21:25:06 | alan_o | joins #crosstool-ng |
| # 21:25:09 | diorcety | i'm trying to understand when elf2flt is ussed and sstrip |
| # 21:25:46 | diorcety | and ARCH_BINFMT_FDPIC? |
| # 21:25:49 | diorcety | not used? |
| # 21:27:21 | y_morin | diorcety: elf2flt is used when ARCH_BINFMT_FLAT is set, and only then. |
| # 21:27:41 | y_morin | ARCH_BINFMT_FLAT is for processors without an MMU, and without shared libraries |
| # 21:28:30 | y_morin | ARCH_BINFMT_FDPIC is for processors without an MMU, too, but with support for shared libraries. |
| # 21:29:05 | y_morin | sstrip is only for ARCH_BINFMT_ELF |
| # 21:29:28 | y_morin | So far, there's no support for ARCH_BINFMT_FDPIC in crosstool-NG |
| # 21:29:57 | y_morin | diorcety: so, is your question about how to introduce the cctools in the game? |
| # 21:31:34 | diorcety | make a menu |
| # 21:31:42 | diorcety | no? |
| # 21:34:56 | diorcety | how i can introduce correctly that? |
| # 21:35:07 | y_morin | diorcety: yes. The way you are going with in your git repo seems good. |
| # 21:35:31 | y_morin | diorcety: Well, that menu would be a bit convoluted, because: |
| # 21:36:03 | y_morin | 1) binutils and elf2flt are not exclusive, quite the opposite: elf2flt is a complement to binutils |
| # 21:36:23 | y_morin | 2) cctools and binutils(+elf2flt) are exclusive |
| # 21:36:40 | y_morin | 3) sstrip is just pita that we should just rip off. |
| # 21:39:40 | thewonderidiot | y_morin: I'm trying to build gcc-4.4.6 for compatibility with some other things we use, but I'm getting linking errors -- graphite.c:(.text+0x2722): undefined reference to `ppl_finalize' -- in the pass-1 core-C compiler stage |
| # 21:40:05 | y_morin | diorcety: so, maybe we could move elf2flt into binutils, and only show it for binfmt-flat. |
| # 21:40:32 | y_morin | diorcety: thus, we'd have only two components: binutils and cctools. Then we'd have a menu like for the C libraries. |
| # 21:41:10 | y_morin | thewonderidiot: please, share your .config (put on some pastebin, eg. code.bulix.org ) |
| # 21:43:27 | thewonderidiot | y_morin: here you go: http://pastebin.com/gHBDe0sB |
| # 21:46:22 | diorcety | y_morin: yes but it is a no choice ... |
| # 21:47:06 | y_morin | diorcety: indeed. Let's have each depend on DARWIN or !DARWIN. |
| # 21:47:34 | y_morin | diorcety: eg, in binutils.in: ## depends on !DARWIN |
| # 21:47:45 | y_morin | diorcety: and in cctools.in: ## depends on DARWIN |
| # 21:48:06 | y_morin | diorcety: thus, even it that gets into a choice entry, only the available one(s) will be displayed |
| # 21:49:40 | y_morin | diorcety: that's what we already do in the C library choice menu. Each library already depend on some conditions, and if they are not met, that C library is not available in the choice menu. |
| # 21:50:32 | y_morin | diorcety: granted, for binutils' choice, we know this will never be a real choice. But I don't want to invent yet another mechanism. |
| # 21:50:52 | y_morin | diorcety: and who nows? Maybe in a while, the GNU binutils wil have support for Darwin? ;-) |
| # 21:51:05 | diorcety | ^^ |
| # 21:51:47 | y_morin | diorcety: lemme look again at your repo, t osee what you've done so far. |
| # 21:53:49 | y_morin | diorcety: OK, I'll give you a hint: buy a flame-thrower, and aim it at sstrip. ;-) |
| # 21:54:21 | diorcety | ok so i make a menu? |
| # 21:54:42 | diorcety | and put elf2flt in binutils |
| # 21:54:50 | y_morin | diorcety: yes. But first, migrate elf2flt as a binutils.in sub-options, not as an alternative. |
| # 21:54:55 | y_morin | diorcety: exactly. |
| # 21:55:14 | y_morin | diorcety: the way you did in your repo looks OK at firstsight. |
| # 21:55:33 | y_morin | diorcety: hold on! |
| # 21:55:56 | y_morin | diorcety: just rename the elf2flt.in into binutils.in.2, and you should be done with it. |
| # 21:57:23 | y_morin | diorcety: there might be something to do with the build script, though. |
| # 21:58:20 | diorcety | and ARCH_BINFMT_FDPIC ? |
| # 21:58:22 | diorcety | yes yes |
| # 22:03:58 | y_morin | diorcety: I want to keep FDPIC for now, even if it never used (well, we have no sample that use it). |
| # 22:07:54 | diorcety | it is no used at all ?! |
| # 22:09:02 | diorcety | how i merge binutils.sh elf2flt.sh? |
| # 22:09:38 | y_morin | diorcety: well, FDPIC *is* used by one of our samples! :-) |
| # 22:09:48 | y_morin | diorcety: Hehe, good question! ;-) |
| # 22:10:16 | y_morin | diorcety: lemme have a look how they are today, first. |
| # 22:10:55 | diorcety | yes but ARCH_BINFMT_FDPIC is not used in scripts ?! |
| # 22:11:52 | y_morin | diorcety: maybe it's used neither in config/ nor scripts/. But it is a choice entry, so the laternate choice symbol *is* used. So if you choose FDPIC, it means FLAT is not selected. |
| # 22:12:33 | diorcety | hum ok |
| # 22:12:52 | y_morin | diorcety: and FLAT enables sone stuff. So FDPIC implicitly deisables that stuff. |
| # 22:13:22 | y_morin | diorcety: for binutils+elf2flt: in do_binutils_backend(): add build of elf2flt if it is selected. |
| # 22:13:41 | y_morin | diorcety: I'll leave to your imagination how to do the download, extract and patch. ;-) |
| # 22:14:02 | diorcety | ok |
| # 22:14:38 | diorcety | i have to keep ARCH_BINFMT_FDPIC but now elf2flt is in binutils ... there in no choice .. yes FLAT enable or not |
| # 22:15:10 | y_morin | diorcety: elf2flt is still conditional to BINFMT_FLAT |
| # 22:15:25 | y_morin | diorcety: eveas a sub-option to binutils. |
| # 22:15:30 | y_morin | *even as |
| # 22:15:48 | diorcety | yes |
| # 22:16:20 | diorcety | how i make it work with ARCH_BINFMT_FDPIC ? |
| # 22:17:28 | y_morin | diorcety: and as bonus point, you get to get away with the dirty hack in elf2flt to reference the binutils source tree: you already know it, as you're in the same script, now! :-) |
| # 22:17:54 | y_morin | diorcety: no need to. elf2flt is not needed for FdPIC (IIRC) |
| # 22:18:55 | diorcety | i talk about config ARCH_BINFMT_FDPIC depends on ! ARCH_BINFMT_FLAT and ARCH_BINFMT_FLAT depends on ! ARCH_BINFMT_FDPIC |
| # 22:18:58 | diorcety | ? |
| # 22:20:40 | y_morin | diorcety: Ah, OK, that part. No, you keep the choice as it is today! |
| # 22:21:04 | y_morin | diorcety: I missed that you removed it in your repo. You should not have! |
| # 22:21:25 | y_morin | diorcety: Jsut include config.gen/binutils.in instead of each binutils/*.in |
| # 22:24:04 | y_morin | diorcety: Oh, I think I see your issue. |
| # 22:25:07 | y_morin | diorcety: Hmmm. No, forget it... |
| # 22:26:20 | y_morin | diorcety: http://code.bulix.org/5kuwus-82469 |
| # 22:31:33 | diorcety | ok understood |
| # 22:32:00 | diorcety | if add config ARCH_BINFMT_PE |
| # 22:34:15 | y_morin | diorcety: that's for DARWIN? |
| # 22:35:15 | diorcety | PE = windows :D |
| # 22:38:36 | diorcety | no so easy to merge binutils with elf2flt ... pushd are done ouside backend .. |
| # 22:39:59 | y_morin | diorcety: OK, so add a elf2flt backend, and call it only if it is needed. |
| # 22:40:29 | y_morin | diorcety: PE: Ah, I see. Yes, that would make sense, too. |
| # 22:53:53 | y_morin | thewonderidiot: Sorry, I forgot about you... :-( The build is going on here. I wil tell you when it breaks. |
| # 22:58:50 | diorcety | y_morin: https://github.com/diorcety/crosstool-ng/tree/darwin |
| # 23:02:24 | y_morin | diorcety: OK, I'm looking now... |
| # 23:02:57 | thewonderidiot | y_morin: great, thanks :) |
| # 23:04:29 | y_morin | thewonderidiot: Ah, I think I know why. Lemme do another test-build with a few options changed, just to be sure... |
| # 23:07:53 | y_morin | diorcety: be carefull: you're doing many unrelated things in each changeset. For example, removing sstrip should be in its own cset. |
| # 23:10:03 | y_morin | diorcety: basically, the idea for the binutils menu is there, but it still needs some polishing. :-) |
| # 23:10:24 | y_morin | diorcety: the BINFMT_PE should also be in its own cset. |
| # 23:11:12 | y_morin | diorcety: binutils.in: ## Depends on ! KERNEL_darwin |
| # 23:11:40 | y_morin | (instead of the long ## depends on bla || bla || bla... |
| # 23:12:49 | y_morin | diorcety: in config/binutils.in: change those "if blabla ... endif" into "depends on blabla" |
| # 23:14:50 | y_morin | diorcety: the elf2flt is pretty OK! \o/ |
| # 23:15:25 | y_morin | diorcety: you can however simplify it a bit: |
| # 23:15:41 | y_morin | 1) see if it is possible to re-use the binutils_opts array |
| # 23:16:02 | y_morin | 2) commonalise the tools symlink |
| # 23:17:27 | y_morin | thewonderidiot: OK, my guess was right: you selected too recent companion libraries. |
| # 23:17:41 | y_morin | thewonderidiot: you have to use older comp-libs with gcc-4.4: |
| # 23:17:51 | y_morin | gmp: 4.3.2 |
| # 23:17:57 | y_morin | mpfr: 2.4.2 |
| # 23:18:04 | y_morin | ppl: 10.10.2 |
| # 23:18:09 | y_morin | cloog: 0.15.11 |
| # 23:18:19 | thewonderidiot | y_morin: I figured! I was trying various combinations and was getting different failures |
| # 23:18:25 | thewonderidiot | y_morin: thanks a ton! |
| # 23:18:32 | y_morin | thewonderidiot: cheers! ;-) |
| # 23:18:58 | y_morin | thewonderidiot: there is no provision in ct-ng to set this properly, unfortunately. It's not that trivial to do... :-( |
| # 23:19:08 | y_morin | I mean: to set it automatically. |
| # 23:19:27 | thewonderidiot | right |
| # 23:21:49 | y_morin | diorcety: OK for the companion libs rework. :-) |
| # 23:22:22 | y_morin | diorcety: could you try to push it to the list? (so I can apply it and you can get rid of it.) |
| # 23:23:00 | alan_o | quits : Quit: Leaving |
| # 23:23:13 | diorcety | push companion libs rework only? |
| # 23:23:53 | y_morin | diorcety: It's the only I've reviewed in depth so far. |
| # 23:24:00 | diorcety | ok |
| # 23:24:07 | diorcety | i do that tomorrow |
| # 23:24:44 | y_morin | diorcety: but basically, when you have some patches that are finished, do not hesitate to push them to the list, even if the whole series is not. |
| # 23:25:17 | y_morin | diorcety: the less patches you have to deal with, the easier it will be for you. The fewer patches we get to review on the list, the easier it is to merge them! :-) |
| # 23:25:27 | y_morin | diorcety: that's a win-win situation! |
| # 23:26:24 | y_morin | diorcety: for example, you can push the comp-libs rework. Once you have extracted sstrip removal, you can push it. Then when you've added BINFMT_PE, you can push it, and so on.. |
| # 23:27:08 | y_morin | diorcety: the basis is to always try for the smaller patch possible that is a semantically-autonomous change. |
| # 23:27:35 | smartin | quits : Quit: good night |
| # 23:27:47 | y_morin | diorcety: for example, adding BINFMT_PE, and removing sstrip are not related: they should be in two different patches. |
| # 23:28:16 | diorcety | ok i will rebase this commit |
| # 23:28:26 | y_morin | yawns... Time for bed, I guess... |
| # 23:28:53 | y_morin | diorcety: thank you for working on this! That's great! :-) |
| # 23:28:57 | diorcety | ^^ me too |
| # 23:28:58 | diorcety | no pb |
| # 23:29:09 | y_morin | quits : Quit: Nighty Night! |