| # 21:37:08 | ctngbot | joins #crosstool-ng |
| # 21:37:25 | aneyman | I certaily hope not ;) |
| # 21:37:50 | aneyman | If this works out, I might reconsider on Win as a work environment |
| # 21:38:07 | aneyman | right now, I have Win for games & Linux for work ;) |
| # 21:38:13 | bhundven | never... (for me) |
| # 21:38:25 | aneyman | Never say never :) |
| # 21:38:29 | bhundven | ever |
| # 21:38:31 | bhundven | never |
| # 21:39:11 | bhundven | I have done my best to even stay away from the mingw/cygwin stuff |
| # 21:39:18 | aneyman | Since you're here: anything else you want me to do on #373? |
| # 21:39:47 | aneyman | I responded to your sparc comment and haven't seen wbx here (re _obstack_free in uclibc-ng) |
| # 21:42:49 | aneyman | btw, it seems there's more sparc breakage that we might need to work around: glibc does not build on sparc64, afaics GCC somehow misapplies the default -mcpu=ultrasparc which results in assembler error |
| # 21:43:05 | aneyman | tried to test my multilib branch on multiple targets :) |
| # 21:43:46 | bhundven | makes me kinda miss my sparc station III's |
| # 21:44:02 | bhundven | had 8 of them |
| # 21:44:48 | bhundven | I messaged wbx in #uclibc-ng |
| # 21:44:59 | bhundven | I'd like to wait for a response first |
| # 21:45:13 | aneyman | never dealt with sparc personally |
| # 21:45:23 | bhundven | is the sparc stuff bugged upstream? |
| # 21:45:48 | aneyman | we have an old sparc box serving as a gateway between two networks here and I think that's it :) |
| # 21:45:52 | aneyman | seems so |
| # 21:46:34 | aneyman | at least, according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16109, gcc configured for sparc64-linux should default to -mcpu=ultrasparc |
| # 21:46:49 | aneyman | but with 5.3.0 it defaults to -mcpu=v9 |
| # 21:47:32 | aneyman | I see it in the -dumpspecs output: %{profile:-p} %{m32:%{m64:%emay not use both -m32 and -m64}} %{m32:-mptr32 -mno-stack-bias %{!mlong-double-128:-mlong-double-64} %{!mcpu*:-mcpu=cypress}} %{mv8plus:-mptr32 -mno-stack-bias %{!mlong-double-128:-mlong-double-64} %{!mcpu*:-mcpu=v9}} %{!m32:%{!mcpu*:-mcpu=ultrasparc}} %{!mno-vis:%{!m32:%{!mcpu=v9:-mvis}}} |
| # 21:47:34 | aneyman | and |
| # 21:47:51 | aneyman | *asm_cpu_default: |
| # 21:47:52 | aneyman | %{m32:} %{!m32:-Av9a} |
| # 21:48:26 | aneyman | i.e., in absence of -m32, sparc64-unknown-linux-gnu-gcc should supply -mcpu=ultrasparc to cc1 and -Av9a to as |
| # 21:48:31 | aneyman | but somehow, it does not |
| # 21:49:32 | aneyman | parts #crosstool-ng |
| # 21:49:41 | aneyman | joins #crosstool-ng |
| # 21:50:08 | aneyman | damn, ^W does works differently in XChat ;) |
| # 21:50:21 | bhundven | heh |
| # 21:50:32 | bhundven | uses irssi since I left irccloud |
| # 21:50:48 | aneyman | worst case, we'd need a quirk in sparc.sh (since this is not for just glibc - it will apply to all libc variants and all companion libs/tools |
| # 21:51:12 | aneyman | but I wanted to see if it is a GCC bug (looks so, at this moment) |
| # 21:51:58 | aneyman | so many interesting corner cases that were not handled by mingwandroid's multilib branch, nor handled by stock ct-ng |
| # 21:52:55 | aneyman | superh, for example, requires multilib if we let go of the forcing everything into usr/lib (mingwandroid's branch removed that "forcing") |
| # 21:53:27 | aneyman | because on superh without multilib, -print-multi-os-directory prints "!m4" which then confuses ld |
| # 21:53:44 | y_morin | quits : Quit: Nighty Night! |
| # 21:54:18 | bhundven | Not a GCC bug. |
| # 21:54:19 | aneyman | and on mips, multiple -mabi= options do not override each other but result in ld's internal error |
| # 21:54:37 | aneyman | you mean, "!m4" is not a gcc bug? |
| # 21:54:42 | aneyman | or the sparc one? |
| # 21:54:46 | bhundven | the sparc one |
| # 21:54:53 | bhundven | it's a glibc issue |
| # 21:55:13 | aneyman | I saw the message at the end of that bug, too |
| # 21:56:11 | aneyman | but I also see this %{!m32:%{!mcpu*:-mcpu=ultrasparc}} portion in %cc1_spec and I don't understand why it is not applied |
| # 21:56:36 | aneyman | (and same for %asm_cpu_default) |
| # 21:57:40 | bhundven | https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/tree/debian/patches/sparc/local-sparcv9-target.diff |
| # 21:58:26 | bhundven | which is the opposite, right? |
| # 22:00:08 | bhundven | rather, this is the better solution over the hack you have in glibc.sh |
| # 22:01:04 | aneyman | how is it "the opposite"? |
| # 22:01:19 | aneyman | it is the same, but rather patched into glibc/configure |
| # 22:02:03 | aneyman | would you prefer to maintain a patch for glibc configure rather than tweak the architecture? be my guest, just don't forget to run 'build-all' the next time you import a new glibc :) |
| # 22:03:38 | bhundven | wrt the 'opposite', I was confused |
| # 22:03:46 | bhundven | then I got it |
| # 22:04:09 | bhundven | I spent a few weeks away from this project :P |
| # 22:04:37 | bhundven | as for the patch vs. the tweak |
| # 22:04:49 | bhundven | the tweak is probably better |
| # 22:07:45 | bhundven | and I'm still trying to grok the ultrasparc issue |
| # 22:09:02 | aneyman | FWIW ultrasparc is not addressed in #373 - we currently don't have a sparc64-linux sample |
| # 22:09:25 | aneyman | so this can be left until I post the multilib stuff |
| # 22:09:38 | bhundven | ok |
| # 22:10:02 | bhundven | I'm still holding out on merge till I hear back from wbx. |
| # 22:10:11 | bhundven | otherwise, everything looks good |
| # 22:11:02 | bhundven | aneyman: sometimes, like with the patch vs. tweak, I have to play the devil's advoicate out loud to see if it is the best way moving forward or not. |
| # 22:11:31 | aneyman | ok |
| # 22:11:52 | bhundven | updating and managing patches is not what we want to be doing |
| # 22:12:20 | bhundven | so the tweak is the right way |
| # 22:12:43 | aneyman | I am not 100% set on patching uclibc-ng - but turning off OBSTACK in uclibc-ng behind user's back (which was suggested as the other approach) looks worse to me |
| # 22:13:09 | aneyman | in uclibc-ng config |
| # 22:13:12 | bhundven | my want to wait for wbx is to see if there is something else maybe he forgot |
| # 22:14:05 | aneyman | ok, let's wait for some sane time (2-3 days maybe) and if he does not respond, then merge? |
| # 22:14:28 | aneyman | we can always change it later if there's a reason to |
| # 22:14:48 | bhundven | this release series is getting long in the tooth |
| # 22:14:51 | aneyman | but I'd like to see build-all passing so that I can use it as a regression test |
| # 22:15:10 | bhundven | I was hoping to have 2-pass gcc by now |
| # 22:15:47 | bhundven | I got it working for cross-compile, and bare-metal, but second pass is still needed for cross-canadian |
| # 22:15:59 | aneyman | well, seems like it is not happening in 1.23... and actually, I think 2-pass will not work for multilib at all |
| # 22:16:07 | aneyman | yeah, in addition to canadian |
| # 22:16:11 | bhundven | so I'm having to rework that patch series so that second pass is optional |
| # 22:16:31 | bhundven | right |
| # 22:16:39 | aneyman | I currently have a dependency on CC_CORE_PASS_1 if MULTILIB is enabled |
| # 22:16:54 | bhundven | core_pass_1 isn't going away |
| # 22:16:57 | bhundven | that is required |
| # 22:17:09 | aneyman | because I need to evaluate ARCH_CFLAG_* stuff before libgcc *or* libc is built |
| # 22:17:48 | bhundven | in my patch series, core_pass_1 is renamed to core_pass, and core_pass_2 was removed. |
| # 22:18:59 | bhundven | but now that needs to change so that |
| # 22:19:27 | aneyman | besides, while 2-pass is certainly a good thing (reducing our regression test time) - it is not really a requirement for production builds |
| # 22:19:46 | bhundven | that is the point, decrease time |
| # 22:19:48 | aneyman | since production use does not rebuild the toolchain constantly |
| # 22:20:06 | bhundven | the only reason 3 passes was required before |
| # 22:20:19 | bhundven | was that gcc needed a libc stub before building libgcc |
| # 22:20:26 | bhundven | but that was fixed in gcc-4.6 |
| # 22:20:29 | aneyman | if they did, they wouldn't be using ct-ng in the first place but rather build gcc/libc directly as a part of buildroot/openadk/... |
| # 22:20:59 | aneyman | didn't know about that |
| # 22:21:15 | aneyman | so now gcc provides libc stub itself if it is not present? |
| # 22:21:18 | bhundven | so we can build a core pass with multilib |
| # 22:21:40 | aneyman | btw, uclibc.sh also builds libm.so claiming it is needed for some powerpc target |
| # 22:21:46 | bhundven | right |
| # 22:21:48 | aneyman | is it still true? |
| # 22:22:08 | bhundven | I think that is backwards compatible for uclibc |
| # 22:22:19 | bhundven | I'm not sure if that is fixed in -ng |
| # 22:23:13 | bhundven | I think the dependency on libc.so for libgcc was removed, as libgcc can be used on baremetal |
| # 22:23:48 | bhundven | it was a while ago, I'm getting rusty on remembering stuff |
| # 22:25:23 | bhundven | one bug I'd like to see fixed for 1.23 |
| # 22:25:36 | bhundven | at the end of the build in finalize |
| # 22:25:43 | bhundven | we strip the toolchain components |
| # 22:25:47 | bhundven | if that option is enabled |
| # 22:25:54 | bhundven | ... |
| # 22:26:11 | bhundven | if the CC_LANG_GOLANG is enabled as well as stripping the tools |
| # 22:26:31 | bhundven | the wrong strip tools get used on the golang tools |
| # 22:26:42 | bhundven | and it fails, which kills the ct-ng build |
| # 22:27:42 | aneyman | that would be annoying |
| # 22:27:53 | aneyman | do you use Go? |
| # 22:28:09 | bhundven | I've had requests to get this working |
| # 22:28:16 | bhundven | I am trying to learn go as well |
| # 22:28:30 | bhundven | but I've taken time off from almost all things computers for the last few weeks |
| # 22:28:44 | bhundven | (almost all but focusing on finding work) |
| # 22:28:50 | bhundven | https://github.com/golang/go/wiki/GccgoCrossCompilation |
| # 22:28:57 | bhundven | has some tips for finishing up go |
| # 22:30:03 | bhundven | we should also install the gotools as companion tools if go is enabled |
| # 22:31:10 | bhundven | https://github.com/crosstool-ng/crosstool-ng/issues/96 |
| # 22:33:10 | blueness | quits : Quit: blueness |
| # 22:34:16 | aneyman | looked at the build log in that issue |
| # 22:34:34 | aneyman | so, what *is* the format of powerpc-unknown-linux-gnu-gccgo? |
| # 22:35:01 | aneyman | powerpc-unknown-linux-gnu-go, that is |
| # 22:35:02 | bhundven | powerpc |
| # 22:35:12 | bhundven | which I think is strange |
| # 22:35:19 | aneyman | why? isn't it a cross toolchain? |
| # 22:35:27 | bhundven | that's what I was thinking |
| # 22:35:29 | aneyman | that's supposed to run on x86_64-linux? |
| # 22:36:22 | bhundven | Really, Sometimes I need someone on this project to confirm I'm not crazy. |
| # 22:36:26 | aneyman | so it is not that the wrong strip tool is used; rather, it seems something bogus gets compiled as the "powerpc-*-go" |
| # 22:37:26 | bhundven | well, I would think that if it is called 'powerpc-*-go{,fmt}' that it would go in the prefix/bin |
| # 22:37:38 | bhundven | and if it was meant for the target it would go in the sysroot |
| # 22:37:58 | bhundven | so I should talk with Ian and clear this one up |
| # 22:39:20 | aneyman | ok, let me crawl back to work stuff :) |
| # 22:39:38 | bhundven | Sure! :) I have some other things I need to do. |
| # 22:39:42 | aneyman | suggest to wait till Friday for wbx response on #373 |
| # 22:39:51 | aneyman | if none, merge as is? |
| # 22:39:54 | bhundven | I'll give him till the end of the WE |
| # 22:40:06 | bhundven | incase work has him too loaded for this week |
| # 22:40:10 | aneyman | ok |
| # 22:40:17 | bhundven | then monday... |
| # 22:40:18 | aneyman | till Mon, then :) |
| # 22:40:20 | bhundven | the hammer falls |
| # 22:40:22 | bhundven | :) |
| # 22:40:31 | bhundven | s/the/then/ |
| # 22:40:43 | aneyman | it's not like we can't change it later |
| # 22:40:54 | bhundven | sure |
| # 22:41:35 | aneyman | my concern was that switching off OBSTACK may break some target stuff build (target_binutils, for example) or something for the end-user that was building with 1.22 and will no longer build with 1.23 |
| # 22:42:39 | aneyman | gone debugging a weird hang... |
| # 22:46:11 | blueness | joins #crosstool-ng |
| # 22:52:56 | djmott | joins #crosstool-ng |
| # 22:55:14 | Dmott | quits : Ping timeout: 268 seconds |
| # 23:21:05 | luc4 | quits : Quit: luc4 |
| # 23:22:24 | djmott | quits : Ping timeout: 244 seconds |
| # 23:38:34 | blueness | quits : Quit: blueness |
| # 23:45:48 | blueness | joins #crosstool-ng |