| # 01:28:07 |
sh4rm4 |
quits : Ping timeout: 276 seconds |
| # 01:40:49 |
sh4rm4 |
joins #crosstool-ng |
| # 04:53:00 |
imMute |
joins #crosstool-ng |
| # 04:54:33 |
imMute |
I've been trying to cross compile for an embedded system we are developing at work. The ct-ng script worked fine on the work box (Ubuntu Karmic x86_64) but the same .config blows up on my ArchLinux box as well as on Fedora 16. |
| # 04:56:27 |
imMute |
I even tried the arm-cortex_a8-linux-gnueabi.config example but I still get errors about make targets during the libc headers step. The issues doc said use an older version of make, so I compiled 3.80 and it still says that |
| # 04:57:49 |
imMute |
(The issue I was having with Arch and the other .config were internal gcc errors, which I attributed to Arch having an "experimental" version of gcc) |
| # 05:42:44 |
mnt_real |
quits : Quit: Leaving |
| # 09:41:10 |
smartin |
joins #crosstool-ng |
| # 14:01:44 |
smartin |
quits : Ping timeout: 258 seconds |
| # 14:48:13 |
imMute |
I might just end up installing ubuntu x86_64 on something so I can just use the already-compiled binaries :( |
| # 16:29:19 |
mnt_real |
joins #crosstool-ng |
| # 18:25:09 |
imMute |
gah. I just realized pretty much all the errors i've been getting now are "Makefile:240: *** mixed implicit and normal rules. Stop." even though I'm using make-3.80 |
| # 18:25:15 |
imMute |
I have no idea what to try now. any ideas? |
| # 19:51:19 |
fauno_ |
joins #crosstool-ng |
| # 19:51:24 |
fauno |
quits : Ping timeout: 240 seconds |
| # 19:53:18 |
fauno_ |
is now known as: fauno |
| # 19:55:13 |
y_morin |
joins #crosstool-ng |
| # 19:55:26 |
y_morin |
quits : Remote host closed the connection |
| # 19:59:54 |
y_morin |
joins #crosstool-ng |
| # 20:15:17 |
imMute |
aha, apparently ct-ng is creating a .build/tools/bin/make binary that is v2.82 |
| # 20:15:20 |
imMute |
now why is it doing that.... |
| # 20:22:04 |
y_morin |
imMute: hey! This is a wrapper script to your own make. |
| # 20:22:43 |
y_morin |
imMute: so if your host make is 3.82 (I hope it's not 2.82!), then the wrapper just calls this. |
| # 20:24:13 |
y_morin |
imMute: If you have make issues, then you can ask ct-ng to build a make 3.81. Go to: "Companion tools" -> [*] Build some companion tool -> [*] make |
| # 20:26:03 |
imMute |
y_morin: right, and it is still "pointing" at /usr/bin/make rather than /somewhere/else/bin/make (which is earlier in my PATH). apparently you have to specify where make is whne *compiling ct-ng itself* |
| # 20:27:36 |
y_morin |
imMute: .configure looks for a 'make' in the PATH, and then uses that to setup crosstool-NG. So if you built your own 'make' after you installed crostool-NG, it will still use the old one. |
| # 20:28:08 |
imMute |
right. I just recompiled ct-ng and its still using the old make |
| # 20:29:13 |
y_morin |
Hmm... Lemme check... |
| # 20:29:31 |
imMute |
and apparently this version of ct-ng doesn't have the option to build make |
| # 20:30:36 |
imMute |
I'll try the latest ct-ng with the option to compile make turned on |
| # 20:30:51 |
y_morin |
imMute: you have to first enable "EXPERIMENTAL" in "Paths and misc options" |
| # 20:31:25 |
imMute |
right, I did. the companion tools shows up and lists automake, m4 , autoconf, and something else, but not make |
| # 20:31:35 |
imMute |
I'm nuking everything and starting over |
| # 20:31:37 |
y_morin |
imMute: what ct-ng version are you using? |
| # 20:31:48 |
imMute |
I was using 1.9.2, going to try 1.13.2 now |
| # 20:32:04 |
y_morin |
imMute: Oh yes, 1.9.x was lacking 'make'. |
| # 20:33:03 |
imMute |
It wont matter that ct-ng was built with make 3.82?? |
| # 20:33:43 |
y_morin |
imMute: Nope. It does matter only for old versions of the Linux kernel, the glibc nd eglibc, and maybe old versions of gcc as well. |
| # 20:33:58 |
y_morin |
imMute: old, meaning "before make-3.82 was released" |
| # 20:34:09 |
imMute |
screw it, going to rebuild ct-ng with the old make anyway |
| # 20:34:22 |
y_morin |
imMute: but ct-ng itself is immune to the make-3.82 changes. |
| # 20:34:45 |
y_morin |
imMute: it's not like configuring+building crostool-NG took ages! ;-) |
| # 20:35:00 |
imMute |
thank god |
| # 20:35:54 |
imMute |
running the cross build would take > 2hrs on my VM. I did that once then said, NOEP. |
| # 20:36:37 |
y_morin |
imMute: "NOEP" ? |
| # 20:36:44 |
imMute |
nope* |
| # 20:37:17 |
imMute |
I'm trying the arm-cortex_a8-linux-gnueabi.config example config (with a couple minor path changes, and the make change) and seeing if that works. if it does, then I'll praise |
| # 20:38:48 |
y_morin |
imMute: I just did the folowing: build crosstool-NG with my host /usr/bin/make, then install another make in /opt/make/bin/make, export it to PATH, then re-run ct-ng's ./configure, and it properly picks the new make. |
| # 21:00:56 |
imMute |
oh snap, it moved past teh libc_start_files step - that's a first! |
| # 21:03:16 |
y_morin |
imMute: Yeah! :-) |
| # 21:04:24 |
imMute |
man, I'm glad I'm not in charge of the hardware behind this VPS - I've been *hammering* the disks for the last 3 days. |
| # 21:28:18 |
imMute |
well shit, puked on building cross-gdb with a python error |
| # 21:34:24 |
y_morin |
imMute: Yep, 1.13 does not have proper checks in place to test for python, especially if you ask for a static link of gdb. |
| # 21:34:56 |
imMute |
so the solution is to... not build gdb? |
| # 21:35:17 |
imMute |
I probably don't need to as I already have gdb on the target |
| # 21:36:10 |
imMute |
oh, just noticed a [ ] Enable python scripting option under gdb. going to turn that off now |
| # 21:36:16 |
y_morin |
imMute: it's about the cross-gdb, not the native one. And you can simply disable python script: [ ] Enable python scripting |
| # 21:36:22 |
y_morin |
Hehe! :-) |
| # 21:36:58 |
imMute |
whee, moving on. (also, thank freaking god for the RESTART option) |
| # 21:37:20 |
y_morin |
imMute: The restart does not work if you change the configuration! |
| # 21:37:36 |
imMute |
even just that one little thing? |
| # 21:37:50 |
imMute |
nope, apparently not. |
| # 21:37:53 |
y_morin |
imMute: that's because crosstool-NG has no way to know if the config change has an impact on the previous build... |
| # 21:39:00 |
imMute |
quite true. although it'd be cool if you could say "yes the config changed, but continue where you left off anyway - I think I know what I'm doing" |
| # 21:39:33 |
y_morin |
imMute: I already looked at it, and that's not that simple... |
| # 21:39:52 |
imMute |
I figured as much. not complaining :) |
| # 21:40:09 |
imMute |
I'm assuming you're teh guy that wrote crosstool-ng? |
| # 21:40:36 |
y_morin |
imMute: when I wrote all that scripts and Makefile stuff some 5 years ago, it seemed like a pretty neat thingy. Now, as time passes, I see that there are real issues with the design... |
| # 21:41:12 |
imMute |
ever thought about redesigning it? |
| # 21:41:20 |
imMute |
or does it work well enough to not bother? |
| # 21:42:08 |
y_morin |
imMute: Yes, I am thinking about it. But I have much more important to finish first. And yes, it works pretty well for my use case, but really I want to change some big things in the design... |
| # 21:43:31 |
y_morin |
imMute: basically, instead of this all-linear build procedure, I'd like to switch to a Makefile-based dependency, so that not-dependent steps can be built in parallel; eg. binutils do not require the complibs, so there's no point in waiting for them to finish before building binutils). |
| # 21:44:32 |
y_morin |
Especially since, at least on my machine, about 1.3rd of the time is spent in ./configure, which is not parallel at all, so I have a bunch of CPUs just idling for 1.3rd of the toolchain build (jeez, that's eleven hyper-threads doing nothing!) |
| # 21:44:46 |
imMute |
thatd be pretty cool, but yeah, I can see how that would require a major overhaul |
| # 21:46:12 |
y_morin |
imMute: basically, it's not that technically complex: all the steps are already self-contained, and run in their own sub-shell. The big hudle would be about the big scripts/crosstool-NG.sh that is not really thought out (well, at the time, I thought it was, but, hey!...) |
| # 21:46:23 |
y_morin |
*hurdle |
| # 21:47:25 |
imMute |
jeez PPL is murdering the RAM, but barely touching the CPUs |
| # 21:47:46 |
y_morin |
imMute: Even on my machine with 6GiB, it swaps horribly... |
| # 21:48:21 |
y_morin |
But I build 12 jobs in // |
| # 22:44:09 |
y_morin |
is now known as: y_morin|away |
| # 23:03:25 |
y_morin|away |
is now known as: y_morin |
| # 23:31:19 |
imMute |
y_morin: so the example config build worked. going to try the work config again (it ran out of disk on the first try) |
| # 23:32:22 |
y_morin |
imMute: The samples are just that: samples, known to build; users can then tweak them to better fit their needs. But at least, they provide a known-working starting point |
| # 23:32:48 |
imMute |
mhmm. if it didn't work, then I'd know something was definitely up |
| # 23:38:23 |
fauno |
quits : Ping timeout: 252 seconds |
| # 23:39:41 |
fauno |
joins #crosstool-ng |
| # 23:58:37 |
imMute |
y_morin: woot! it finished! |
| # 23:58:43 |
y_morin |
\o/ |