| # 00:40:08 | codyps | joins #crosstool-ng |
| # 00:45:31 | codyps | quits : Read error: Connection reset by peer |
| # 00:45:54 | codyps | joins #crosstool-ng |
| # 01:57:34 | Net147 | joins #crosstool-ng |
| # 02:29:26 | Net147 | quits : Quit: HydraIRC -> http://www.hydrairc.com <- The alternative IRC client |
| # 05:03:38 | codyps | quits : Quit: Leaving. |
| # 05:14:28 | alan_o | quits : Quit: Leaving |
| # 05:29:14 | sh4rm4 | joins #crosstool-ng |
| # 05:38:32 | codyps | joins #crosstool-ng |
| # 05:39:18 | codyps | quits : Client Quit |
| # 05:41:52 | codyps | joins #crosstool-ng |
| # 07:20:33 | diorcety | quits : Quit: Leaving. |
| # 08:19:42 | sfan5|OFF | is now known as: sfan5 |
| # 08:26:18 | sfan5 | does crosstool-ng support build != host = target ? |
| # 08:37:15 | diorcety | joins #crosstool-ng |
| # 08:50:48 | Net147 | joins #crosstool-ng |
| # 09:02:48 | smartin | joins #crosstool-ng |
| # 09:02:57 | sfan5 | does crosstool-ng support build != host = target ? |
| # 09:21:29 | sfan5 | is now known as: sfan5|OFF |
| # 09:29:05 | sfan5|OFF | is now known as: sfan5 |
| # 09:37:47 | ubergeek42 | quits : Ping timeout: 252 seconds |
| # 09:54:37 | ubergeek42 | joins #crosstool-ng |
| # 10:30:52 | mingwandroid | joins #crosstool-ng |
| # 12:12:19 | An_Ony_Moose | sfan5: to my knowledge it doesn't support any configurations where build != host |
| # 12:17:57 | sfan5 | oh, ok |
| # 14:34:11 | smartin | quits : Quit: leaving |
| # 16:36:00 | diorcety | quits : Quit: Leaving. |
| # 17:12:11 | diorcety | joins #crosstool-ng |
| # 17:14:30 | mingwandroid | diorcety: hi. |
| # 17:31:14 | codyps | quits : Quit: Leaving. |
| # 17:32:07 | codyps | joins #crosstool-ng |
| # 18:00:54 | y_morin | joins #crosstool-ng |
| # 18:20:50 | mingwandroid | hi yann. |
| # 18:32:04 | y_morin | mingwandroid: hello! |
| # 18:33:10 | y_morin | 08:26:18 sfan5: does crosstool-ng support build != host = target ? <-- No. |
| # 18:33:32 | y_morin | sfan5: However, build != host != target *is* supported. |
| # 18:33:37 | y_morin | An_Ony_Moose: ^^^^^ |
| # 18:34:12 | y_morin | Oh, and by the way: Happy New Year, and Best Wishes To You All! :-) |
| # 18:34:59 | mingwandroid | y_morin: Happy New Year! |
| # 18:35:14 | sfan5 | y_morin: Happy new Year |
| # 18:35:24 | mingwandroid | y_morin: All your celebrating done? I remember you said that you'd not have much time for hacking over the festive period? |
| # 18:35:54 | y_morin | mingwandroid: Festivities are over today. |
| # 18:36:20 | sfan5 | what about build = i586-linux-gnu | host = arm-unknown-linux-gnueabi | target = arm-unknown-linux-gnueabi_duplicate |
| # 18:36:25 | y_morin | mingwandroid: But I've been busy with REal Life duties since ~Sunday morning. |
| # 18:36:44 | mingwandroid | y_morin: probably want to get lost in some coding then ;-) |
| # 18:36:53 | y_morin | sfan5: It *may* work, but you should use: target = arm-unknown_duplicate-linux-gnueabi |
| # 18:37:03 | y_morin | mingwandroid: I am! :-) |
| # 18:37:27 | sfan5 | I'll test that |
| # 18:37:51 | y_morin | sfan5: *But*: if you want a native toolchain on your target (ie. host == target), then you probably do *not* want a sysrooted toolchain. |
| # 18:38:08 | y_morin | sfan5: And crostool-NG does not support non-sysrooted toolchains. |
| # 18:38:27 | sfan5 | :( |
| # 18:38:53 | y_morin | sfan5: BTW, what you want is called a cross-native, ie. a cross-compiled native toolchain. |
| # 18:39:15 | y_morin | sfan5: I'd like to have support for that, but it is not in my top-priorities. So any patch welcome! ;-) |
| # 18:39:23 | y_morin | Muhahaha! |
| # 18:39:41 | sfan5 | :/ i don't think i am going to make a path in the near future |
| # 18:40:19 | mingwandroid | y_morin: I've got a series of patches ready now. |
| # 18:40:40 | mingwandroid | http://paste.kde.org/635750/ |
| # 18:40:43 | y_morin | mingwandroid: OK, good. Post them to the list, please. |
| # 18:41:04 | y_morin | mingwandroid: Ah, cctools patches, not ct-ng patches. |
| # 18:41:08 | mingwandroid | indeed. |
| # 18:41:29 | mingwandroid | I wanted to get your opinion on a few aspects... |
| # 18:41:45 | mingwandroid | so clearly there's a lot of 'stuff' there. |
| # 18:41:55 | y_morin | mingwandroid: 'autoconfiscate'? You mean, adding autotools stuff? |
| # 18:42:01 | mingwandroid | y_morin: yeah. |
| # 18:42:25 | mingwandroid | 1263933Â -> clean_sources... this is a purely deletion of files. |
| # 18:42:29 | y_morin | Hmm, I'll like the pun, but I think a better name is waranted, eg.: add-autotools-infra. |
| # 18:42:50 | mingwandroid | http://en.wikipedia.org/wiki/Autoconfiscation |
| # 18:43:04 | y_morin | mingwandroid: And what would it cost to split 135-misc_host_fixes ? |
| # 18:43:30 | mingwandroid | not strictly a pun, more a well known term... |
| # 18:43:44 | y_morin | mingwandroid: OK, then! :-) |
| # 18:44:40 | mingwandroid | very little, they are very noddy one-liners mostly: http://paste.kde.org/635804/ |
| # 18:45:18 | mingwandroid | what about the clean_sources patch, I could get rid of it as it just removes things that aren't strictly part of the compiler toolchain. |
| # 18:46:25 | y_morin | mingwandroid: If it removes files that are anyway not used, then no need for that patch. |
| # 18:46:30 | mingwandroid | 1263933Â (clean sources) + 931839Â (configure_regen) could arguably be done away with. |
| # 18:46:52 | y_morin | mingwandroid: 135: I think it would be good to have one patch for each do_sed. |
| # 18:47:03 | mingwandroid | ok that's fine. |
| # 18:47:20 | mingwandroid | I've got an automated way to produce them all now so splitting is simple... |
| # 18:47:46 | mingwandroid | can we require autoreconf is run at build time? |
| # 18:48:02 | y_morin | mingwandroid: maybe you can join in one patch the (stdlib+stdint) with the (unistd+stdint) and with the (string+strings) |
| # 18:48:10 | y_morin | mingwandroid: autoreconf: yes, definitely. |
| # 18:49:09 | y_morin | mingwandroid: Got to go for dinner now. Will be back later (probably before 21:30 UTC) |
| # 18:49:30 | y_morin | is hungry. Very hungry. Very, VERY hungry! ;-] |
| # 18:49:32 | mingwandroid | ok, there's more to ask about. I'll try to get online around then. |
| # 18:49:55 | y_morin | mingwandroid: Otherwise, you can cook a mail and send it to the mailing list. |
| # 18:50:51 | y_morin | mingwandroid: That way, you have more room to expose your issues and ask many questions, and I can answer them all at once (after thinking a bit on the answers ;-) ) |
| # 18:50:57 | y_morin | goes now. |
| # 19:02:10 | mingwandroid | parts #crosstool-ng |
| # 19:41:19 | mingwandroid | joins #crosstool-ng |
| # 20:00:52 | alan_o | joins #crosstool-ng |
| # 20:09:20 | smartin | joins #crosstool-ng |
| # 20:31:32 | sfan5 | is now known as: sfan5|OFF |
| # 21:00:27 | diabel | Hi, all |
| # 21:06:15 | diabel | I've got big problem |
| # 21:07:59 | diabel | http://paste.kde.org/635858/ |
| # 21:08:42 | diabel | I don't know why it 'alphaev4-unknown-elf' because i set to have arm cross |
| # 21:09:52 | y_morin | diabel: care to post your .config, please? |
| # 21:17:36 | y_morin | diabel: ^^^^ ? |
| # 21:19:11 | diabel | ok, moment |
| # 21:19:20 | doc2 | joins #crosstool-ng |
| # 21:19:49 | diabel | http://paste.kde.org/635882/ |
| # 21:20:34 | y_morin | diabel: Also, do *not* run as root. It is dangerous, as ct-ng does 'rm -rf' on the install dir by default. |
| # 21:20:46 | y_morin | diabel: OK, I'm having a look at your .config. |
| # 21:22:00 | y_morin | diabel: Also, you're using ct-ng 1.15.3. It's no longer maintained. Latest is 1.17.0. |
| # 21:23:28 | diabel | y_morin: that's the problem, I test 1.16 first 1.17, and 1.15.X |
| # 21:23:48 | y_morin | diabel: then, what's the error with 1.17.0 ? |
| # 21:26:07 | diabel | the same :( |
| # 21:26:13 | diabel | on every versions... |
| # 21:28:23 | y_morin | diabel: strange, it works here... Can you post your complete build.log, please? |
| # 21:29:20 | doc2 | hello, one question to the naming of the patches for GCC for example. I'm trying to setup some patches that are only relevant while building a cross gcc for sh4. As far as I can see I have to name this like 'xxx-sh-foo-somthing.patch'. Am I right? |
| # 21:30:30 | y_morin | doc2: There are no support for target-specific patches in crosstool-NG. All patches are applied. |
| # 21:31:06 | doc2 | hmm, that's sad |
| # 21:31:11 | y_morin | doc2: the only relevant part of the patch naming is the ordering of patches, which is guarantedd by prefixing a number at the front (xxx-) |
| # 21:31:29 | diabel | http://wklej.org/id/913124/ |
| # 21:31:39 | doc2 | STlinux make some heavy patching to binutils and gcc partialy |
| # 21:31:44 | y_morin | doc2: The idea behind that is to gurarantee that the *same* code base is used for all toolchains using the same components. |
| # 21:32:21 | y_morin | doc2: One comment: STlinux is, well, crap... |
| # 21:32:28 | diabel | y_morin: also, I try without patches, with patches, with minimal settings, withs stable apps, without stable apps... many ways... allways the same problem |
| # 21:32:32 | y_morin | diabel: OK, I'm haviong a look in a minute... |
| # 21:33:12 | doc2 | y_morin, yes, patches for gdb for example are little bit bigger :) |
| # 21:35:34 | y_morin | doc2: Just use your patches. If you are only interested in SuperH toolchains, they will be applied. |
| # 21:36:16 | y_morin | doc2: if you are also interested in alternate architectures, they will also be applied, but if they break something, then complain to STlinux for their incorrect patches. |
| # 21:36:37 | y_morin | diabel: Indeed, this build.log is, tp put in mildly, weird... :-( |
| # 21:36:52 | doc2 | y_morin, o.k. so I have to look deeper into buildroot if I can patch the extractet Crosstool sources ... |
| # 21:38:22 | doc2 | y_morin, most of the patches are generic enough, I would like prepare to a patch next days based on 1.17.0 |
| # 21:39:13 | diabel | y_morin: I set now, to do the debug log, v.verbosity etc, paste is after some 5-10 minutes |
| # 21:39:15 | sfan5 | joins #crosstool-ng |
| # 21:40:09 | sfan5 | y_morin: couldn't you symlink sysroot to / ? |
| # 21:41:50 | y_morin | diabel: could you post the result of: set |grep -E '^[^[:space:]]+=' |sort |
| # 21:42:29 | diabel | one moment |
| # 21:43:27 | y_morin | sfan5: well, IIRC, that's what is done for the native RPI toolchain... |
| # 21:44:16 | sfan5 | i may try that tomorrow |
| # 21:44:27 | y_morin | sfan5: that would need some tweaking to the toolchain afterwards, because ct-ng does not do that itself. |
| # 21:45:15 | y_morin | sfan5: but granted, that *could* be a simple way to achieve a cross-native. |
| # 21:45:25 | sfan5 | but why does crosstool-ng provide a sysrooted option if it doesn't support non-sysrooted toolchains? |
| # 21:46:00 | diabel | y_morin: http://paste.debian.net/221179/ |
| # 21:46:07 | y_morin | sfan5: that's a different matter. Just a sec... |
| # 21:47:21 | y_morin | diabel: can you remove that android sdk from your PATH, and give it another go? |
| # 21:47:31 | sfan5 | quits : Read error: Connection reset by peer |
| # 21:48:03 | diabel | y_morin: ok, moment |
| # 21:48:42 | y_morin | diabel: And do *not* run as root. This s *very* dangerous. ct-ng should work just fine as non-root. |
| # 21:48:44 | sfan5 | joins #crosstool-ng |
| # 21:49:08 | y_morin | sfan5: was the weather sunny outside? ;-) |
| # 21:49:13 | sfan5 | did i miss something? |
| # 21:49:20 | y_morin | sfan5: no, no? |
| # 21:49:30 | y_morin | sfan5: no, no! |
| # 21:50:13 | sfan5 | no, it was too rainy for my WLAN ;) |
| # 21:50:43 | y_morin | :-) |
| # 21:51:39 | y_morin | GTG, BBS... |
| # 21:55:45 | diabel | y_morin: (doing it from user), the same problem |
| # 21:57:40 | mingwandroid | diorcety y_morin: ping. |
| # 22:00:54 | doc2 | quits : Remote host closed the connection |
| # 22:18:02 | sfan5 | quits : Read error: Connection reset by peer |
| # 22:22:00 | y_morin | diabel: could you run ct-ng show-tuple, please? |
| # 22:24:02 | y_morin | diabel: then apply this patch: http://code.bulix.org/dum7jh-82763 and re-run ct-ng show-tuple |
| # 22:24:12 | y_morin | mingwandroid: pong. |
| # 22:26:16 | smartin | quits : Quit: leaving |
| # 22:26:27 | mingwandroid | ok, so... |
| # 22:26:45 | mingwandroid | there's a bit where I grab headers from the OSX SDK... |
| # 22:27:31 | mingwandroid | All of the files are licensed under either APSL 2 or else BSD... and most of them are headers directly from the Mach Kernel. |
| # 22:28:20 | mingwandroid | It's quite a sizeable chunk. Old odcctools had different (probably just old) versions of these files. |
| # 22:28:28 | y_morin | mingwandroid: APSL? |
| # 22:28:38 | mingwandroid | Apple Public Source License 2. |
| # 22:28:45 | y_morin | OK |
| # 22:28:56 | mingwandroid | http://en.wikipedia.org/wiki/Apple_Public_Source_License |
| # 22:29:15 | mingwandroid | http://www.gnu.org/licenses/license-list.html#apsl2 |
| # 22:29:45 | mingwandroid | now... I got these headers from Xcode. |
| # 22:30:14 | mingwandroid | http://images.apple.com/legal/sla/docs/xcode.pdf |
| # 22:30:51 | mingwandroid | wanting to make sure that this is all ok with you. Personally, I hate legalese, but of course we've got to be 100% compliant. |
| # 22:31:23 | y_morin | mingwandroid: yes, we have. And yes, it is a tough issue... |
| # 22:31:35 | y_morin | mingwandroid: AFAICS, APSL2 is not GPL-compatible. |
| # 22:32:40 | mingwandroid | y_morin: http://www.gnu.org/philosophy/apsl.html |
| # 22:32:55 | y_morin | mingwandroid: Is each header available under both the APSL2 and BSD, or are some headers under APSL2 and others BSD? |
| # 22:32:59 | mingwandroid | "Theproblems previously described on this page are still potential issues for other possible licenses, but they do not apply to version 2.0 of the APSL" |
| # 22:33:06 | y_morin | mingwandroid: yes, I've read that. |
| # 22:33:16 | mingwandroid | y_morin: I'll paste the most common license header.. |
| # 22:33:30 | y_morin | mingwandroid: That page also says: "It is incompatible with the GPL." |
| # 22:34:10 | mingwandroid | http://paste.kde.org/635912/ |
| # 22:34:11 | y_morin | mingwandroid: "most common" manes nothing. Suffice one header to be under an incompatible license, and that's end of game. |
| # 22:34:30 | mingwandroid | y_morin: unless I re-write a workaround for the missing piece. |
| # 22:34:42 | y_morin | mingwandroid: that's BSD 4-clause, and is not compatible with the GPL either. |
| # 22:35:11 | mingwandroid | y_morin: these things are interop-necessary. also, theres precedent of them being included in GPL software (Apple released GCC compilers built with them!) |
| # 22:35:26 | y_morin | mingwandroid: I know, but: |
| # 22:35:50 | y_morin | mingwandroid: !) Apple being the author can do whatever they want with it, they are not bould by the license. |
| # 22:36:06 | y_morin | (that was a '1', not a '!') |
| # 22:36:09 | mingwandroid | k |
| # 22:36:25 | y_morin | and s/bould/bound/ |
| # 22:36:31 | mingwandroid | but, actually, they're from BSD before Apple? |
| # 22:36:51 | mingwandroid | I mean, apple took BSD 4-clause software, stuck APSL 2 on top... compiled GCC, released GCC... |
| # 22:36:53 | y_morin | mingwandroid: 2) (can't remember, now. sigh...) |
| # 22:37:29 | y_morin | mingwandroid: would it be possible to "grab" those headers at the time the toolchain is built? |
| # 22:37:48 | y_morin | mingwandroid: then it is the responsibility of the user to mix the works, not yours. |
| # 22:37:55 | mingwandroid | Apple releasing GCC with those headers compiled into and then distributing them puts those headers under GPL doesn't it? |
| # 22:38:19 | y_morin | mingwandroid: But even in that case, we'll have to inform the user of that potential conflict (IANAL). |
| # 22:38:22 | diabel | y_morin: back, one moment |
| # 22:38:29 | mingwandroid | the (ugh, sorry) much debated viral nature of the GPL. |
| # 22:38:37 | mingwandroid | sorry 'viral' |
| # 22:39:20 | y_morin | mingwandroid: no, wrong. That's a misconception. The wqhole work is convered by the most 'propagating' license (here, GPL). But each piece independently retain their original license. |
| # 22:39:33 | y_morin | convered -> covered. |
| # 22:40:34 | y_morin | mingwandroid: but if there *is* a release of gcc that builds a binary from GPL source code, and that this source code includes aforementioned headers, they *probably* it is OK. |
| # 22:40:49 | y_morin | And I mean *probably*, *not* certainly. |
| # 22:41:03 | mingwandroid | y_morin: AFAIK, if a company bundles GPL code with their own proprietary code then that prop. code must also be offered to anyone it's distributed to under GPL? |
| # 22:41:12 | mingwandroid | y_morin: is it worth me firing off an email to RMS? |
| # 22:41:30 | y_morin | mingwandroid: Ahaha! ROTFL! |
| # 22:41:43 | y_morin | mingwandroid: probably not. |
| # 22:41:53 | mingwandroid | He'd love to give us his opinion on this ;-) |
| # 22:42:16 | y_morin | mingwandroid: anyway, enough speaking licensing here, I am not qualified to give legal advice. |
| # 22:42:37 | mingwandroid | y_morin: Ok, nor I. I can go for the download it from apple approach then? |
| # 22:42:37 | y_morin | mingwandroid: Is it possible to "grab" those headers at toolchain build time? |
| # 22:42:45 | diabel | y_morin: show tuple (1st) "alphaev4-unknown-elf" (why???? i set it to arm, strange) show-tuple - second: http://paste.debian.net/221202/ |
| # 22:42:49 | y_morin | mingwandroid: yes, that'd be better. |
| # 22:42:59 | y_morin | diabel: OK, I'm looking... |
| # 22:44:01 | mingwandroid | the other thing I was thinking was to write a small Python program to take --save-temps output and work out the minimum amount of stuff needed and make my own interop headers with just the minimal amount (re-typed of course)? I think this is the sort of thing the odcctools (opendarwin cctools) guys did before... |
| # 22:44:13 | mingwandroid | ...though I think they did it by hand... |
| # 22:44:24 | diabel | y_morin: it's strange, is possible that ctng thinking that config-linux = bare-metal and config-bare-metal = linux? |
| # 22:44:37 | diabel | maybe I try to set bare metal, and check? |
| # 22:46:09 | y_morin | diabel: no, there really is something strange. |
| # 22:46:21 | y_morin | diabel: can you apply this patch, and re-run, please? http://code.bulix.org/lyp13o-82764 |
| # 22:47:01 | y_morin | diabel: that will generate a *huge* amount of traces, but we'll see exactly where it breaks. |
| # 22:48:27 | y_morin | diabel: you'll need to re-run 'make' after that patch. |
| # 22:49:28 | diabel | one moment |
| # 23:01:18 | diabel | http://109.110.201.98/debug |
| # 23:05:01 | y_morin | diabel: Uh? This *is* an alpha config: it's visible a few lines below the . .config.2 --> CT_ARCH=alpha |
| # 23:05:25 | y_morin | diabel: Also, check .config.2, it should read the same as .config . |
| # 23:05:49 | y_morin | diabel: id it does not, then it means .config.2 was *not* regenerated. |
| # 23:06:08 | y_morin | id --> if |
| # 23:06:33 | diorcety | quits : Quit: Leaving. |
| # 23:09:38 | y_morin | diabel: remove the patch, and try: ct-ng clean; ct-ng build |
| # 23:09:51 | diabel | grep -i alpha 3config |
| # 23:09:51 | diabel | # CT_ARCH_alpha is not set |
| # 23:09:51 | diabel | CT_ARCH_alpha_AVAILABLE=y |
| # 23:10:10 | diabel | heh... massacre... that little... mistake ;/ |
| # 23:10:33 | y_morin | diabel: can you run: stat .config .config.2 |
| # 23:10:52 | diorcety | joins #crosstool-ng |
| # 23:11:35 | y_morin | diabel: forget the 'stat' thingy... Remove my patch, and try: ct-ng clean; ct-ng build |
| # 23:13:38 | diabel | moment |
| # 23:22:08 | y_morin | diabel: So? (It's 00:20 here, I'm soon going to bed...) |
| # 23:22:58 | diabel | y_morin: I get crosstool 1.17 |
| # 23:23:07 | y_morin | diabel: OK. |
| # 23:23:13 | diabel | this problem is strange still I have .config.2 different than |
| # 23:23:15 | diabel | .config |
| # 23:23:31 | y_morin | diabel: OK. How did you create your .config ? |
| # 23:23:41 | diabel | ct-ng menuconfig |
| # 23:23:58 | diabel | I did ln -sf .config .config.2 and tried to build |
| # 23:24:12 | y_morin | diabel: No! |
| # 23:24:23 | y_morin | diabel: .config.2 is generated by ct-ng! |
| # 23:24:29 | diabel | ;o |
| # 23:24:47 | y_morin | diabel: just run: ct-ng menuconfig; ct-ng build |
| # 23:24:50 | y_morin | that's all. |
| # 23:24:53 | diabel | ok |
| # 23:26:10 | diabel | y_morin: still have CT_ARCH_alpha_AVAILABLE=y |
| # 23:26:17 | diabel | # CT_ARCH_alpha is not set |
| # 23:26:21 | diabel | in .config.2 |
| # 23:26:48 | y_morin | diabel: that's OK. What's important is CT_ARCH_arm=y |
| # 23:27:26 | diabel | CT_ARCH_arm=y |
| # 23:27:29 | diabel | in .config |
| # 23:27:59 | y_morin | diabel: the _AVAILABLE symbols are here for when ct-ng is used as a backend. When used standalone, all _AVAILABLE symbols are set, which allows ct-ng to show all architectures in the menuconfig. |
| # 23:28:08 | y_morin | diabel: and in .config.2 ? |
| # 23:29:16 | diabel | yes they are too in .config.2 |
| # 23:29:17 | diabel | CT_ARCH_arm=y |
| # 23:29:17 | diabel | CT_ARCH_arm_AVAILABLE=y |
| # 23:29:28 | y_morin | diabel: OK, now run: ct-ng build |
| # 23:29:50 | y_morin | diabel: on the first few lines, you should see 'target = arm-spica-linux-uclibcgnueabi' |
| # 23:33:05 | diabel | I did the ct-ng build but I have no any string like arm-spica |
| # 23:33:46 | y_morin | diabel: sorry, 'arm-unkown-linux-uclibcgnueabi' |
| # 23:34:22 | diabel | y_morin: only have this: http://paste.kde.org/635942/ |
| # 23:35:19 | y_morin | diabel: what do you have in build.log ? |
| # 23:37:51 | diabel | ome moment |
| # 23:38:28 | diabel | http://wklej.org/id/913207/ |
| # 23:39:46 | diabel | I know that You told me to not run this under root, but I nedd to work on 7 consoles, can't not use it, I'll interputt after binutils told me it's ok |
| # 23:39:49 | y_morin | diabel: line 5832: checking target system type... alphaev4-unknown-elf |
| # 23:40:03 | y_morin | Doh... :-( |
| # 23:40:16 | y_morin | Really, I do not understand. What's your host distro ? |
| # 23:41:08 | diabel | it's debian |
| # 23:41:39 | y_morin | diabel: OK, I'm using Debian Squeeze here, and it does work. So, this is an issue on your host... :-( |
| # 23:41:41 | diabel | I have no error when i compied it long time a go, when i used arm-iphone (for my samsung galaxy spica) |
| # 23:42:08 | diabel | y_morin: the files that only math with string 'alpha' is : http://pastebin.com/kTPJb3LW |
| # 23:42:14 | diabel | I used grep -i |
| # 23:42:47 | y_morin | diabel: what is that 'config' file? |
| # 23:43:17 | diabel | ouch i cut the '.' when paste it |
| # 23:43:21 | diabel | it's .config |
| # 23:43:24 | y_morin | OK. |
| # 23:44:37 | y_morin | diabel: can you 'grep -i arm *' please? |
| # 23:45:00 | y_morin | diabel: well: grep -i arm .* |
| # 23:45:25 | diabel | one moment |
| # 23:47:02 | diabel | http://pastebin.com/ZK5JuW9Y |
| # 23:48:16 | y_morin | diabel: OK, good too. |
| # 23:50:11 | y_morin | diabel: OK, can you try this: http://code.bulix.org/a04knv-82765 |
| # 23:50:39 | y_morin | diabel: how did you run ./configure ? |
| # 23:51:30 | diabel | y_morin: ./configure --prefix=$HOME/ctng/ then adding to PATH $HOME/ctng/bin/ |
| # 23:52:48 | diabel | cp /tmp/config.save .config ??? |
| # 23:52:55 | diabel | I've no /tmp/config.save |
| # 23:54:02 | y_morin | diabel: That was the first step in the procedure... |
| # 23:54:29 | diabel | hm, moment, I'll check |
| # 23:58:15 | y_morin | diabel: with the .config you sent earlier, I have: http://code.bulix.org/wzckjo-82766 |
| # 23:59:04 | diabel | yes but I've got some little bit problem |
| # 23:59:22 | diabel | I did the ./configure --enable-local --prefix=$HOME/ctng |
| # 23:59:36 | diabel | then make; but make install did not install it :| |
| # 23:59:48 | y_morin | diabel: Doh. No. Either, not both. |