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