| # 04:12:26 | tzarc | joins #crosstool-ng |
| # 04:13:35 | tzarc | evening folks |
| # 04:13:56 | tzarc | don't suppose anyone knows of a solution for: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. ? |
| # 04:14:53 | tzarc | trying x86_64 -> arm, but it fails during the cc_for_host stage |
| # 08:07:37 | arekinath | quits : Read error: Operation timed out |
| # 08:11:17 | arekinath | joins #crosstool-ng |
| # 08:28:53 | kos_tom | tzarc: Yann was having the same problem yesterday. I'd guess that if he has time today, he'll look into this. |
| # 08:30:03 | tzarc | cool. had a look at the logs and saw it, attempting to work my way around it with script modification |
| # 08:30:17 | tzarc | will feed it back if I can get it sorted I guess |
| # 08:59:21 | tzarc | mmm, well it seems to be working now |
| # 08:59:28 | tzarc | kinda heavy-handed approach though |
| # 09:49:43 | arekinath | quits : Ping timeout: 250 seconds |
| # 09:50:56 | arekinath | joins #crosstool-ng |
| # 09:50:56 | arekinath | quits : Changing host |
| # 09:50:56 | arekinath | joins #crosstool-ng |
| # 12:40:03 | y_morin | joins #crosstool-ng |
| # 13:10:27 | y_morin | Hello! Any idea how the new armhf tuples should be interpreted? |
| # 13:10:45 | y_morin | Eg. arm-unknown-linux-gnueabihf is valid |
| # 13:10:59 | y_morin | but what about arm-unknown-linux-uclibcgnueabihf ? |
| # 13:15:08 | tzarc | that doesn't really make sense, does it? |
| # 13:15:16 | tzarc | it'd be uclibchf, no? |
| # 13:15:27 | tzarc | gnu matches glibc? |
| # 13:16:21 | y_morin | tzarc: not really, in fact. The proper EABI tuple for ARM and uclibc is arm-unknown-linux-uclibcgnueabi |
| # 13:16:54 | y_morin | tzarc: GNU is everywhere... ;-] |
| # 13:16:57 | kos_tom | just curious, how do you know which tuple is correct for a particular configuration? is there a specification of existing tuples somewhere? |
| # 13:17:08 | tzarc | hmmmm |
| # 13:17:22 | y_morin | kos_tom: the config.guess and config.sub scripts are the soecs, I gues... :-/ |
| # 13:17:28 | y_morin | *specs... |
| # 13:17:56 | y_morin | http://git.savannah.gnu.org/gitweb/?p=config.git |
| # 13:18:36 | kos_tom | urgh, what a spec :-( |
| # 13:18:43 | y_morin | Yep... |
| # 13:35:26 | tzarc | I was looking at sorting out the "Link tests are not allowed after GCC_NO_EXECUTABLES." error earlier today |
| # 13:36:26 | tzarc | for LE arm, just need to suppress "-EL" in do_cc_backend() |
| # 13:36:33 | ccole | joins #crosstool-ng |
| # 13:49:26 | y_morin | tzarc: -EL is set in scripts/functions on line 980. |
| # 13:49:47 | tzarc | yep, but stage 2 fails if you remove it there |
| # 13:49:56 | y_morin | -EL is a valid ld flag. Alas, the fscking autostuff inisist on callin 'gcc' as the linker. Gah... |
| # 13:50:09 | tzarc | mmmm |
| # 13:50:14 | y_morin | tzarc: that's even weirder. stage-2 builds with -EL, final does not. WTF? |
| # 13:50:27 | tzarc | I know, eh |
| # 13:50:29 | y_morin | :-) |
| # 13:50:30 | tzarc | makes no sense |
| # 16:24:36 | y_morin | tzarc: thank you for the -EL hint. I have a patch here that I am testing, and preliminary tests seem to be conclusive! Thanks! |
| # 16:25:03 | y_morin | kos_tom: seems we are on the verge of fixing the gcc-4.7 build. |
| # 16:25:20 | kos_tom | y_morin: ah ah? |
| # 16:25:43 | kos_tom | I don't *need* it myself, but I guess being able to build 4.7 in ct-ng will be useful at some point in the future :) |
| # 16:25:58 | y_morin | kos_tom: yep, tzarc said that removing -EL in LDFLAGS made final gcc-4.7 build OK, but that core pass-2 needed it. |
| # 16:26:12 | y_morin | kos_tom: So I replace -EL witj -WL,-EL, and it builds! :-) |
| # 16:27:18 | y_morin | Tss... keyboard-dyslexia... |
| # 16:27:33 | kos_tom | doesn't this sounds a bit hackish? is the fundamental reason understood? |
| # 16:28:17 | y_morin | kos_tom: not yet fully understood, indeed, but at least we at least have a direction to follow, now! :-) |
| # 16:30:14 | kos_tom | just curious, do you know why the Linaro guys have moved libstdc++, libgcc_so and other gcc libraries outside of the sysroot since 2012.03 ? |
| # 16:30:50 | y_morin | In there pre-built toolchain? |
| # 16:30:54 | y_morin | *their |
| # 16:31:35 | kos_tom | yes |
| # 16:32:10 | y_morin | I did not look at their toolchain, but I supposed they moved it to the libexec sub-dir, right? |
| # 16:33:57 | kos_tom | I guess it's related to the "Subject: GCC support libraries and sysroot |
| # 16:33:58 | kos_tom | " |
| # 16:33:59 | kos_tom | thread |
| # 16:34:01 | kos_tom | on the crossgcc list |
| # 16:37:51 | y_morin | kos_tom: OK, I remember that thread. The fact that those libs are in the sysroot is not the "standard" layout. |
| # 16:38:34 | y_morin | kos_tom: the canonical layout is to have those "support" libs in their own dir, and the sysroot would only contain the C library libs |
| # 16:38:53 | y_morin | Which would make it easy to replace the sysroot with an alternate one. |
| # 16:39:40 | y_morin | In the beginings of ct-ng, that "canonical" layout was not working (probably because of a bug in ct-ng), but I noticed that: |
| # 16:40:03 | y_morin | - having all the taget libs in the sysroot made the build work (that not a reason for doing so, though) |
| # 16:40:39 | y_morin | - I found it stupid to have target libs outside the sysroot |
| # 16:41:09 | kos_tom | ok, so it doesn't sound crazy for BR to support the case where the support libs are outside the sysroot, right? |
| # 16:42:12 | y_morin | kos_tom: I'd say ct-ng is not doing things properly from an "academic" point-of-view. So yes, BR (like other build systems) should be able to cope with the fact that those libs could be {any,some}where else. |
| # 16:42:53 | kos_tom | basically, I could do a gcc -print-file-name=libstdc++.a and assume that this is the "support libraries" directory, correct ? |
| # 16:42:57 | y_morin | kos_tom: the best bet would be to ask gcc with: gcc -print-file-name=... |
| # 16:43:20 | kos_tom | so I do one -print-file-name=libc.a to get the sysroot, and another -print-file-name=libstdc++.a to get the support lib directory |
| # 16:43:26 | y_morin | kos_tom: I'd do it for every needed lib, and copy the pointed-to lib |
| # 16:43:28 | kos_tom | and then I can merge both into the BR sysroot |
| # 16:43:41 | kos_tom | well, for the sysroot, we don't copy lib-per-lib, we copy the whole thing |
| # 16:43:51 | kos_tom | we do lib-per-lib copy for the target |
| # 16:44:51 | y_morin | kos_tom: remind me why you need to copy the sysroot in the first place? Is that because you override its location with --sysroot=... ? |
| # 16:45:04 | y_morin | At the sysroot you point to is the staging area? |
| # 16:45:11 | y_morin | *And... |
| # 16:45:38 | kos_tom | right |
| # 16:48:51 | y_morin | kos_tom: they've gone one step further in 2012-04: the libc is not even installed in the sysroot... :-/ |
| # 16:48:59 | y_morin | bin/arm-linux-gnueabi-gcc -print-file-name=libc.so |
| # 16:49:07 | y_morin | gcc-linaro-arm-linux-gnueabi-2012.04-20120426_linux/bin/../arm-linux-gnueabi/libc/usr/lib/arm-linux-gnueabi/libc.so |
| # 16:49:15 | y_morin | (stripped leading path) |
| # 16:49:31 | y_morin | kos_tom: notice where it finds the libc.so? |
| # 16:49:40 | y_morin | yep, it's a linker script, but anyway... |
| # 16:50:29 | y_morin | The real libc.so is just side-by-side with this linker script... |
| # 16:50:50 | y_morin | And there is no sysroot anymore... :-( |
| # 19:28:02 | ben1066 | quits : Ping timeout: 246 seconds |
| # 19:29:15 | ben1066 | joins #crosstool-ng |
| # 20:50:55 | ben1066_ | joins #crosstool-ng |
| # 20:53:52 | ben1066 | quits : Ping timeout: 276 seconds |
| # 22:44:14 | y_morin | kos_tom: OK, I have a patch locally that uses savedefconfig, now! |
| # 22:44:46 | y_morin | kos_tom: I have other pending changes to test, and I'll push all that tomorrow, after some testing. |
| # 22:45:04 | y_morin | kos_tom: and indeed, savedefconfig makes for much smaller .config files! Yeah! \o/ |
| # 23:06:47 | y_morin | quits : Quit: Night! |