ibotlog2html for #crosstool-ng

<< Previous 2012-05-06 Next >>

# 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!

Generated by ibotlog2html by Yann E. MORIN