| # 00:10:44 | bhundven | tlwoerner: ? |
| # 01:44:35 | djerome | joins #crosstool-ng |
| # 01:57:51 | diorcety | joins #crosstool-ng |
| # 02:00:24 | diorcety1 | quits : Ping timeout: 240 seconds |
| # 02:11:18 | tlwoerner | bhundven: :-) |
| # 03:30:19 | perr | joins #crosstool-ng |
| # 03:30:19 | perr | quits : Changing host |
| # 03:30:19 | perr | joins #crosstool-ng |
| # 03:36:50 | perr | quits : Ping timeout: 264 seconds |
| # 03:46:40 | perr | joins #crosstool-ng |
| # 03:53:37 | perr | quits : Ping timeout: 265 seconds |
| # 04:14:44 | perr | joins #crosstool-ng |
| # 04:19:21 | bhundven | gah, I've been sick for 3 days. I keep missing people on chat. |
| # 04:29:38 | perr | quits : Ping timeout: 240 seconds |
| # 04:42:03 | perr | joins #crosstool-ng |
| # 05:15:06 | djerome | quits : Remote host closed the connection |
| # 05:28:52 | tlwoerner | bhundven: still here? |
| # 05:30:38 | perr | quits : Ping timeout: 240 seconds |
| # 05:32:17 | tlwoerner | email probably works better :-) |
| # 05:43:39 | perr | joins #crosstool-ng |
| # 06:20:38 | perr | quits : Ping timeout: 240 seconds |
| # 06:34:09 | perr | joins #crosstool-ng |
| # 07:51:15 | diorcety | quits : Quit: Leaving. |
| # 07:55:36 | perr | quits : Ping timeout: 240 seconds |
| # 08:02:15 | hurdman | tu avais quand même l'usb2serial ? |
| # 08:02:22 | hurdman | sorry bad chan |
| # 08:11:59 | perr | joins #crosstool-ng |
| # 08:12:17 | hurdman | is now known as: nantes_geek |
| # 08:12:50 | nantes_geek | is now known as: hurdman |
| # 08:19:26 | perr | quits : Ping timeout: 264 seconds |
| # 08:43:20 | aalv | joins #crosstool-ng |
| # 08:48:17 | perr | joins #crosstool-ng |
| # 08:56:40 | perr | quits : Ping timeout: 265 seconds |
| # 09:27:08 | silviof | joins #crosstool-ng |
| # 09:27:08 | perr | joins #crosstool-ng |
| # 09:27:09 | perr | quits : Changing host |
| # 09:27:09 | perr | joins #crosstool-ng |
| # 09:27:21 | silviof | parts #crosstool-ng |
| # 09:48:17 | duffduff | parts #crosstool-ng |
| # 10:33:46 | Net147 | joins #crosstool-ng |
| # 11:10:00 | perr | quits : Ping timeout: 240 seconds |
| # 11:22:09 | perr | joins #crosstool-ng |
| # 11:40:52 | zkrx | joins #crosstool-ng |
| # 11:54:48 | zkrx | quits : Ping timeout: 240 seconds |
| # 11:59:58 | zkrx | joins #crosstool-ng |
| # 12:48:58 | zkrx | quits : Ping timeout: 240 seconds |
| # 12:54:06 | zkrx | joins #crosstool-ng |
| # 13:07:18 | perr | quits : Ping timeout: 240 seconds |
| # 14:02:14 | perr | joins #crosstool-ng |
| # 14:42:27 | Net147 | quits : Quit: HydraIRC -> http://www.hydrairc.com <- |
| # 15:00:48 | zkrx | quits : Remote host closed the connection |
| # 15:02:54 | zkrx | joins #crosstool-ng |
| # 15:21:46 | mnt_real | quits : *.net *.split |
| # 15:29:11 | mnt_real | joins #crosstool-ng |
| # 16:12:14 | perr | quits : Ping timeout: 264 seconds |
| # 16:40:13 | mingwandroid | joins #crosstool-ng |
| # 16:50:29 | mingwandroid | quits : Read error: Connection reset by peer |
| # 16:51:41 | mingwandroid | joins #crosstool-ng |
| # 16:54:47 | zkrx | quits : Ping timeout: 272 seconds |
| # 17:17:06 | y_morin | joins #crosstool-ng |
| # 17:22:45 | zkrx | joins #crosstool-ng |
| # 17:26:37 | mingwandroid | quits : Read error: Connection reset by peer |
| # 17:27:51 | mingwandroid | joins #crosstool-ng |
| # 17:33:03 | aalv | quits : Remote host closed the connection |
| # 18:27:59 | bhundven | ok |
| # 18:28:45 | bhundven | tlwoerner: so the gcc snapshot for 4.8 (4.8.3) supports arm multilib? |
| # 18:32:15 | bhundven | tlwoerner: in my point of view, the only horse I have in the multilib race, is just to get it working. |
| # 18:33:02 | bhundven | tlwoerner: if you have a way to get multilib to work on all architectures that support it, in a way that future architectures will also be supported, I'm all in. |
| # 18:34:42 | bhundven | tlwoerner: but I'm not interested in a one off change that just gets arm multilib working, disregarding the other platforms. Listing the architectures and variants in ct-ng is planned, we just hadn't gotten there yet. |
| # 18:35:01 | bhundven | s/Listing/Setting/ |
| # 18:51:37 | mingwandroid | quits : Read error: Connection reset by peer |
| # 18:52:52 | mingwandroid | joins #crosstool-ng |
| # 18:53:18 | diorcety | joins #crosstool-ng |
| # 18:59:10 | mingwandroid_ | joins #crosstool-ng |
| # 19:02:02 | mingwandroid | quits : Ping timeout: 264 seconds |
| # 19:43:06 | Virus_7 | joins #crosstool-ng |
| # 19:45:55 | mingwandroid_ | quits : Read error: Connection reset by peer |
| # 19:47:18 | mingwandroid | joins #crosstool-ng |
| # 19:52:01 | mingwandroid_ | joins #crosstool-ng |
| # 19:54:29 | mingwandroid | quits : Ping timeout: 240 seconds |
| # 19:58:01 | tlwoerner | ha! that ctngbot is cute! |
| # 19:59:16 | tlwoerner | bhundven: if you download the sources from https://launchpad.net/gcc-arm-embedded the compiler declares itself as 4.8.3 and supports arm multilib |
| # 19:59:32 | tlwoerner | (at least for the cortex-M profile) |
| # 19:59:55 | tlwoerner | arm-none-eabi-gcc -print-multi-lib |
| # 19:59:55 | tlwoerner | .; |
| # 19:59:55 | tlwoerner | thumb;@mthumb |
| # 19:59:55 | tlwoerner | fpu;@mfloat-abi=hard |
| # 19:59:55 | tlwoerner | armv6-m;@mthumb@march=armv6s-m |
| # 19:59:56 | tlwoerner | armv7-m;@mthumb@march=armv7-m |
| # 19:59:58 | tlwoerner | armv7e-m;@mthumb@march=armv7e-m |
| # 20:00:00 | tlwoerner | armv7-ar/thumb;@mthumb@march=armv7 |
| # 20:00:02 | tlwoerner | armv7e-m/softfp;@mthumb@march=armv7e-m@mfloat-abi=softfp@mfpu=fpv4-sp-d16 |
| # 20:00:06 | tlwoerner | armv7e-m/fpu;@mthumb@march=armv7e-m@mfloat-abi=hard@mfpu=fpv4-sp-d16 |
| # 20:00:08 | tlwoerner | armv7-ar/thumb/softfp;@mthumb@march=armv7@mfloat-abi=softfp@mfpu=vfpv3-d16 |
| # 20:00:10 | tlwoerner | armv7-ar/thumb/fpu;@mthumb@march=armv7@mfloat-abi=hard@mfpu=vfpv3-d16 |
| # 20:00:56 | bhundven | ok |
| # 20:01:26 | bhundven | so this is work that will go into gcc 4.8.3 (official)? |
| # 20:02:21 | tlwoerner | i know that team works on getting things upstream, but when it gets in isn't well known |
| # 20:02:43 | tlwoerner | we would have to try to involve some of them in these discussions |
| # 20:02:53 | tlwoerner | i've noticed some of them are on the crosstool-NG mailing list |
| # 20:03:00 | bhundven | yup |
| # 20:03:09 | bhundven | here is the problem |
| # 20:03:17 | bhundven | (I've been in your spot before ;) ) |
| # 20:03:50 | bhundven | crosstool-ng needs to support the official gcc. |
| # 20:04:02 | bhundven | I also see it working for snapshots |
| # 20:04:24 | bhundven | but that is more of a gcc/binutils/glibc developer thing |
| # 20:05:11 | bhundven | I used to work for watchguard, and we did some custom stuff with our toolchain |
| # 20:05:42 | bhundven | one of them was static toolchain (the tools are static, not that it only makes static output) |
| # 20:06:20 | bhundven | there has to be a compromise for the gcc-arm-embedded stuff though |
| # 20:06:33 | tlwoerner | http://en.wikipedia.org/wiki/WatchGuard ? |
| # 20:06:53 | bhundven | right |
| # 20:08:32 | bhundven | yann wasn't too excited to take on some of our custom additions to ct-ng |
| # 20:08:50 | bhundven | so we had to have a local branch to track upstream and our changes |
| # 20:09:09 | tlwoerner | even if the "C compiler" menu had a generic "extra arguments to pass to pass 1/2/3 build" (i.e. "extra config" the way, say, gdb does) |
| # 20:09:22 | bhundven | sure |
| # 20:09:34 | bhundven | I don't see anything wrong with that |
| # 20:09:36 | tlwoerner | this would allow me to enable "multilib" then pass the "--multilib-list" option |
| # 20:09:52 | bhundven | but |
| # 20:10:46 | bhundven | crosstool-ng doesn't really track passes that well |
| # 20:11:01 | bhundven | well, let me explain |
| # 20:12:13 | tlwoerner | do_cc_core_pass_1(), do_cc_core_pass_2(), do_cc_for_host() ? |
| # 20:12:27 | bhundven | hehe |
| # 20:12:30 | bhundven | yes |
| # 20:12:49 | bhundven | at the same time as multilib is going in |
| # 20:13:03 | bhundven | so is llvm/clang |
| # 20:13:18 | bhundven | and a few other things |
| # 20:13:42 | bhundven | I just feel like it's about time some refactoring happens to take these things into consideration |
| # 20:13:57 | bhundven | probably won't be doing multilib for llvm |
| # 20:14:08 | bhundven | so you're right |
| # 20:14:38 | bhundven | putting in a CT_CC_GCC_PASS{x}_EXTRA_ARGS isn't going to hurt much |
| # 20:14:49 | tlwoerner | :-) |
| # 20:15:12 | bhundven | I've been sick, so my brain is kinda scrambled :P |
| # 20:15:21 | tlwoerner | i'm not familiar enough with llvm, but it's on "the list" :-) |
| # 20:15:42 | Virus_7 | quits : Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/ |
| # 20:16:09 | bhundven | it just seems to me that crosstool-ng needs to be componentized a bit more |
| # 20:16:36 | bhundven | parts of crosstool-NG.sh.in reach into scripts/build/cc/gcc.sh |
| # 20:16:45 | bhundven | and have no barring on llvm |
| # 20:16:55 | bhundven | stuff like that |
| # 20:17:02 | tlwoerner | well, now that i'm getting more familiar with it, i'd be happy to help, and help with any refactoring (if i understand what i'm doing!) |
| # 20:17:16 | bhundven | does that make sense? |
| # 20:17:44 | tlwoerner | oh yes, everything you've said is clear. and i'm grateful for the explanations |
| # 20:18:07 | bhundven | cool. I feel a bit foggy |
| # 20:18:12 | bhundven | hehe |
| # 20:18:22 | tlwoerner | since i have your attention... |
| # 20:19:24 | mingwandroid_ | quits : Read error: Connection reset by peer |
| # 20:20:07 | tlwoerner | when one uses a crosscompiler, often there are a bunch of flags that are always given (-ffunction-sections -fdata-sections) |
| # 20:20:25 | tlwoerner | isn't there a way to build the crosscompiler such that it will always invoke these flags automatically? |
| # 20:20:40 | mingwandroid | joins #crosstool-ng |
| # 20:20:51 | bhundven | well, yes. luckly gcc isn't monolithic |
| # 20:21:08 | tlwoerner | that way the Makefiles and build invocations can be "cleaner"? |
| # 20:21:35 | bhundven | it depeneds |
| # 20:21:48 | bhundven | s/depeneds/depends/ |
| # 20:22:20 | bhundven | so, there are flags you want gcc built with, and there are flags you want gcc to use when compiling on the target |
| # 20:22:33 | bhundven | er, compiling for the target |
| # 20:22:49 | bhundven | I'm assuming you mean the later |
| # 20:23:21 | bhundven | one way is to make a wrapper for the cross-compiler |
| # 20:23:46 | bhundven | for instance if you have: arm-unknown-linux-gnueabi- |
| # 20:24:07 | tlwoerner | ah good, _for_ the target |
| # 20:24:14 | tlwoerner | yes, the latter |
| # 20:24:40 | bhundven | mv the -gcc to -gcc.orig, and have the wrapper add the command line (this in my opinion is the cleaner way) |
| # 20:24:55 | bhundven | or |
| # 20:25:01 | tlwoerner | oh yea? that seems "hackish" to me :-) |
| # 20:25:11 | bhundven | waits for everyone to get ready to hit him with thousands of shoes |
| # 20:25:20 | bhundven | you can modify the specs file |
| # 20:25:28 | bhundven | ducks |
| # 20:25:38 | tlwoerner | that requires a source patch before building? |
| # 20:26:02 | bhundven | right |
| # 20:26:04 | tlwoerner | what about "CFLAGS_FOR_TARGET"? |
| # 20:26:35 | tlwoerner | everyone's been quiet up to now, if they get excited they're too late to the conversation :-) |
| # 20:27:25 | bhundven | there was something about that... |
| # 20:27:28 | bhundven | I forget now |
| # 20:27:35 | bhundven | let me look really quick |
| # 20:28:25 | tlwoerner | i agree, modifying a specs file would be much messier than a wrapper |
| # 20:28:39 | bhundven | well, it's also kinda messy |
| # 20:28:48 | bhundven | in a different way |
| # 20:29:11 | bhundven | because rather then modifying the specs file for the build |
| # 20:29:20 | bhundven | you want to replace the specs file after the build |
| # 20:29:32 | bhundven | so I was wrong earlier, gcc wouldn't need a patch before building |
| # 20:30:02 | tlwoerner | oh phew, i was just about to ask (i was getting confused) |
| # 20:30:04 | bhundven | ct-ng or (manually by hand) you modify the specs file after gcc-final is done |
| # 20:30:18 | bhundven | yea, sorry about that |
| # 20:30:30 | tlwoerner | but i thought the specs file was hidden away since a long time ago? |
| # 20:30:46 | tlwoerner | back in the good ol' days, the specs file was readily available as part of the install |
| # 20:30:58 | tlwoerner | you'd just copy it, edit it, and replace |
| # 20:31:09 | tlwoerner | but i though that was gone and the specs were "burried" |
| # 20:31:38 | tlwoerner | s/were/are |
| # 20:33:14 | bhundven | nah |
| # 20:33:51 | bhundven | if a specs file does not exist in the right place |
| # 20:34:01 | bhundven | it uses the internal specs file |
| # 20:34:09 | bhundven | -gcc -dumpspecs |
| # 20:34:13 | tlwoerner | ah, interesting |
| # 20:34:31 | tlwoerner | how does one know the "right" place? |
| # 20:34:34 | bhundven | you can dump that to a file and put it in ..\libgcc\specs |
| # 20:34:54 | tlwoerner | excellent |
| # 20:35:08 | bhundven | (nasty hack: http://www.linuxfromscratch.org/lfs/view/6.2/chapter05/adjusting.html) |
| # 20:35:27 | bhundven | we did have some specs file magic at WG |
| # 20:35:35 | bhundven | and I think that was in with the changes yann didn't want |
| # 20:35:46 | bhundven | as it is a nasty hack |
| # 20:36:02 | bhundven | essentially, the specs file is the driver for gcc |
| # 20:36:23 | bhundven | to tell gcc the steps and what to pass the steps on the command line |
| # 20:36:31 | bhundven | internally |
| # 20:36:47 | bhundven | http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html |
| # 20:37:16 | bhundven | mingwandroid: doesn't mingw have some specs file magic? |
| # 20:37:53 | mingwandroid | I'm playing catch up here .. one sec. |
| # 20:38:38 | mingwandroid | tlwoerner: trevor? hello. |
| # 20:38:44 | tlwoerner | mingwandroid: hello |
| # 20:39:50 | bhundven | hehe, my brain had to go back to 2011 for the specs file memory |
| # 20:39:56 | mingwandroid | quits : Read error: Connection reset by peer |
| # 20:40:17 | bhundven | think I was on gcc-4.4 |
| # 20:41:08 | mingwandroid | joins #crosstool-ng |
| # 20:41:32 | mingwandroid | bhundven: I don't *think* mingw is specifically hacky specs-wise. |
| # 20:42:00 | tlwoerner | hmm... according to "The Definitive Guide to GCC" the specs file was internalized starting with 4.0 |
| # 20:42:13 | tlwoerner | it suggests dumping the specs (as you mentioned) |
| # 20:42:26 | tlwoerner | then using the "-specs=file" cmdline option |
| # 20:43:07 | mingwandroid | tlwoerner: I missed some context here, what are you trying to achieve? |
| # 20:43:24 | bhundven | I personally recommend the wrapper option |
| # 20:44:04 | tlwoerner | internalizing options such as "-ffunction-sections" so the user isn't required to specify them every time they invoke the compiler |
| # 20:44:18 | tlwoerner | "default arguments" to the crosscompiler... if you will |
| # 20:45:00 | tlwoerner | which could also be used to specify a linker script too, for different targets |
| # 20:45:51 | bhundven | ah, here is the more modern stuff from lfs: http://www.linuxfromscratch.org/lfs/view/7.4/chapter06/adjusting.html |
| # 20:47:02 | mingwandroid | tlwoerner: ah ok. +1 for wrapper scripts from me then. |
| # 20:47:13 | bhundven | so, I'm happy to hand you the rope to hang yourself, but I'd rather send you to a path of sanity |
| # 20:47:20 | bhundven | the wrapper is the better choice |
| # 20:47:43 | tlwoerner | excellent, i have some reading ahead of me then :-D |
| # 20:47:55 | tlwoerner | yes. i'm starting to agree => wrappers are cleaner |
| # 20:47:57 | bhundven | hehe |
| # 20:47:58 | mingwandroid | tlwoerner: linaro has it's own fork of crosstool-ng? |
| # 20:48:26 | tlwoerner | uhhhh.... not that i know of... (but i'm not in the toolchain group) |
| # 20:49:19 | bhundven | I know michael hope has done some work on ct-ng |
| # 20:49:26 | bhundven | (spelling?) |
| # 20:49:45 | bhundven | but, idk if he has a linaro fork |
| # 20:50:10 | tlwoerner | yes, i've noticed his contributions before, but i have yet to meet him in person |
| # 20:50:31 | tlwoerner | linaro has their own gcc fork, which ct-ng can be used to build |
| # 20:50:54 | mingwandroid | quits : Read error: Connection reset by peer |
| # 20:51:34 | tlwoerner | i know some of the guys use https://wiki.linaro.org/Cbuildv2Usage |
| # 20:52:09 | mingwandroid | joins #crosstool-ng |
| # 20:52:21 | bhundven | So, that is kind of the point I'm trying to get to. This is my thought. (I was waiting for mingwandroid to join again) |
| # 20:52:47 | bhundven | if scripts/build/cc/gcc.sh is componentized |
| # 20:53:05 | mingwandroid | diorcety: ping |
| # 20:53:25 | bhundven | tlwoerner: so that there are wrapper sh files for: official, linaro, custom |
| # 20:53:36 | bhundven | then there is no need to fork |
| # 20:54:04 | bhundven | is all about abstracting process, to make more flexable |
| # 20:55:11 | bhundven | just like breaking out architecture specific things to scripts/build/arch/ |
| # 20:55:55 | mingwandroid | bhundven: well, I think once we get multilib committed, working on diorcety fork to get the CC-variant stuff into a mergable state would be really good. |
| # 20:56:09 | bhundven | ja |
| # 20:56:41 | mingwandroid | where are we with multilib? tlwoerner: that was a long list of multilibs for your compiler. |
| # 20:57:51 | bhundven | well, I know there are other updates in patchworks that should get applied soon |
| # 20:58:01 | bhundven | (not my kconfig update, though) |
| # 20:58:19 | bhundven | but they are mostly version updates |
| # 20:59:11 | bhundven | I don't think the multilib changes should affect llvm |
| # 20:59:21 | bhundven | or am I totally wrong? |
| # 21:00:10 | bhundven | as multilib should be specific to gcc/target-glibc/target-binutils |
| # 21:00:53 | tlwoerner | mingwandroid: yes, that nice list is generated from the gcc-arm-embedded compiler, which is being developed by ARM employees (https://launchpad.net/gcc-arm-embedded) |
| # 21:01:24 | bhundven | nods |
| # 21:01:39 | mingwandroid | bhundven: well, it's not a dependency at all, just thinking "lets get that out out of the way first" |
| # 21:02:03 | tlwoerner | sounds like there's a number of interesting TODO items for crosstool-NG yet! |
| # 21:02:06 | bhundven | diorcety's changes are probably 10x more mature then the multilib stuff |
| # 21:02:17 | bhundven | tlwoerner: oh yea |
| # 21:02:31 | bhundven | :D |
| # 21:02:53 | mingwandroid | bhundven: well, I think multilib is quite un-intrusive and can be committed if we can ensuere its not effecting the non-multilib case .. |
| # 21:03:02 | bhundven | I don't have a personal agenda, other then fielding support on crossgcc and working on my silly projects |
| # 21:04:42 | bhundven | hopefully, I'm able to help yann a bit more with patchworks and moving to git, so that more people don't have to go through the mercurial learning curve anymore |
| # 21:05:19 | mingwandroid | bhundven: then CT_EXPERIMENTAL it .. I know there was an attempt by Yann D. to merge diorcety's CC choice stuff .. https://sourceware.org/ml/crossgcc/2013-12/msg00003.html |
| # 21:05:59 | bhundven | yes, the changes just need to be broken out into steps |
| # 21:06:11 | bhundven | I haven't looked at it recently |
| # 21:06:44 | mingwandroid | https://sourceware.org/ml/crossgcc/2013-12/msg00018.html |
| # 21:06:50 | bhundven | at the same time, we're trying to remove kconfig from ct-ng |
| # 21:07:03 | bhundven | and switching to y_morin's kconfig-frontends |
| # 21:07:06 | bhundven | external dependency |
| # 21:07:18 | bhundven | http://ymorin.is-a-geek.org/git/kconfig-frontends/ |
| # 21:07:32 | bhundven | (which I have a few pending patches to) |
| # 21:07:47 | mingwandroid | what's this all about? |
| # 21:08:35 | bhundven | I posted an update to sync kconfig from the upstream in the linux kernel |
| # 21:09:06 | bhundven | and yann suggested that we attempt to remove kconfig from ct-ng to make ct-ng a little easier to maintain |
| # 21:09:14 | y_morin | bhundven: Well, we can keep our built-in version (and bump it once more). But if kconfig stuff already exists on the user's machine, use that and don;t bother build our bundled version. |
| # 21:09:23 | bhundven | right |
| # 21:09:45 | bhundven | I'd like to just see it go away, and use the external dep |
| # 21:09:47 | y_morin | bhundven: Then after a while, we can just rip it out (but not right now). |
| # 21:09:52 | bhundven | :) |
| # 21:09:54 | y_morin | bhundven: So would I. |
| # 21:10:11 | bhundven | jinx |
| # 21:14:22 | mingwandroid | quits : Read error: Connection reset by peer |
| # 21:15:35 | mingwandroid | joins #crosstool-ng |
| # 21:16:16 | bhundven | mingwandroid: I personally think that because no one has really commented on the patches in the patchqueue, it is less mature then llvm/diorcety changes |
| # 21:16:40 | bhundven | I feel less comfortable pushing changes that aren't complete or commented on |
| # 21:17:31 | mingwandroid | quits : Read error: Connection reset by peer |
| # 21:18:45 | mingwandroid | joins #crosstool-ng |
| # 21:22:54 | mingwandroid | bhundven: I think posting the to the ML is the accepted way to request for comments though is it not? |
| # 21:23:13 | bhundven | sure |
| # 21:23:50 | bhundven | tlwoerner: do you want to be added to the ml patch queue to add your additions? |
| # 21:24:15 | tlwoerner | putting patches on ML will help their visibility |
| # 21:24:23 | tlwoerner | bhundven: there's a ml patch queue? :-) |
| # 21:24:46 | bhundven | https://bitbucket.org/bhundven/crosstool-ng-multilib |
| # 21:24:56 | mingwandroid | ml == mailing list and multilib?! |
| # 21:25:05 | bhundven | hahaha |
| # 21:25:11 | tlwoerner | mingwandroid: haha, yes i was thinking that! |
| # 21:25:21 | mingwandroid | ok ML == mailing list, ml == multilib, not confusing at all now. |
| # 21:25:38 | tlwoerner | bhundven: i'm not sure if i need to be added |
| # 21:25:48 | mingwandroid | tlwoerner: have you done some tests of it yet? |
| # 21:26:02 | mingwandroid | y_morin: would you rather we posted to the mailing list before commenting or would you check that URL ^? |
| # 21:26:24 | bhundven | there is quite a bit of backlog too |
| # 21:26:31 | bhundven | on the mailinglist |
| # 21:26:42 | tlwoerner | bhundven: i did a quick test, but it required me to hard-code my --with-multilib-list, and it failed in the very last step (cleaning up) |
| # 21:26:43 | y_morin | bhundven: The list, definitely. That way, all can read and review. |
| # 21:27:28 | y_morin | bhundven: Yes, I've been slacking a bit. But I've already quickly skimmed over all the changes, and most are not urgent. |
| # 21:27:33 | tlwoerner | but i haven't had time to investigate |
| # 21:27:39 | bhundven | :) |
| # 21:28:01 | bhundven | tlwoerner: is that with the patches mingwandroid and I have or with your pass1/2/3 option? |
| # 21:28:01 | mingwandroid | y_morin: whens 1.20 planned for? |
| # 21:28:06 | y_morin | bhundven: I want to do the release *this* WE, so I'm building all the toolchains (takes time, so no patch jungling in the meantime. |
| # 21:28:15 | y_morin | mingwandroid: ^^^ |
| # 21:28:19 | bhundven | y_morin: understood ;) |
| # 21:28:29 | tlwoerner | y_morin: the "newlib custom extract" patch is urgent to me :-) |
| # 21:28:46 | y_morin | tlwoerner: Yes, I saw that one (but it is very recent!) |
| # 21:29:11 | mingwandroid | so codyps said that newlib {doesn't need to be|isn't} built for multilib? |
| # 21:29:11 | tlwoerner | it's just a one character change |
| # 21:29:28 | tlwoerner | mingwandroid: newlib is being built for multilib |
| # 21:29:33 | y_morin | tlwoerner: We were om Buildroot-release spree the past few days, so I focused on that... |
| # 21:29:45 | mingwandroid | tlwoerner: with different CFLAGS per each variant? |
| # 21:29:45 | tlwoerner | mingwandroid: but newlib is smarter and doesn't need all the fixups that {e}glibc needs |
| # 21:30:03 | mingwandroid | tlwoerner: does it build for some lowest common denominator? |
| # 21:31:06 | tlwoerner | mingwandroid: how would i tell? by looking at the build log? what i know is that when it is done there are multiple crt0.o files in multiple architecture directories :-) |
| # 21:31:35 | mingwandroid | not crt0.o, that's core GCC, more libm.a for example. |
| # 21:32:03 | mingwandroid | GCC will definitely do a per-multilib build, but in a different folder layout than the sysroot layout, annoyingly. |
| # 21:33:34 | tlwoerner | ./arm-unknown-eabi/sysroot/lib/armv6-m/libm.a |
| # 21:33:34 | tlwoerner | ./arm-unknown-eabi/sysroot/lib/libm.a |
| # 21:33:34 | tlwoerner | ./arm-unknown-eabi/sysroot/lib/thumb/libm.a |
| # 21:33:34 | tlwoerner | ./arm-unknown-eabi/sysroot/lib/armv7e-m/libm.a |
| # 21:33:34 | tlwoerner | ./arm-unknown-eabi/sysroot/lib/armv7e-m/fpu/libm.a |
| # 21:33:35 | tlwoerner | ./arm-unknown-eabi/sysroot/lib/armv7e-m/softfp/libm.a |
| # 21:33:37 | tlwoerner | ./arm-unknown-eabi/sysroot/lib/armv7-m/libm.a |
| # 21:33:39 | tlwoerner | ./arm-unknown-eabi/sysroot/lib/fpu/libm.a |
| # 21:33:43 | tlwoerner | ./arm-unknown-eabi/sysroot/lib/armv7-ar/thumb/libm.a |
| # 21:33:45 | tlwoerner | ./arm-unknown-eabi/sysroot/lib/armv7-ar/thumb/fpu/libm.a |
| # 21:33:47 | tlwoerner | ./arm-unknown-eabi/sysroot/lib/armv7-ar/thumb/softfp/libm.a |
| # 21:34:13 | bhundven | hears y_morin pass out |
| # 21:34:17 | y_morin | tlwoerner: Please use a pastebin site to paste more than 3-4 lines... |
| # 21:34:21 | y_morin | bhundven: ;-) |
| # 21:34:34 | tlwoerner | haha, sorry |
| # 21:34:41 | y_morin | bhundven: You know me well! ;-) |
| # 21:34:48 | y_morin | tlwoerner: no problem. ;-) |
| # 21:38:44 | tlwoerner | mingwandroid: yes, there are per-architecture flags for each multilib when building newlib |
| # 21:38:50 | tlwoerner | (looking through the log file) |
| # 21:38:59 | tlwoerner | i'll post it... would here be okay? ;-) |
| # 21:39:29 | mingwandroid | tlwoerner: ok. It's many years since I dealt with newlib (apart from in Cygwin/MSYS2) .. |
| # 21:39:51 | mingwandroid | does newlib ask GCC for the details then? |
| # 21:41:26 | tlwoerner | mingwandroid: i'm new to being at this level myself :-) |
| # 21:41:38 | tlwoerner | i'm just preparing the newlib part of the build log so you can have a look |
| # 21:44:28 | bhundven | tlwoerner: personally, I'm really excited to see newlib+multilib+cortex-m{0,1,2,3...} |
| # 21:44:42 | bhundven | I have a few of those |
| # 21:45:14 | bhundven | I was just trying to handle some of the easier (e)glibc variants/architectures before getting to arm |
| # 21:45:29 | bhundven | and newlib was an unknown to me |
| # 21:45:41 | bhundven | and we've also been talking about mucl |
| # 21:45:42 | tlwoerner | instead of pastebin, how does one share a file? |
| # 21:45:55 | mingwandroid | paste.kde.org for me. |
| # 21:46:07 | bhundven | less limit on size |
| # 21:46:58 | tlwoerner | but again, that requires me to cut and past the whole file, how do i just upload the file? |
| # 21:47:15 | mingwandroid | tlwoerner: dropbox is an option? |
| # 21:47:22 | bhundven | google drive |
| # 21:47:28 | bhundven | mediafire |
| # 21:47:41 | mingwandroid | does google drive support linux yet? |
| # 21:47:48 | bhundven | ugh, kinda |
| # 21:47:54 | bhundven | well, not by google |
| # 21:47:55 | bhundven | :) |
| # 21:48:38 | mingwandroid | ffs. come on google! |
| # 21:48:41 | tlwoerner | linux is all i use, and we use google drive all the time (the linaro email system is actually a corporate gmail account) |
| # 21:49:26 | mingwandroid | tlwoerner: well, I'm asking about a client like dropbox .. shell integration for popular file managers, the usual nicities that DB give us |
| # 21:49:47 | bhundven | there are some different fusefs addons |
| # 21:49:53 | tlwoerner | ah, no. just web interface |
| # 21:54:03 | tlwoerner | https://drive.google.com/file/d/0B3mtE9WJovhfSGI0M0ZreUdyV2M/edit?usp=sharing |
| # 21:54:20 | tlwoerner | man... you guys are fast! |
| # 21:55:04 | tlwoerner | what you must remember is that the sources for this build come from the gcc-arm-embedded project |
| # 21:55:16 | tlwoerner | so i'm not sure if they've done anything to help things along |
| # 21:55:21 | bhundven | I may be fast, but my connection is teh slowz |
| # 21:55:23 | tlwoerner | obviously they've done some multilib work |
| # 21:59:38 | bhundven | wholy smokes |
| # 21:59:51 | tlwoerner | bhundven: i agree, i'm looking forward to doing much more cortex-M work too, and i've got a couple boards lined up |
| # 22:00:29 | mingwandroid | quits : Read error: Connection reset by peer |
| # 22:01:08 | bhundven | that is a serious ./configure line |
| # 22:01:49 | mingwandroid | joins #crosstool-ng |
| # 22:02:01 | mingwandroid | [ALL ] Checking multilib configuration for newlib... |
| # 22:02:01 | mingwandroid | [ALL ] Checking multilib configuration for libgloss... |
| # 22:02:11 | bhundven | looks at his coffee, thinks he should be on crack |
| # 22:02:56 | mingwandroid | [ALL ] Adding multilib support to Makefile in /home/trevor/devel/arm/toolchains/crosstool-ng/mercurial/work-area/newlib-test/_build/src/newlib-custom/libgloss |
| # 22:03:18 | mingwandroid | .. so yeah, newlib does the stuff we've added by the look of it .. clever newlib, clap clap. |
| # 22:03:29 | bhundven | hmm |
| # 22:04:20 | tlwoerner | from the sounds of it, the gcc-arm-embedded people have pretty much taken over maintainership of newlib |
| # 22:04:33 | tlwoerner | they even have their own "newlib-nano" they're working on too |
| # 22:04:37 | tlwoerner | https://answers.launchpad.net/gcc-arm-embedded/+question/244125 |
| # 22:06:13 | bhundven | bleh, not open though |
| # 22:06:49 | tlwoerner | but the sources are available (for each release) |
| # 22:07:03 | bhundven | I wish linaro would work on (e)glibc multilib... |
| # 22:07:08 | bhundven | hehe |
| # 22:07:30 | bhundven | make it that easy |
| # 22:07:34 | bhundven | er as newlib |
| # 22:07:59 | tlwoerner | bhundven: if you find a customer willing to pay for it, linaro will do anything :-) |
| # 22:08:17 | bhundven | looks in his pocket, pulls out $2 USD |
| # 22:08:22 | bhundven | :( |
| # 22:08:33 | bhundven | lol |
| # 22:08:59 | tlwoerner | :-D |
| # 22:09:48 | bhundven | maybe when this startup pays off... |
| # 22:10:01 | bhundven | s/when/if/ |
| # 22:16:59 | tlwoerner | i believe the gcc-arm-toolchain people push their code upstream, so this work is being done (at least for the cortex-M case) |
| # 22:17:10 | tlwoerner | linaro tends to focus on the cortex-A space |
| # 22:28:25 | smartin_ | joins #crosstool-ng |
| # 22:51:34 | bhundven | tlwoerner: I'm really happy with this efm32 dk3750gg http://www.silabs.com/products/mcu/lowpower/Pages/efm32gg-dk3750.aspx |
| # 22:51:47 | bhundven | fun project board |
| # 22:53:36 | bhundven | these guys are trying to port linux to it: http://lwn.net/Articles/476996/ |
| # 23:01:43 | sh4rm4 | gotta love arm boards where you need special kernel support for each of them |
| # 23:01:53 | sh4rm4 | bios ftw |
| # 23:02:03 | bhundven | hehe |
| # 23:05:32 | bhundven | sh4rm4: and in turn, gotta love arm fragmentation |
| # 23:05:57 | bhundven | not saying energymicro/siliconlabs is helping there. |
| # 23:06:37 | sh4rm4 | honestly i wouldnt have bought my arm netbook had i known earlier how much hacking it needs |
| # 23:07:01 | sh4rm4 | and that i need to use an old unmaintained 2.6.31 kernel with a ton of custom patches |
| # 23:07:12 | bhundven | which netbook? |
| # 23:07:15 | sh4rm4 | efika mx |
| # 23:07:51 | bhundven | seems like a good candidate for chromeos |
| # 23:08:10 | sh4rm4 | just that half of the drivers didnt go upstream |
| # 23:08:15 | bhundven | ah |
| # 23:08:22 | sh4rm4 | so youre stuck with the olde kernel |
| # 23:08:45 | bhundven | well, it's a good spot to be in, if you want to become a kernel contributor |
| # 23:08:46 | sh4rm4 | unless you have a lot of time to port patches to recent |
| # 23:08:54 | bhundven | yup |
| # 23:10:10 | bhundven | I've given a few stabs at trying to port this s5pc110 android device (SGH-T959V, based on nexus s (crespo)) to newer kernels. it's painful. |
| # 23:10:35 | bhundven | without jtag anyway |
| # 23:11:18 | bhundven | we have a 2.6.35.x and 3.0.x kernel, but samsung really did a lame coding job. |
| # 23:11:59 | sh4rm4 | the only thing my netbook is good at is battery life and noise. but it's dead slow, nearly no ram, buggy kernel, minimal resolution, no ethernet on board, only 16gflash... |
| # 23:12:15 | sh4rm4 | an atom netbook would've been 10x more useful for the same price |
| # 23:12:37 | sh4rm4 | compiling webkitgtk took 2.5 days |
| # 23:12:38 | bhundven | that target (atom) has changed a lot though. started with lpia |
| # 23:13:03 | bhundven | remembers his Samsung Q1U |
| # 23:13:16 | bhundven | lost to the pawn shop |
| # 23:13:19 | sh4rm4 | afaik you can use a vanilla kernel with any atom device |
| # 23:13:24 | bhundven | yup |
| # 23:14:18 | bhundven | but for better efficiency, there are some toolchain optimizations you can use. |
| # 23:14:45 | bhundven | linux pm doesn't take advantage of it though |
| # 23:14:56 | bhundven | same with the efm32 |
| # 23:15:06 | bhundven | super low power states |
| # 23:19:22 | bhundven | I've wanted to get an arm netbook, but I'm waiting for ssd to go down in price and up in capacity |
| # 23:19:47 | sh4rm4 | well i'd actually prefer a proper drive |
| # 23:19:50 | sh4rm4 | 1 TB or so |
| # 23:19:59 | sh4rm4 | so you can store a lot of games on it |
| # 23:20:17 | sh4rm4 | mame roms, nes roms, etc |
| # 23:20:52 | bhundven | hehe |
| # 23:21:05 | bhundven | I play nes roms on my psp :D |
| # 23:21:13 | sh4rm4 | :) |
| # 23:47:33 | smartin_ | quits : Write error: Broken pipe |