ibotlog2html for #crosstool-ng

<< Previous 2011-10-09 Next >>

# 03:10:31 mnt_real quits : Quit: Leaving
# 09:35:43 smartin joins #crosstool-ng
# 09:51:01 y_morin joins #crosstool-ng
# 10:13:12 sinseman44 joins #crosstool-ng
# 10:13:34 sinseman44 /quiit
# 10:13:39 sinseman44 quits : Client Quit
# 11:05:48 y_morin is now known as: y_morin|away
# 12:44:50 friggle joins #crosstool-ng
# 12:50:08 friggle so I have a compile environment (for ARM) that I can chroot in to, using qemu-arm-static user-mode emulation, triggered for every ARM ELF using binfmt_misc
# 12:50:25 friggle and I'd like to build an x86 toolchain with ARM target to run in this environment
# 12:51:13 friggle so the 1st requirement is it's totally static, and secondly it would ideally use all the same library search paths and so on that the native ARM gcc would
# 12:52:36 friggle how can I build a fully-static toolchain with crosstool-ng?
# 12:57:16 y_morin|away is now known as: y_morin
# 14:32:27 sh4rm4 friggle, by using uclibc and the appropriate settings
# 14:34:06 ccole joins #crosstool-ng
# 14:35:23 ccole I am using latest crosstool-ng, and running into a problem while building glibc-2.14. The configure script keeps running over and over, until eventually the crosstool-ng dies with "too many open files". I am running Ubuntu 32-bit. Is there a workaround for this?
# 14:36:26 sh4rm4 ccole, by studying what configure does... and fixing it... or using another version ?
# 14:37:29 ccole sh4rm4: I have tried other versions of glibc (2.12.2) and get the same problem.
# 14:38:04 ccole sh4rm4: Before investing the time to stucy the configure, I was hoping this might be a known issue with a known workaround? From what I can tell, there appears to be a common problem between Ubuntu and crosstool-ng.
# 14:38:36 sh4rm4 hmm you just need to look at config.log
# 14:39:28 sh4rm4 what's special about ubuntu/debian is that they use /bin/dash instead of /bin/bash as standard sh symlink
# 14:39:51 sh4rm4 so that may be a possible cause
# 14:40:35 y_morin ccole: that's a known issue, and it is under investigations...
# 14:40:57 y_morin ccole: the issue so far occurs only on ubuntu.
# 14:41:17 y_morin ccole: the workaround (an ugly one, but it works):
# 14:41:27 y_morin ccole: 1) go to the menuconfig
# 14:41:58 y_morin ccole: 2) Paths and misc options ---> [*] Debug crosstool-NG
# 14:42:10 y_morin ccole: 3) [*] Save intermediate steps
# 14:42:27 y_morin ccole: 4) rebuild the toolchain: ct-ng build
# 14:43:01 y_morin ccole: 5) when it starts the 'headers and start files' step, Press Ctrl-C
# 14:43:26 y_morin ccole: 6) then ask to restart the build: ct-ng libc_start_files+ (Notice the trailing '+')
# 14:43:33 y_morin ccole: this should work.
# 14:43:56 sh4rm4 does it just skip building the start files ?
# 14:44:12 y_morin sh4rm4: nope, it just restarts at that step.
# 14:44:24 sh4rm4 and why does it work after a restart ?
# 14:44:31 y_morin sh4rm4: there is something that is 'leaking' from a previous step that breaks the build.
# 14:44:41 sh4rm4 interesting
# 14:44:48 y_morin sh4rm4: I just did not manage to see what is leaking...
# 14:45:29 y_morin sh4rm4: yes, it is... interesting, to say the least...
# 14:45:30 ccole @y_morin: Thank you very much!
# 14:45:31 y_morin :-)
# 14:45:52 y_morin ccole: If you can invest a bit of time looking at it, that would be much appreciated!
# 14:46:17 sh4rm4 it'd probably help to look at config.log to see which step loops
# 14:46:50 ccole @y_morin: Sure. I was looking through the build.log and saw several strange things. I will investigate.
# 14:46:52 y_morin sh4rm4: well, that has been identified, but the reason it does loop is still a mystery...
# 14:47:06 sh4rm4 maybe some changed ulimit ?
# 14:47:26 y_morin sh4rm4: a more plausible reason would be a variable leak...
# 14:47:40 ccole sh4rm4: Na, it loops until ulimit is reached. Perhaps max open files should ne *decreased* if anything to help expose the problem.
# 14:47:53 y_morin sh4rm4: I'll try a few changes here, where each step in crosstoll-Ng is run in its own sub-shell...
# 14:48:03 ccole sh4rm4: I think that increasing max open files wil only delay the inevitable :(
# 14:48:05 y_morin ccole: exactly.
# 14:48:39 y_morin But first, I have a gdb+Python issue to tackle. After I get my hourly nicotine dose... :-/
# 14:49:18 sh4rm4 gdb doesnt also build using a static-only buildchain...
# 14:50:06 ccole @y_morin: Your work on crosstool-ng is very much appreciated! A comprehensive cookbook on how to build all these toolchains is a fast moving target and is a full time job to keep on top of.
# 14:58:47 y_morin is now known as: y_morin|away
# 15:01:30 y_morin|away is now known as: y_morin
# 15:02:02 y_morin sh4rm4: yes it does. Here. I have a patch I'm working on! :-p
# 15:02:07 y_morin ccole: Thanks! :-)
# 15:19:37 kos_tom y_morin: I did 'sudo debootstrap --arch i386 lenny lenny-32'
# 15:20:13 y_morin kos_tom: yeah, I did the same. But do you remember your 32-bit vs. 64-bit issues, in GMP of MPFR ?
# 15:20:55 kos_tom yeah, I had to pass ABI=32
# 15:21:05 kos_tom I guess it was for GMP
# 15:21:11 y_morin kos_tom: Ah. Thanks...
# 15:49:13 y_morin is now known as: y_morin|away
# 16:51:29 smartin quits
# 16:53:43 y_morin|away is now known as: y_morin
# 17:25:57 ccct Wow another ubuntu'er with the loop. The issue is becoming hot! :)
# 17:26:36 y_morin ccct: I'm on it...
# 17:29:44 y_morin ccct: in case you have a bit of time ahead of you, could you test this patch: http://code.bulix.org/84ysd4-80674
# 17:30:01 y_morin ccct: ditto ^^^^^^
# 17:30:24 y_morin ccole: ditto ^^^^^^ (Damn autocomplete, it completed the wrong nicjname)
# 17:30:34 y_morin *nickname
# 17:32:37 ccct I will try, but by comp is slow so it will take a few hours.
# 17:33:19 y_morin ccct: no problem, I like reports from others, because it working here is not enough.
# 17:53:34 y_morin ccct: no need to further test this. I have a case still failing here... :-(
# 17:56:02 ccct y_morin: Ok, I'll cancel the build.
# 17:56:25 y_morin ccct: this is a tough issue. Takes quite a time testing fixes... :-(
# 17:56:34 y_morin ccct: thanks for your help. :-)
# 17:57:01 ccct :)
# 18:18:37 y_morin ccct: OK, I have some clue here. The only difference between the failing run, and the working restarted run is the CONFIG_SHELL variable.
# 18:19:18 y_morin ccct: in the failing case, it is set (and this is expected!), but on the working run, it is unset (and it is unexpected...)
# 18:19:28 y_morin ccct: more after dinner...
# 18:19:32 y_morin is now known as: y_morin|away
# 18:34:43 ccct /bin/sh -> dash on ubuntu
# 18:35:08 ccct many issues with dash found on google. (& with libtool), not sure if related
# 18:36:56 sh4rm4 which by itself is retarded, but help finding portability issues.
# 18:37:01 sh4rm4 *helps
# 21:24:12 y_morin|away is now known as: y_morin
# 21:40:39 mnt_real joins #crosstool-ng
# 22:14:37 y_morin ccole, ccct: OK, the loop issue has been definitely identified! Yeah! :-)
# 22:15:14 y_morin ccole, ccct: It is due to a mishap with the CONFIG_SHELL variable being _properly_ set on the first run, but failing with Ubuntu
# 22:16:46 y_morin ccole, ccct: the value of this variable tells configure what shell to use when running its tests. Usually, using bash is what one wants, as using dash can break on some packages (yes, ./ocnfigure scripts are full of bashisms. although they should not be...)
# 22:18:40 y_morin ccole, ccct: I'm investigating a fix for this issue, but that may well wait for later in the week...
# 22:48:52 y_morin quits : Quit: Nity Might!

Generated by ibotlog2html by Yann E. MORIN