ibotlog2html for #crosstool-ng

<< Previous 2016-03-30 Next >>

# 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

Generated by ibotlog2html by Yann E. MORIN