ibotlog2html for #crosstool-ng

<< Previous 2011-10-04 Next >>

# 01:10:36 mnt_real quits : *.net *.split
# 01:10:40 sh4rm4 quits : *.net *.split
# 01:10:40 KAeL quits : *.net *.split
# 01:10:41 kos_tom quits : *.net *.split
# 01:10:41 al` quits : *.net *.split
# 01:10:46 ChanServ quits : *.net *.split
# 01:13:24 al` joins #crosstool-ng
# 01:13:25 mnt_real joins #crosstool-ng
# 01:13:25 kos_tom joins #crosstool-ng
# 01:13:25 sh4rm4 joins #crosstool-ng
# 01:13:25 KAeL joins #crosstool-ng
# 01:13:25 ChanServ joins #crosstool-ng
# 06:23:10 mnt_real quits : Quit: Leaving
# 13:47:30 mnt_real joins #crosstool-ng
# 16:59:19 y_morin joins #crosstool-ng
# 17:41:28 ccct joins #crosstool-ng
# 17:42:46 ccct crosstools tries to download glibc-ports-2.14.tar.gz but there is no such thing, what to do?
# 17:43:57 ccct And there is no ftp.de.kernel.org ... and ftp.eu.kernel.org is empty.
# 17:46:06 y_morin is now known as: y_morin|away
# 18:03:36 ccct parts #crosstool-ng
# 19:46:40 mnt_real_ joins #crosstool-ng
# 20:36:00 y_morin|away is now known as: y_morin
# 21:00:15 y_morin Sazpaimon_: Hey! Did you manage to solve your eglibc issue?
# 21:12:17 mnt_real_ quits : Read error: Connection reset by peer
# 21:37:42 ccct joins #crosstool-ng
# 21:41:53 ccct Is there a way to resume a build, rather than starting all over? I keep failing, but wasting hours trying to fix it and continue.
# 21:52:03 ccct Seems not. So frustrating.
# 21:52:45 y_morin ccct: what's the problem you have? If you don;t tell us, we can't help...
# 21:54:32 ccct This is the error: http://pastebin.com/yECAYkSP
# 21:54:52 ccct This is the .config file: http://archlinuxarm.org/mirror/development/ct-ng/xtools-dotconfig-v7
# 21:56:08 ccct And trying to build it again (ct-ng build), it rebuilds libgomp, ppl, etc, which seems unnecessary and is taking a lot of time.
# 21:57:03 y_morin ccct: if you do *not* change the config, you can restart a build:
# 21:57:36 y_morin 1) gp to Paths and misc options --->
# 21:57:54 y_morin 2) select [*] Debug crosstool-NG
# 21:58:04 y_morin 3) select [*] Save intermediate steps
# 21:58:16 y_morin 4) build it normally: ct-ng build
# 21:59:04 y_morin 5) if it breaks, you can restart with: ct-ng STEP+ (where STEP is the last step crosstool-Ng said it saved)
# 21:59:18 y_morin But it is *not* possible to restart if the config changes.
# 21:59:30 y_morin ccct: I'll try your .config here...
# 21:59:52 ccct Those options are already set in that .config file
# 22:00:08 ccct but ct-ng build is rebuilding ppl at the moment.
# 22:00:08 y_morin ccct: read: ct-ng help
# 22:00:14 ccct That config file is from archlinux.
# 22:00:36 y_morin ccct: you have to *ask* ct-ng to rstart by specifying what step to restart at
# 22:00:51 y_morin ccct: what version of crosstool-NG are you using?
# 22:01:19 ccct ct-ng-1.12.3
# 22:02:13 y_morin ccct: OK, testing here...
# 22:03:14 y_morin ccct: Oh, I see you had issue with the glibc ports addon. It's not available as a tarball, you have to "get it" from the repository...
# 22:03:14 ccct y_morin: I had to build my own tarballs/glibc-ports-2.14.tar.bz2
# 22:03:33 y_morin ccct: yes, the glibc guys suck at making actual releases... :-(
# 22:04:06 ccct But, as you can see from the pastebin, I get a "Too many open files" which I am guessing causes the error?
# 22:04:44 ccct /home3/incoming/cross3/.build/src/glibc-2.14/ports/sysdeps/arm/elf/configure: 43: 0: Too many open files
# 22:06:02 Sazpaimon_ y_morin, I thought I did, but apparently not
# 22:06:14 y_morin ccct: what does ulimit -a
# 22:06:18 y_morin ..says?
# 22:06:34 Sazpaimon_ I successfully compiled the toolchain, yes, but I'm getting versioning issues when I run compiled programs on the target device
# 22:06:50 Sazpaimon_ http://pastebin.com/PkbXpMfj
# 22:07:17 ccct y_morin: ulimit -a: http://pastebin.com/72kHS0ru
# 22:07:33 Sazpaimon_ http://pastebin.com/LgudHY9P with a comparison of the prebuilt toolchain (cs2007q3-glibc2.5-arm7) vs mine (arm-unknown-linux-gnueabi)
# 22:07:42 Sazpaimon_ did I miss any options when I built my toolchain?
# 22:08:32 y_morin ccct: what's the machine you're building on?
# 22:08:43 y_morin Sazpaimon_: lemme get up to speed on this...
# 22:09:12 ccct y_morin: old ubuntu linux
# 22:09:45 Sazpaimon_ y_morin, essentially, my end goal is to build a toolchain exactly like the prebuilt one, but with gcc 4.4 instead of 4.2
# 22:10:00 Sazpaimon_ whilst still being able to run binaries on the target device
# 22:10:17 y_morin Sazpaimon_: did you recompile 'lightspark' with the new toolchain?
# 22:10:23 Sazpaimon_ y_morin, yes
# 22:10:35 y_morin Sazpaimon_: annd all the other libs (libxml...)
# 22:10:44 Sazpaimon_ lightspark will only compile with gcc 4.4
# 22:10:46 Sazpaimon_ also yes
# 22:11:12 y_morin ccct: lemme look at the build here...
# 22:11:15 Sazpaimon_ in the second link you can see the versions supplied by the old toolchain
# 22:12:12 y_morin Sazpaimon_: This smells like the library that were used to build the binary are not the one it runs against.
# 22:12:31 y_morin Sazpaimon_: did you replace the libraries on the target with the newer ones?
# 22:12:43 Sazpaimon_ y_morin, I'm running the programs on a different device than the one I compiled it on
# 22:13:52 Sazpaimon_ the toolchain is being compiled for scratchbox
# 22:14:00 y_morin Sazpaimon_: yes, of course. I mean, did you move the newly-built libxml++ and the new libc to the target?
# 22:14:35 Sazpaimon_ I didn't move the new libc to the new target device
# 22:14:43 Sazpaimon_ i was hoping that could be avoided..
# 22:14:55 y_morin Sazpaimon_: it can't.
# 22:15:18 y_morin Sazpaimon_: as you linked your binaries and other libs against the new libc (and libstdc++) you have to use those versions
# 22:15:49 Sazpaimon_ I used the same eglibc as the old toolchain has, though
# 22:16:35 y_morin Sazpaimon_: it's mostly libstdc++ that is yelling here. libstdc++ is really picky, you *have* to use the same one at runtime and at build time
# 22:16:58 y_morin Sazpaimon_: and mixing libc is not really possible either.
# 22:17:50 y_morin Sazpaimon_: it _may_ have worked the other way around, building with an older libc and running with a newer one, but not at all for libstdc++. ABI changes with every version...
# 22:18:22 Sazpaimon_ so I have to package these c++ and libgcc libraries and hope/pray that it doesn't break everything else on the device
# 22:18:23 y_morin Sazpaimon_: and BTW, libstdc++ comes from gcc, not the C library. So, as you upgraded gcc, you upgraded libstdc++ as well...
# 22:18:52 y_morin Sazpaimon_: if you have other C++ apps on the devioce, it *will* break. libstdc++ is not backward nor forward compatible.
# 22:19:13 Sazpaimon_ well, that's a bummer
# 22:19:29 Sazpaimon_ I dont see any way of getting this resolved, then
# 22:20:05 ccct -static -static-libgcc
# 22:20:29 y_morin Sazpaimon_: if you are really, really, and I mean *really* REALLY adventurous, you *may* tru chrooting your "lightspark" app
# 22:20:44 y_morin ccct: for Sazpaimon_'s issue?
# 22:21:04 ccct y_morin: I don't know his issue, just throwing it out there..
# 22:21:22 Sazpaimon_ y_morin, that wont work, because It also comes with a browser plugin
# 22:21:25 y_morin ccct: well, the build does work nicely here, with 18 jobs in parallel, so it seems you have hit some ulimits on your machine.
# 22:21:30 Sazpaimon_ so it'd need to run in a browser too
# 22:21:58 y_morin ccct: So what is this '-static -static-libgcc' for, then?
# 22:22:19 y_morin Sazpaimon_: or you could rebuild everything on the device...
# 22:23:06 ccct y_morin: When I have libc/libstdc++ compat issues, I just compile the app statically. But it might not be appropriate in his case, not sure.
# 22:23:08 Sazpaimon_ y_morin, the device has lots of closed and proprietary programs like drivers
# 22:23:29 y_morin Sazpaimon_: kill those binary blobs with a flamethrower! :-p
# 22:23:42 ccct y_morin: so your build completed? maybe my glibc-ports-2.14.tar.bz2 isn't correct. What is your "uname -a"?
# 22:23:52 ccct err, ulimit -a
# 22:23:53 Sazpaimon_ also, if libstdc++ isn't backwards compatible, why does it supply all the old version strings>
# 22:24:07 y_morin ccct: indeed, that might not be possible here, (s)he needs to create a plugin for a browser, so it's a .so.
# 22:24:43 y_morin Sazpaimon_: not really sure. I know from experience that it does not really work every time.
# 22:25:58 y_morin ccct: usually, 1024 file descriptors are far enough, even for modern desktops environements (using KDE4 on Debian squeeze here, and never got out of FDs...)
# 22:26:50 ccct y_morin: Then I'm not sure why mine fails.
# 22:27:09 y_morin ccct: I'm looking for it...
# 22:30:23 y_morin ccct: Oh, we already had this issue: http://crosstool-ng.org/download/ibot-logs/2011-07-03.html#quick-18:00:44
# 22:30:56 ccct Hmm. yes, I see a loop.
# 22:32:02 y_morin ccct: now I remember. We never understood what was going on... I tried to reproduce in a Ubuntu VM here, confirmed the issue, but did not have time to solve the issue.
# 22:32:45 ccct Hmm. ubuntu is all I've got.
# 22:33:50 ccct His solution was to use archlinux. Doesn't help me. :)
# 22:35:51 y_morin ccct: Well, the issue is /probably/ some internal variables in crosstool-Ng that propagates from step to step, and breaks glibc's configure.
# 22:36:29 y_morin ccct: but it happens only on Ubuntu, *and* only with glibc-2.14
# 22:36:43 ccct glibc-ports, not glibc proper.
# 22:36:51 y_morin ccct: as I rely on a VM to test on Ubuntu (wchi I seldom do, anyway) it takes ages testing.
# 22:37:10 y_morin ccct: well, it's the same from my point of view. The same load of crap...
# 22:38:41 ccct is "ct-ng build.libc_start_files" the correct way to start at that step?
# 22:39:13 ccct oh probably not.
# 22:39:43 y_morin ccct: the proper way is: ct-ng libc_start_files
# 22:40:13 y_morin ccct: but that will only build *that* step. If you want to continue the build: ct-ng libc_start_files+ (with the trailing '+')
# 22:40:19 y_morin ccct: see: ct-ng help
# 22:41:02 ccct I understand now.
# 22:42:10 y_morin ccct: I may have an idea on the problem. I have to investigate, though...
# 22:42:45 ccct I'll be here. :)
# 22:46:49 ccct It completed the libc_start_files step.
# 22:47:04 ccct I should have used "+" ... here we go again.
# 22:50:29 y_morin ccct: you can use the next step, now!
# 22:51:01 y_morin ccct: ct-ng will tel you what step you can restart at, for example: Saving state to restart at step 'cloog'...
# 22:51:13 y_morin ccct: ... means you can run: ct-ng cloog+
# 22:51:41 y_morin ccct: so, in your case, you could have run: ct-ng cc_core_pass_2+
# 22:54:15 ccct Yup, next time... slow computer, slow compile.
# 22:56:23 ccct But if that loop/too man files error was in libc_start_files, why didn't it error out.
# 23:01:41 y_morin ccct: the problem might be avariable that crosstool-NG sets for its own internal needs in a step _before_ libc_start_files, and that variable is not reset, and passes from step to step, up to the libc_start_files step, and then it is passed down the glibc's configure, which chokes on that variable.
# 23:02:06 y_morin ccct: we still do not know for sure this is the problem, and I did not yet identify the offending variable...
# 23:03:20 y_morin ccct: but it's 1am here, I'm going to bed...
# 23:03:35 y_morin ccct: I will probably build a VM tomorrow to investigate further...
# 23:04:02 ccct Strange that is is ubuntu only. Thank you and good night!
# 23:04:40 y_morin Cheers!
# 23:04:43 y_morin quits : Quit: Quitting...

Generated by ibotlog2html by Yann E. MORIN