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