#ubuntu-toolchain 2005-10-17
<jbailey> So,erm...  The LiveCD sees the sound card in my G5, and the regular hotplug on the system doesn't. =)
#ubuntu-toolchain 2005-10-22
<fabbione> doko: http://people.ubuntu.com/~fabbione/gcc-4.1.log.bz2
<fabbione> we didn't get that far at all
<doko_> fabbione: it needs some love to _build_ biarch. it should build fine, if you
<doko_> disable biarch (debian/rules.defs:583).
<fabbione> doko: well what's the point of not building biarch?
<fabbione> we need biarch for the kernel
<fabbione> and quite a bunch of stuff
<fabbione> doko: so you plan to make 4.1 the new default compiler for dapper?
<fabbione> or are we going to stick with 4.0 and start preparing 4.1?
<fabbione> that's sort of important given that dapper will open soon
<fabbione> and we do have a set of SCC release out there
<doko> fabbione: we'l have to rebuild the archive first, and decide then, not the other way around.
<fabbione> #ifdef SPARC_BI_ARCH
<fabbione> #undef CPP_ARCH32_SPEC
<fabbione> #define CPP_ARCH32_SPEC "%{mlong-double-128:-D__LONG_DOUBLE_128__}"
<fabbione> #endif
<fabbione> this is in gcc/src/sparc/linux64.h
<fabbione> as far as i can tell that one should just go away
<doko> that looks ok for the 32bit case
<fabbione> yes exactly
<fabbione> the same lines are both for 32 and 64 bit
<fabbione> i can see that __LONG_DOUBLE_128 is used later on
<fabbione> i suspect that the mlong-double-128 bit should disappear
<fabbione> let see.. it's building the normal one from scratch
<fabbione> i have seen too many kick the rebuild and it works cases
<fabbione> doko: the rebuild archive bit is scary.. specially because sparc doesn't have the horse power yet to do that
<fabbione> doko: when building gcc.. and get these errors, can i safely do the modification and ./debian/rules build?
<fabbione> or is it better to create the patch and rebuild from scratch?
<doko> fabbione: no, you need to rerun the configury ... shortest way: rm stamps/05-build-stamp; make -C build
<doko> sorry, make -C build bootstrap
<fabbione> i think that error shows up way before that stamp
<fabbione> yeah there is no 05
<doko> ok, plese remove the configure stamp
<fabbione> ok
<doko> hmm, maybe we want to set need_64bit_hwint=yes as well for the biarch case (config.gcc)
<doko> fabbione: what was the name of the ia64 machine in the dc?
<doko> fabbione; ^^^
<fabbione> halley
<fabbione> doko: i can't get out of that error
<fabbione> i managed to get rid of the -128 thing
<fabbione> but not the -64
<fabbione> ../../src/gcc/crtstuff.c:1: error: -mlong-double-64 not allowed with -m64
<fabbione> and i did remove all possible references of that in gcc/config/sparc
<fabbione> so it's either autogenerated somewhere
<fabbione> or hidden in some .$fuckdir that i can't find
<doko> did you set need_64bit_hwint=yes ?
<fabbione> no
<fabbione> i am testing one bit at a time
<fabbione> otherwise we can't isolate it properly...
* fabbione cleans the tree and tries again with that
<doko> btw, did you get some feedback if OOo is actually working on sparc?
<fabbione> doko: i did test it personally and i even told you :)
<fabbione> that's faster than amd64 :)
<doko> ahh, I remember :-)
<fabbione> now.. fix gcc-4.1 dude..
<doko> fabbione: so you build kernels and glibc using 4.0 on sparc?
<fabbione> doko: we also need to fix gcc-4.0
<fabbione> no
<doko> ahh
<fabbione> we don't do that even on main arches
<doko> I know
<fabbione> meh can you give me the line in config.gcc where i am supposed to stick that need_64bit thingy?
<fabbione> doko: we also want to look at this failure http://bld-3.mmjgroup.com/buildLogs/k/klibc/1.0.14-1ubuntu2/klibc_1.0.14-1ubuntu2_20050915-0618-sparc-failed.gz
<fabbione> that happens only with gcc-4.0
<doko> fabbione: about 307, same as for sparc64
<fabbione> doko: ok.. there is also another reference at around 2004
<fabbione> sorry 2047
<fabbione> ok let's try with only this change
<fabbione> and see what happens
<fabbione> doko: same story with that modification of config.gcc
<doko> :(
<fabbione> doko: time to fire up your sparc and install breezy?
<doko> fabbione: have to get it going for the standard architectures first, currently wading through test results.
<fabbione> doko: you can still do it in parallel :)
<fabbione> doko: so ok.. i am going to try to disable biarch to test build
<doko> fabbione: thanks
<fabbione> doko: no problem, but please try to get biarch working :)
<fabbione> doko: it fails even disabling biarch
<fabbione> at a different point
* fabbione collects the log
<doko> yep, please send me it
<fabbione> yup
<fabbione> doko: do you prefer email or web?
<doko> web is ok
<doko> fabbione: ^
<fabbione> ok
<fabbione> doko: people/~fabbione
<fabbione> there are 2 gcc-4.1-* log files
<fabbione> with and without biarch defined in debian/rules.defs
<doko> well, yes, that patch could be more robust
<fabbione> don't assume i know all the patches applied to gcc..
<fabbione> i just build gcc on your commands :)
<doko> fabbione: updated, same location
<fabbione> doko: ok.. taking it now
<infinity> doko : Mail me when you have (what you believe to be) finalised sources for the gcc-4.1 testbuild, I'll bootstrap it on the buildds, and we'll see if we can get a breezy-gcc-4.1 building before UBZ.
<fabbione> doko: i will let you know soon how it goes.. it's building 
<fabbione> still didn't pass that point tho
<doko> fabbione: it's currently in stage3 in my build
<fabbione> on sparc?
<doko> yes
<fabbione> ah cool
<fabbione> did you actually bootstrapped a breezy chroot ? or are you building on debian?
<doko> breezy
<fabbione> ohhh finally :)
<doko> stopped the sid build after it completed stage1
<fabbione> did it bootstrap properly?
<fabbione> it should have...
<doko> don't know, did it two months ago
<fabbione> ahh
<fabbione> ehehe
<fabbione> ok thanks dude.. bbl
<lamont__> configure: error: 
<lamont__> The following requested languages could not be built: ada
<lamont__> Recognised languages are: c,ada,c++,fortran,java,objc,obj-c++,treelang
* lamont__ kicks doko
<doko> lamont__: I'm innocent ;-p
<lamont__> checking for gnatbind... gnatbind
<lamont__> checking whether compiler driver understands Ada... no
<doko> gnat-3.4 or gnat-4.0?
<doko> lamont__: what did you use for bootstrapping?
* lamont__ tries the simple thing first
<lamont__> breezy
<lamont__> and sbuild
<lamont__> well, actually, dpkg-buildpackage
<lamont__> so gcc-4.0, I expect
<doko> strange, anything more in the changelog?
<doko> s/changelog/config.log/
<lamont__> iz my bad
<lamont__> configure didn't like the 'could not open /CurrentlyBuilding'
<doko> ;.)
<doko> lamont__: but I should warn you ...
<doko> xgcc: ../libmath/.libs/libmath.a: No such file or directory
<doko> xgcc: ../libmath/.libs/libmath.a: No such file or directory
<doko> make[7] : *** [libstdc++.la]  Error 1
<doko> I don't know why ...
<doko> works even on sparc
* lamont__ will look
<fabbione> doko: s/even//g
<fabbione> doko: sparc > hppa ;) ask lamont on the final breezy buildd run :P
* fabbione hides from lamont
<lamont__> fabbione: that's all kde's fault
<fabbione> ehehe
<lamont__> well, actually, it's gcc-4.0's fault
<lamont__> since it liked to ICE for lots of kde packages
<doko> well, remembers me on hppa's messages on kernel errors: "your system ate a sparc."
<fabbione> ahha
<lamont__> "      _______________________________ \n"
<lamont__> "     < Your System ate a SPARC! Gah! >\n"
<lamont__> "      ------------------------------- \n"
<lamont__> "             \\   ^__^\n"
<lamont__> "              \\  (xx)\\_______\n"
<lamont__> "                 (__)\\       )\\/\\\n"
<lamont__> "                  U  ||----w |\n"
<lamont__> "                     ||     ||\n");
<lamont__> iz in die_if_kernel()
<lamont__> and that's from upstream. :-
<lamont__> )
<fabbione> ahahha
<doko> lamont__, maybe fabbione has difficulties laughing about it ;-P
<fabbione> why?
<lamont__> arch/parisc/kernel/traps.c
<doko> we should help him ;)
<lamont__> machine eats sparc, dies.
<lamont__> film at 11
<doko> fabbione: sparc build is in libjava ...
<fabbione> doko: it's building here
<fabbione> stage1/xgcc -Bstage1/ -B/usr/sparc-linux-gnu/bin/ -c   -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute     -DHAVE_CONFIG_H -I. -Ifortran -I../../src/gcc -I../../src/gcc/fortran -I../../src/gcc/../include -I../../src/gcc/../libcpp/include     ../../src/gcc/fortran/match.c -o fortran/match.o
<fabbione> i guess i am far behind you
<doko> fabbione: we'll have two independent results, I think, my hppa build is failing for some other reasons
<fabbione> doko: yes.. i prefer to have 2 of them
<fabbione> doko: given how delicate is gcc
#ubuntu-toolchain 2005-10-23
<doko> fabbione: testsuite nearly finished, looks fine
#ubuntu-toolchain 2006-10-20
<jbailey> doko: Hey.  Do we have a toolchain repo yet?
<doko> jbailey: no
<jbailey> Whee...
<infinity> 09:41 < infinity> malcc: What's our current status on feisty?
<infinity> 09:42 < malcc> infinity: kiko spoke to mdz, and my understanding of the conclusion is that we're 
<infinity>                not opening it early after all
<jbailey> infinity: Thanks.
<doko> interesting :-/
#ubuntu-toolchain 2006-10-21
<doko> fabbione: please see debian #394325
#ubuntu-toolchain 2006-10-22
<fabbione> doko: we don't support sparc32 and we don't have that problem in dapper/edgy
#ubuntu-toolchain 2007-10-18
<lamont> doko: how hard would it be to make gcc internally detect the cases from: http://wiki.debian.org/ImplicitPointerConversions
<lamont> (they are errors that are currently listed as two warnings()
<doko> lamont: waiting for gcc-4.3
 * lamont searches for context.
<lamont> implict defn pointer use. right.
#ubuntu-toolchain 2007-10-19
<doko> lamont: gcc-4.2 ftbfs on hppa/hardy. expect problem? if yes please fix
#ubuntu-toolchain 2007-10-21
<doko> lamont: kohnen, primero: Not available because:
<doko> <socket.error instance at 0x2ad83ed5a878>
#ubuntu-toolchain 2015-10-15
<zaytsev> doko: hi there :) here i am again to ping you, any chance to kick off gcc 5.2 build to precise?
