# 00:58:58 |
chris86 |
quits : Quit: This computer has gone to sleep |
# 01:05:37 |
devcoder |
joins #crosstool-ng |
# 01:20:36 |
devcoder |
quits : Quit: devcoder |
# 01:34:02 |
fest3er |
joins #crosstool-ng |
# 01:37:52 |
fest3er |
parts #crosstool-ng |
# 01:38:41 |
fest3er |
joins #crosstool-ng |
# 02:00:46 |
fest3er |
Knock, knock. Anyone home? |
# 02:05:39 |
fest3er |
q |
# 02:05:42 |
fest3er |
quits : Quit: fest3er |
# 02:56:14 |
thewonderidiot |
parts #crosstool-ng |
# 03:27:20 |
ssspiff |
joins #crosstool-ng |
# 03:28:48 |
sspiff |
quits : Ping timeout: 252 seconds |
# 06:15:09 |
sfan5|OFF |
is now known as: sfan5 |
# 06:21:14 |
mnt_real |
quits : Ping timeout: 240 seconds |
# 06:31:42 |
sfan5 |
is now known as: sfan5|OFF |
# 06:32:28 |
chris86 |
joins #crosstool-ng |
# 06:32:28 |
chris86 |
quits : Client Quit |
# 06:34:06 |
sfan5|OFF |
is now known as: sfan5 |
# 06:35:03 |
sfan5 |
is now known as: sfan5|OFF |
# 07:21:13 |
chris86 |
joins #crosstool-ng |
# 07:33:25 |
diorcety |
quits : Quit: Leaving. |
# 08:01:35 |
chris86 |
quits : Quit: This computer has gone to sleep |
# 08:02:40 |
chris86 |
joins #crosstool-ng |
# 08:05:27 |
chris86 |
quits : Client Quit |
# 08:45:13 |
smartin |
joins #crosstool-ng |
# 10:23:36 |
vyrus001 |
quits : Ping timeout: 256 seconds |
# 10:23:49 |
vyrus001 |
joins #crosstool-ng |
# 12:13:37 |
Net147 |
joins #crosstool-ng |
# 12:30:44 |
ssspiff |
quits : Ping timeout: 248 seconds |
# 12:31:27 |
sspiff |
joins #crosstool-ng |
# 13:08:30 |
sspiff |
quits : Ping timeout: 256 seconds |
# 13:09:32 |
sspiff |
joins #crosstool-ng |
# 13:15:00 |
sfan5|OFF |
is now known as: sfan5 |
# 13:52:18 |
Net147 |
quits : Remote host closed the connection |
# 13:53:59 |
Net147 |
joins #crosstool-ng |
# 13:58:11 |
sh4rm4 |
y_morin: any news regarding upstreaming of microblaze toolchain support ? |
# 14:06:20 |
ccole |
quits : Read error: Connection reset by peer |
# 14:11:33 |
ccole |
joins #crosstool-ng |
# 14:12:21 |
Net147 |
quits : Quit: HydraIRC -> http://www.hydrairc.com <- The alternative IRC client |
# 17:35:36 |
mnt_real |
joins #crosstool-ng |
# 17:37:56 |
belak |
joins #crosstool-ng |
# 17:38:13 |
belak |
If I have the /proc/cpuinfo for a cpu, is it possible to build a toolchain for it? |
# 17:38:20 |
belak |
I have an old toolchain as well, if that helps |
# 17:46:17 |
diorcety |
joins #crosstool-ng |
# 17:52:50 |
thewonderidiot |
joins #crosstool-ng |
# 17:54:00 |
y_morin |
joins #crosstool-ng |
# 17:54:20 |
y_morin |
quits : Remote host closed the connection |
# 17:54:58 |
y_morin |
joins #crosstool-ng |
# 18:13:20 |
smartin |
quits : Quit: leaving |
# 18:51:52 |
y_morin |
sh4rm4: no idea about microblaze; I don't do microblaze. All I can say you know already from the mails on the list from the microblaze guys. |
# 18:53:06 |
y_morin |
belak: /proc/cpuinfo is a Linux kernel thingy. It would be better for you to know your CPU part number, and lookup the doc. |
# 18:54:30 |
y_morin |
goes for dinner. cu l8r... |
# 18:54:40 |
belak |
y_morin: I'm pretty sure it's a mv5vfp |
# 18:54:44 |
belak |
That's about all I now |
# 18:54:46 |
belak |
*know |
# 18:55:21 |
belak |
We were handed a arm-mv5vfp-linux-gnueabi build using an old version of x-tools |
# 18:55:26 |
belak |
No build.log |
# 18:55:36 |
belak |
Well, I have a really old one |
# 18:56:26 |
smartin |
joins #crosstool-ng |
# 19:05:04 |
codyps |
quits : Ping timeout: 260 seconds |
# 19:40:55 |
codyps |
joins #crosstool-ng |
# 20:19:30 |
sfan5 |
is now known as: sfan5|OFF |
# 22:09:11 |
smartin |
y_morin: hi |
# 22:09:25 |
y_morin |
smartin: hoady! |
# 22:09:34 |
y_morin |
smartin: howdy! |
# 22:09:58 |
smartin |
y_morin: how are you? |
# 22:11:20 |
smartin |
is there any non-obvious reason to hard-code the path to sed and grep in the xldd script? |
# 22:11:20 |
y_morin |
smartin: busy & drowsy: I've had a problem with my internal ear this WE, and I was barely able to stand up without falling or throwing... :-( |
# 22:12:11 |
y_morin |
smartin: Yes, there are! |
# 22:12:24 |
y_morin |
smartin: Oh, you want to know which ones? ;-) |
# 22:12:36 |
smartin |
ha! yes please ;) |
# 22:12:41 |
y_morin |
smartin: give me a sec, I have a mail pending! ;-) |
# 22:13:55 |
y_morin |
smartin: OK, this qemu series of mine is starting to last a bit longer than I would have hoped for! Haha! ;-) |
# 22:14:05 |
y_morin |
smartin: back to xldd... I'll look. |
# 22:16:05 |
y_morin |
smartin: for sed: we can't rely just on calling 'sed', because that might not be a sed that recognises -r and -e. Eg. sed on MacOS-X does not. So we need to use the sed found by ./configure |
# 22:16:07 |
smartin |
the fact is the host on which it will be used is not necessary identical to the one on which it has been built... |
# 22:17:27 |
y_morin |
smartin: for grep, it is for -E |
# 22:17:47 |
y_morin |
smartin: right, that's a limitation in xldd. |
# 22:18:00 |
y_morin |
smartin: I don't see an obvious way to solve this issue. |
# 22:20:03 |
smartin |
i agree about Mac-O$, but... at work i generate the cross-compiler on ubuntu (because it's the linux platform officily supported), |
# 22:20:22 |
smartin |
and my box run a bleeding-edge arch... |
# 22:21:26 |
y_morin |
smartin: I understand. But if you can think of a solution that does not involve re-running a ./configure, I'm all ears. ;-) |
# 22:21:32 |
smartin |
in the cross-ldd, there is 'grep=/bin/grep', whereas on my box grep is in /usr/bin, with no symlink in /bin :-/ |
# 22:22:44 |
y_morin |
smartin: that path is set by crosstool-NG with the paths it finds at ./configure time. |
# 22:23:58 |
smartin |
yep that's what i've seen in the xldd.in... |
# 22:25:46 |
y_morin |
smartin: one solution could be: http://code.bulix.org/47d2mc-82593 |
# 22:26:17 |
y_morin |
smartin: then, if the user has set SED and/or GREP in the env, those will be used. Otherwise, the paths found by ./configure will be used. |
# 22:26:32 |
smartin |
i understand you don't we a specific case for linux... but 'grep=`which grep`' |
# 22:26:58 |
smartin |
s/we/want to do/ |
# 22:29:36 |
smartin |
y_morin: well, your solution can be easily wrapped in such a way the user won't have to set these env.vars. manually... |
# 22:32:03 |
y_morin |
smartin: no, on Mac-OS (and *BSD I think), we want gsed, not sed, and we want ggrep (IIRC), not grep. |
# 22:41:09 |
y_morin |
belak: back to you: I would suggest that you start off one of the samples bundeld with ct-ng. |
# 22:41:27 |
y_morin |
belak: try to build it on your machine to see if every if fine there. |
# 22:42:00 |
y_morin |
belak: then, tweak the configuration (hint: ct-ng menuconfig) and set the proper values for arch, cpu, tune... |
# 22:42:50 |
belak |
y_morin: thanks |
# 22:43:04 |
belak |
y_morin: unless there are any working builds for mv5vfp |
# 22:43:33 |
y_morin |
belak: I don't know what the mv5vfp is, so I can't say. |
# 22:44:13 |
y_morin |
belak: is it of the DaVinci familly? |
# 22:45:28 |
y_morin |
belak: can you pastebin your /proc/cpuinfo ? |
# 22:47:51 |
smartin |
y_morin: i think i like your solution, easy to wrappe like this for linux: http://code.bulix.org/3b20tu-82594 |
# 22:49:58 |
belak |
y_morin: I think it's a broadcom |
# 22:49:59 |
belak |
1 min |
# 22:50:11 |
y_morin |
smartin: I'm not adding that in upstream ct-ng. |
# 22:50:40 |
y_morin |
smartin: besides, you want to quote $@, in case there are spaces in there. |
# 22:51:38 |
belak |
Processor: Feroceon rev 0 (v5l) |
# 22:51:49 |
belak |
Features: swp half thumb fastmult vfp edsp |
# 22:51:55 |
belak |
CPU architecture: 5TE |
# 22:52:00 |
belak |
Not sure if anything else is needed |
# 22:52:08 |
smartin |
y_morin: of course, it's just how i will do the wrapper if you do the change ;) |
# 22:52:31 |
y_morin |
smartin: yes, I'll do the change. ;-) |
# 22:53:28 |
y_morin |
belak: just a sec... |
# 22:53:55 |
belak |
I'd rather not post the whole thing, as this is a company box I'm trying to build a toolchain for |
# 22:54:44 |
y_morin |
belak: there's an armv5te sample: arm-unknown-linux-uclibcgnueabi |
# 22:54:55 |
belak |
Awesome. Thanks! |
# 22:54:57 |
y_morin |
belak: to use it: ct-ng arm-unknown-linux-uclibcgnueabi |
# 22:55:06 |
y_morin |
belak: then: ct-ng build |
# 22:55:29 |
y_morin |
belak: not however that VFP and hard-float is *not* supported by upstream gcc. |
# 22:55:53 |
belak |
:/ |
# 22:55:55 |
belak |
Ok, thanks |
# 22:56:02 |
belak |
Better than nothing |
# 22:56:30 |
y_morin |
belak: yes, I don't know why, it's just that gcc will complain at runtime that 'hardfloat and VFP are not supported' |
# 22:56:36 |
belak |
It'll be a good starting point |
# 22:56:51 |
belak |
Is there any way to use a previous toolchain to figure out what options to enable? |
# 22:57:12 |
y_morin |
belak: was your previous toolchain built with ct-ng ? |
# 22:57:15 |
belak |
Yes |
# 22:57:56 |
belak |
No build log though |
# 22:58:02 |
belak |
Well, not in the newest one |
# 22:58:13 |
y_morin |
belak: you could run: arm-mv5vfp-linux-gnueabi-ct-ng.config |
# 22:58:30 |
y_morin |
belak: that will dump you the ct-ng's .config use for that toolchain. |
# 22:58:36 |
belak |
OHHH |
# 22:58:38 |
belak |
Score |
# 22:59:00 |
y_morin |
:-) |
# 22:59:01 |
belak |
YAY |
# 22:59:05 |
belak |
Thanks so much |
# 22:59:52 |
y_morin |
belak: cheers! :-) |
# 23:00:43 |
y_morin |
belak: of course, you'll still have to tweak that old .config to adapt to the newer ct-ng. |
# 23:01:23 |
y_morin |
belak: note also that this sample is using uClibc, while your old toolchain was probably using (e)glibc |
# 23:01:52 |
y_morin |
(you can see it becasue it said -gnueabi, while the sample is -uclibcgnueabi) |
# 23:28:10 |
smartin |
quits : Quit: good night |
# 23:29:34 |
y_morin |
quits : Quit: Nighty Night! |