#ubuntu-toolchain 2005-10-16
<dansydo> anybody here familiar with configuring scanners?
#ubuntu-toolchain 2006-10-09
<fabbione> doko_: ah ok
#ubuntu-toolchain 2006-10-10
<rickey> hello
<fabbione> doko_: ping?
<doko_> fabbione: pong
<fabbione> doko_: http://librarian.launchpad.net/4711367/buildlog_ubuntu-edgy-sparc.gcc-3.3_1%3A3.3.6-13_FAILEDTOBUILD.txt.gz
<fabbione> i am bit puzzled about the issue
<fabbione> the FTBFS is "caused" by glibc-2.4
<fabbione> gnu/stubs.h did change from 2.3 to 2.4
<fabbione> in 2.3 it was the real include
<fabbione> in 2.4 is a wrapper that loads either stubs-32.h or stubs-64.h according to WORDSIZE that's defined by gcc
<fabbione> now
<fabbione> the interesting thing is that in /usr/include/gnu/ there are stubs-32.h and stubs.h
<fabbione> in /usr/include/sparc64-linux-gnu/gnu there are stubs-64.h and stubs.h
<fabbione> the 2 stubs.h are identical
<fabbione> this situation is consistent on all arches
<fabbione> now.. i believe that gcc-3.3 should look in /usr/include/sparc64-linux-gnu/ when building 64 bit stuff but it doesn't
<fabbione> this bug didn't show up in Debian yet, because their glibc in sid are still 2.3.6 and the one in experimental are totally broken
<fabbione> point is that i have no idea on how to get gcc to look there
<fabbione> if you can hand me a patch on the fly i can test build for you
<doko_> sparc, or powerpc?
<fabbione> sparc
<fabbione> ppc is fine
<fabbione> it was not biarch at the time
<doko_> hmm, yes; it doesn't look there ...
<fabbione> yeah i know :) i did spend the last 3 hours poking at it but i truly sucks at gcc
<fabbione> we will need to sit together a bit in UDS MV 
<fabbione> CROSS_SYSTEM_HEADER_DIR = $(gcc_tooldir)/sys-include 
<fabbione> this one should be the thing that includes that path
<fabbione> i think
<fabbione> brb
<doko_> gcc-3.3 (1:3.3.6-14) unstable; urgency=low
<doko_>   * Apply the biarch-include patch for non-biarch architectures as well;
<doko_>     adding /usr/include/<target_alias> to the standard include path.
<doko_>  -- Matthias Klose <doko@debian.org>  Fri, 14 Jul 2006 15:31:03 +0000
<doko_> hmm, never uploaded ...
<doko_> but ... it should have it for sparc. strange
<fabbione> doko_: ok.. do you want to give me the debdiff so i can test build?
<fabbione> or just upload.. or whatever
<fabbione> it needs to be in the archive sooner later than later
<fabbione> Tollef is killing uninstallable pkgs in the archive
<fabbione> and gcc-3.3 FTBFS makes a couple of -docs uninstallable in edgy/main
<doko_> fabbione: does gcc-3.3 -v -m64 prints the include dir?
<fabbione> gcc-3.3 -v -m64
<fabbione> Reading specs from /usr/lib/gcc-lib/sparc-linux-gnu/3.3.6/specs
<fabbione> Configured with: ../src/configure -v --enable-languages=c,c++,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --with-cpu=v7 sparc-linux-gnu
<fabbione> Thread model: posix
<fabbione> gcc version 3.3.6 (Ubuntu 1:3.3.6-10)
<fabbione> no
<doko_> fannione: please check  http://people.ubuntu.com/~doko/
<fabbione> fannione? :P
<fabbione> building now
<doko_> oops ... sorry fanny ;-)
<fabbione> eheh
<fabbione> hmm no
<fabbione> didn't help
<fabbione> oh it was not applied at all
<fabbione> ifneq ($(biarch),yes)
<fabbione>  ?
<fabbione> shouldn't that be ifeq ($(biarch),yes)
<fabbione>  ?
<fabbione> ./xgcc -B./ -B/usr/sparc-linux-gnu/bin/ -isystem /usr/sparc-linux-gnu/include -isystem /usr/sparc-linux-gnu/sys-include -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include  -m64 -DL_muldi3 -c ../../src/gcc/libgcc2.c -o libgcc/64
<fabbione> /_muldi3.o
<fabbione> In file included from /usr/include/features.h:346,
<fabbione>                  from /usr/include/stdio.h:28,
<fabbione>                  from ../../src/gcc/tsystem.h:72,
<fabbione>                  from ../../src/gcc/libgcc2.c:37:
<fabbione> /usr/include/gnu/stubs.h:9:27: gnu/stubs-64.h: No such file or directory
<fabbione> this is with the patch applied
<fabbione> same error
<fabbione> i don't see that path included
<doko_> hmm, you should run ./xgcc -v ...
<fabbione> ./build/gcc/xgcc -v
<fabbione> Reading specs from /usr/lib/gcc-lib/sparc-linux-gnu/3.3.6/specs
<fabbione> Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --with-cpu=v8 sparc-linux-gnu
<fabbione> Thread model: posix
<fabbione> gcc version 3.3.6 (Ubuntu 1:3.3.6-13ubuntu1)
<doko_> no, I mean the whole line, including all args
<doko_> sorry
<fabbione> doko_: see /msg
<fabbione> it's still not there
<fabbione> oh hoild on
<fabbione> it's missing a piece
<doko_> fabbione: you don't have the same problems with 3.4 and 4.0?
<fabbione> doko_: dunno
<fabbione> checking LP build logs
<fabbione> doko_: it looks like they are ok
<fabbione> they have been built with 2.4-1ubuntu6
<fabbione> i can try to rebuild them if you want
<doko_> ahh, yes, they will fail in the same way now. 
<fabbione> hmmm
<fabbione> hold on a sec
<fabbione> if they fail now and they did build before.. this might be a regression in glibc misplacing the include file
<fabbione> let me check
<doko_> no, not misplacing, but putting it into /usr/include/sparc64-linux-gnu
<fabbione> i want to check where it was in ubuntu6
<fabbione> nope.. it was in the same place also in ubuntu6
<fabbione> i wonder if something else did change and it is defining WORDSIZE=64
<fabbione> perhaps it was set to 32 before?
<doko_> $ diff -ur 32/usr/include 64/usr/include/sparc64-linux-gnu|less
<doko_> Only in 32/usr/include/gnu: stubs-32.h
<doko_> Only in 64/usr/include/sparc64-linux-gnu/gnu: stubs-64.h
<doko_> Only in 32/usr/include/rpcsvc: bootparam_prot.h
<doko_> Only in 32/usr/include/rpcsvc: key_prot.h
<doko_> Only in 32/usr/include/rpcsvc: klm_prot.h
<doko_> Only in 32/usr/include/rpcsvc: mount.h
<doko_> Only in 32/usr/include/rpcsvc: nfs_prot.h
<doko_> Only in 32/usr/include/rpcsvc: nlm_prot.h
<doko_> Only in 32/usr/include/rpcsvc: rex.h
<doko_> Only in 32/usr/include/rpcsvc: rquota.h
<doko_> Only in 32/usr/include/rpcsvc: rstat.h
<doko_> Only in 32/usr/include/rpcsvc: rusers.h
<doko_> Only in 32/usr/include/rpcsvc: sm_inter.h
<doko_> Only in 32/usr/include/rpcsvc: spray.h
<doko_> Only in 32/usr/include/rpcsvc: yppasswd.h
<doko_> that's libc6-dev libc6-dev-sparc64 compared
<fabbione> yeah they didn't change between ubuntu6 and ubuntu11
<fabbione> (glibc i mean)
<fabbione> and gcc-3.4 and 4.0 were built with ubuntu6
<fabbione> if they can't build anylonger
<fabbione> it can only be because WORDSIZE did change from 32 to 64
<fabbione> so stubs.h tries to include something else
<doko_> no, I think gnu/stubs-64.h was installed as /usr/include/gnu/stubs-64.h
<fabbione> did check that too
<fabbione> it was in /usr/include/sparc64-linux-gnu|less
<fabbione> <doko_> Only in 32/usr/include/gnu: stubs-32.h
<fabbione> ops
<fabbione> it was in /usr/include/sparc64-linux-gnu
<fabbione> https://launchpad.net/+builds/+build/216534/libc6-dev-sparc64
<fabbione> this is the deb for ubuntu6
<doko_> crap, the older build logs are not available
<fabbione> ask infinity 
<fabbione> perhaps they are still stored in dak
<doko_> hmm, no it was always installed in /usr/include/sparc64-linux-gnu
<doko_> ahh, did look at the wrong patch ...
<doko_> fabbione: do we need 3.3 to be built as biarch?
<fabbione> (phone ... one sec)
<fabbione> doko_: well i don't want to change gcc-* behaviour now
<fabbione> i want to have it as it should be
<fabbione> let me check if gcc-3.4 and 4.0 suffer of the same issue
<doko_> fabbione: the only reason for 3.3 beeing in the archive is libstdc++5.
<doko_> no, 3.4 and 4.0 work
<fabbione> yes i am aware of that
<fabbione> ok
<doko_> so, do you even need that one on sparc?
<fabbione> i dunno.. we might
<doko_> ok, but not for 64bit, right?
<fabbione> doko_: i have no clue if users have 64bit apps installed.. we can't predict
<fabbione> i know a lot of people at SUN build 64 bit stuff on Linux.. i get bugged by email about them
<fabbione> (hence why i was considering a pure64 sparc port)
<doko_> fabbione: we didn't have a release with a g++-3.3 biarch for sparc ...
* fabbione scratches his head...
<fabbione> doko_: is it so complicated to get it building?
<fabbione> either i totally miss the point of your questions.. or we could just fix the FTBFS (best)
<doko_> fabbione: apparently I tried, back in July, the package I sent you already disabled biarch for i386 ...
<fabbione> back in July we didn't have glibc-2.4 :)
<fabbione> Debian is even in a worst situation because their glibc doesn't even have stubs-64.h
<fabbione> it seems lost somewhere
<doko_> 2006-06-08 02:08:54 CEST  	Removed  	edgy   	Release  	main  	libs  	2.4-1ubuntu0
<fabbione> doko_: just do what you think it's right...
<fabbione> and let's try to avoid to kill the world
<doko_> devil^Wsparc's advocate 
<fabbione> *grins*
<doko_> fabbione: faure:~doko/gcc/3.3/
<fabbione> doko_: what do you want me to do with it?
<fabbione> oh i see :)
<doko_> please check if 64bit C++ works for you
#ubuntu-toolchain 2006-10-11
<fabbione> doko: yes it works great
<doko> fabbione: in the archive
<fabbione> yeps i saw it.. thanks a lot dude
#ubuntu-toolchain 2006-10-12
* infinity frowns.
<infinity> gcc -m64 -march=x86-64 -mtune=x86-64 -O3 -g -D_REENTRANT -fPIC -DNO_snprintf -DHAS_sprintf_void -DNO_ERRNO_H -o example example.o -L. libz.a
<infinity> /usr/bin/ld: errno: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS reference in libz.a(gzio.o)
<infinity> /lib64/libc.so.6: could not read symbols: Bad value
<infinity> collect2: ld returned 1 exit status
<infinity> make[1] : *** [example]  Error 1
<infinity> doko_: When you're alive, ping me.
<doko_> infinity: pong
<infinity> doko_: Check the above.  zlib is FTBFS on i386.
<doko_> infinity: other 64bit builds as well?
<infinity> Just i386, afaict.
<infinity> Or, you mean "other packages with biarch builds"?
<infinity> In which case, this is the first I've seen.
<doko_> yes
<doko_> infinity: fixed, that's fallout from our gcc-opt hackings :-/
<infinity> doko_: Ahh.
<infinity> doko_: When you say "fixed", does that include "uploaded"?
<infinity> Oh, someone else already accepted it, I see.
<doko_> yes
<infinity> Thanks.
#ubuntu-toolchain 2006-10-13
<fabbione> doko_: please ignore the mail i did send to you. It was fixed by pitti 
#ubuntu-toolchain 2007-10-08
<arthur-> doko: do you still disagree with the splitted libphobos-dev package?
#ubuntu-toolchain 2007-10-09
<doko> arthur-: did you update gdc-4.1?
<doko> +Package: libphobos`'PHOBOS_V`'PV-dev
<doko> +Description: The phobos D runtime library
<arthur-> doko: I'm doing this right now
<arthur-> doko: sent you a mail
<arthur-> doko: I have some fixes for sh4 targets at least for gcc-4.1, I'll send you them too
<doko> arthur-: +- Donne: add the gdc build infrastructure to gcc 4.2 and 4.3.
<doko> what does Donne mean?
<arthur-> oups...
<arthur-> sorry
<arthur-> Done*
<doko> why a Done entry in a TODO file?
<arthur-> doko: right... please remove it
<lamont> doko: do you have debs for me?
<lamont> (icedtea-java7)
<doko> sure, emailed or msegd to you
<doko> deb http://people.ubuntu.com/~doko/ubuntu gutsy/
<doko> deb-src http://people.ubuntu.com/~doko/ubuntu gutsy/
<doko> lamont: ^^^
<doko> i386, amd64, lpia
<lamont> lpia.  sigh.
<lamont> must I?
<doko> yes
<lamont> OK.  that's the one chroot I don't already have a basis for
<doko> well, start with i386, then amd64
<lamont> right
<doko> you need the -bin, -jre and -jdk packages for bootstrapping
#ubuntu-toolchain 2007-10-10
* Starting logfile irclogs/ubuntu-toolchain.log
<lamont> doko: icedtea-java7 is ftbfs on i386/amd64 - e.g., http://launchpadlibrarian.net/9920793/buildlog_ubuntu-gutsy-i386.icedtea-java7_7%7Eb21-1.4%2B20071007-0ubuntu1_FAILEDTOBUILD.txt.gz
<lamont> OTOH, if you upload to fix that, it'll just try to build
<lamont> lpia will still dep-wait itself though, until we figure out why the deb won't install on ronne and fix that.
<doko> lamont: reuploaded, waiting for approval
<Mithrandir> doko: accepted.
<doko> Mithrandir: thanks
<doko> lamont: rebuilt the lpia packages ... looks like I built in the wrong lpia chroot, having gcc-4.3 as it's default
<lamont> doko: ah, ok
* lamont -> work, will bootstrap there
<lamont> LP build of icedtea-java7/lpia running
<lamont> well, queued anyway
* Starting logfile irclogs/ubuntu-toolchain.log
<lamont> oops.  I need to push the bootstrapping chroot for lpia
#ubuntu-toolchain 2007-10-11
<doko> lamont: so how often did you build icedtea? ;)
<lamont> doko: I did one build on ronne, and then it built in launchpad, and then one upload so that it's in launchpad built with launchpad-built-binaries
<doko> ahh, ok. we usually did skip the last step because it would be rebuilt anyway
<lamont> doko: right
<lamont> I wasn't sure if you had another upload planned or not
<doko> lamont: does this address your hppa problems? http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00603.html ?
<lamont> doko: probably
<lamont> doko: if you want to give me a source package with that, I have a machine where I can build the compiler and proceed to test java stuff out...
<lamont> for bonus points, turn off the test suite, just for this test build. :-)
#ubuntu-toolchain 2007-10-12
* Starting logfile irclogs/ubuntu-toolchain.log
* lamont discovers that the hppa buildds already had the no-unligned-traps crowbar thrown.
<lamont> doko: so the gij-4.2 hack only made it so that people couldn't reproduce buildd failures on paer.
<lamont> heh... actually, paer has the big crowbar thrown too
<doko> lamont: ok, I'll turn off building java for hppa
<lamont> the preference would be to actually get a toolchain that works on gutsy with that patch from yesterday, even if it needs unaligned traps enabled for the moment
<doko> lamont: please ask slangasek =)
<lamont> because whatever is currently in sid is working with unaligned traps disabled
<doko> besides the interpreter ...
<lamont> I didn't say _in_ gutsy.  I just want a working toolchain so that we know it's all good when hardy opens
<lamont> I haven't seen java failures on sid...
<doko> because it's not used, correct
<lamont> note that I didn't just disable unaliged traps - they have been disabled on the buildds for _months_
<lamont> so what is the interpreter doing that it needs unaligned support and can't tell gcc to generate code that does it in the app?
<doko> have a look, the problem is there for years
<lamont> doko: it would help if I knew the first thing about java...
<lamont> and had a working  java (even requiring unaligned) on any hppa box (which means gutsy these days)
<doko> lamont: ok, I can prepare an upload, please get the ok on #ubuntu-release
<lamont> doko: not for upload.  for me to work with
<lamont> I couldn't justify changing the compiler this late in things
<doko> lamont: it hppa conditional only
<lamont> so if you could make what you would have prepared for a gutsy upload, along with debs for same, then I can smash through debugging it, and we can get it fixed in (1) sid and (2) hardy
<lamont> I'll ask, I don't expect much in the way of a yes though.
<doko> lamont: it's fixed in sid
<lamont> I need to go fetch kids now though
#ubuntu-toolchain 2008-10-09
<munckfish> doko: re bug 280451. I can do this for powerpc but I'm gonna need some cross compilers for the other archs
<munckfish> https://bugs.launchpad.net/ubuntu/+source/linux-ports/+bug/280451
<munckfish> doko: could you tell what the build dep should be? Is there like a 'gcc-default' meta/provides thing I can specify to get whatever the current gcc is?
<doko> I don't understand; linux-ports does require cross compilers?
<doko> munckfish: well, you would have to check that the package still works after changing the compiler. so we should now depend on gcc-4.3 explicitely if this results in a working kernel
<munckfish> doko: ok understood. The reason I would need cross compilers is
<munckfish> 1. My PS3 is dog slow at compiling the kernel - I've been using ppu-gcc 4.1 on my x86 laptop to do more frequent test builds
<munckfish> 2. To test compile the other archs in the ports kernel I'd need cross compilers for each
<munckfish> I have tried making gcc 4.3 powerpc64 cross compiler but it gets stuck on a wrong linker search path when building libgcc
<doko> well, then do it for each architecture you have access to.
<doko> maybe pester lamont about hppa
<munckfish> doko: ok. lamont has a hppa kit? ok cool
<munckfish> doko: how soon should this be done are you trying to drop 4.1 for intrepid?
<munckfish> I can't remember if there was some historic reason why 4.1 was needed for powerpc I've asked in the #ubuntu-kernel if anyone knows
<munckfish> doko: ^ when does this need to be actioned by? when are you planning on dropping 4.1?
<doko> asap
<munckfish> ok thx
#ubuntu-toolchain 2009-10-08
<ramana_> doko_: glad to hear the oo.o problem got fixed. 
<doko_> ramana_: yes, thanks for the help! I'll follow-up with email.
<ramana_> doko_: anytime - Sorry I couldn't be of more assistance. 
<ramana> doko_: ping
<doko_> ramana: pong
<ramana> doko: I tried the binutils 2.19.92-rc2 snapshot on an arm-linux board that I've got access to running Debian Lenny and don't see the test failures that you see. However the number of tests I run are significantly lower than yours. 
<ramana> Ofcourse the 2.19.92-rc2 snapshot includes Jakub's gas patch . 
<doko_> yes, the snapshot includes the patch as well.
<doko_> for historical reasons the binutils in ubuntu includes some of the hj lu patches; checked that disabling these doesn't help
<ramana> ok
<ramana> as well as trying gcc-4.3 doesn't help . 
<ramana> ?
<doko_> right, and building with -fno-stack-protector -U_FORTIFY_SOURCE neither
<doko_> currently looking at our buildlogs at https://launchpad.net/ubuntu/+source/binutils/+publishinghistory when the failures do appear
<doko_> they are in 2.19.51.20090620, not in 2.19.51.20090423
<doko_> in 2.19.51.20090515
<ramana> I'm still new to launchpad. 
<ramana> so I clicked a link and got here https://launchpad.net/ubuntu/+source/binutils/2.19.51.20090515-0ubuntu1/+build/1030198 - not sure where you are seeing the test logs
<doko_> there is link called buildlog, search for the second occurrance of test-summary
<doko_> they are in 20090508
<doko_> ramana: between 20090423 and 20090508
<ramana> ok . atleast we know the range now to look at. 
<ramana> Is this failure only armel specific or do you see it on other arch's as well ? 
<ramana> I thought your report on binutils@ suggested that you were seeing similar failures on mips ? 
<doko_> yes, I see these on mips as well
<doko_> and mipsel
<doko_> but mips fails in 2.19.1 as well
<doko_> and 2.18.1
<ramana> hmmm
<doko_> now running a 20090430 build
<ramana> ok
<ramana> well do any more hj lu patches need to be backported in . I see there is a http://www.kernel.org/pub/linux/devel/binutils/binutils-2.20.51.0.1.tar.bz2
<ramana> unless you've seen this already . 
<doko_> no, didn't look yet, but as we don't see this in the debian build, I doubt we find the solution there. 
<doko_> debian has one more difference: built with -march=armv4 by default
#ubuntu-toolchain 2009-10-09
<doko_> hmm, have to downgrade libc6, the old binutils don't understand .cfi_sections
<ramana> hmmmm
<ramana> I'm gonna have to go now .. Is it that you can't run the ld testsuite from 20090430 with the old build ? 
<ramana> of libc6
<doko_> I'll do, but maybe not now, I'll start it and go to bed ...
#ubuntu-toolchain 2011-10-15
<_Andrew> Has anyone else been bitten by the fact that cmake is broken for 64bit builds with 11.10?
#ubuntu-toolchain 2017-10-11
<srwarren> Is it public knowledge what gcc and glibc versions will be used on 18.04 yet?
<srwarren> (I'm aware that toolchain upload deadlines are very soon after development opens for a release, so I guess the selection is likely already made; I just don't know if it's public beforehand)
#ubuntu-toolchain 2017-10-12
<doko> srwarren: no yet, but we'll stick with GCC 7 as the default
<srwarren> doko, thanks.
