#ubuntu-toolchain 2005-09-05
<fabbione> morning
* mode/#ubuntu-toolchain [-s]  by ChanServ
<lamont> jbailey: any word on: /usr/include/linux/socket.h:10: error: redefinition of 'struct sockaddr'
<jbailey> Arch and/or package, please?
<jbailey> My brain's been a bit full lately.
<elmo> jbailey/fabbione: the --as-needed stuff is a mess
<jbailey> elmo: From the bit that I posted for him?
<jbailey> Or do you mean in the archive?
<elmo> it has a touch-all testsuite update, which depends on an earlier touch-all testsuite update which isn't easily backportable
<jbailey> Right, the testsuite will suck incredibly.
<jbailey> I think the best bet for Debian is a CVS update, the best for Ubuntu (hppa, sparc) is to ignore the testsuite and pray.
<elmo> well, I'm leaving ubuntu up to you guys
<elmo> a CVS update for Debian isn't a horrible idea actually
<elmo> let's ask drow
<jbailey> elmo: Where are you asking?
<elmo> privmsg
<elmo> old cabal habits die hard
<jbailey> *lol*
<fabbione> elmo/jb: i just finished to build binutils...
<fabbione> but i am too tired right now to do sensible tests
<fabbione> will do it tomorrow morning
<jbailey> fabbione: Can you humour me and do hello world at least?
<fabbione> jbailey: sure...
<fabbione> what was the bug number for the binutils?
<elmo> #320697:
<fabbione> no .. in ubuntu
<jbailey> 12822
<fabbione> there.. 
<fabbione> thanks
<fabbione> jbailey: you know what?
<fabbione>  grep PROCEDURE_LINKAGE_TABLE *
<fabbione> Binary file libGL.so.1.2 matches
<fabbione> sparcbuildd@vultus5:~$ gcc hello.o -Wl,--as-needed /usr/lib/libGL.so.1.2
<fabbione> sparcbuildd@vultus5:~$ ./a.out 
<fabbione> hello world!
* fabbione starts the binutils go and die dance because jbailey rocks
<jbailey> Did that used to fail?
<fabbione> sparcbuildd@vultus5:~$ gcc hello.o -Wl,--as-needed /usr/lib/libGL.so.1.2
<fabbione> sparcbuildd@vultus5:~$ ./a.out 
<fabbione> hello world!
<fabbione> sparcbuildd@vultus5:~$ ldd a.out 
<fabbione>         libc.so.6 => /lib/libc.so.6 (0x70030000)
<fabbione>         /lib/ld-linux.so.2 (0x70000000)
<fabbione> jbailey: yeps :)
<fabbione> it works..
<jbailey> And it's Modra that rocks.  Glad we don't have to invalidate the archive while we're at it, though.
<fabbione> and hello world comes out :)
<jbailey> Have a good sleep, Fabio. =)
<fabbione> yeah i am in the need of one
<fabbione> i think i am getting a big flu
<jbailey> fabbione: I'll confirm what to do with doko and try to get you a binutils update.
<jbailey> doko: ^^^
<fabbione> jbailey: that would be cool
<fabbione> at least to get main done for breezy will rock
<jbailey> lamont-away: ping?
<fabbione> i am running breezy atm on my buildd.. a suicide :)
<jbailey> It's a good workout.
<lamont> jbailey: 
<jbailey> Tests glibc and such nicely.
<jbailey> lamont: Hey.  Will you have time to test this binutils to see if it's enough love for HPPA as well?
<lamont> it was building when I left the house, checking on its status now
<fabbione> jbailey: btw.. i did also install an initramfs kernel on sparc...
<lamont> I wish expect worked correctly
<jbailey> Ah lovely. =)
<fabbione> i will let you know tomorrow if it boots
<jbailey> fabbione: Boots?
<lamont> jbailey: once this build finishes, I'll upgrade said chroot and try building openexr, since that was the simplest failure case before
<doko> jbailey: applying that for sparc and hppa conditionally? saves us the testsuite results for the other archs ...
<fabbione> jbailey: i don't think we did ever test initramfs on sparc...
<fabbione> jbailey: so this will be a test to do :)
<jbailey> doko: Right.
<lamont> jbailey: on the binutils upload, care to make it say build-depends: ... expect-tcl8.3 [hppa] , expect (>= 5.32.2-1) [!hppa]  ...
<jbailey> tcl8.4 sucking wind for you?
<jbailey> Actually, if this fixes your problem, we'll be disabling the testsuite for hppa anyway, so it doesn't much matter.
<lamont> jbailey: rather, the kernel's failure to deliver SIGCLD under some particular and unknown conditions, is.
<lamont> ah, true
<jbailey> And tcl8.3 solves this?
* jbailey bends the voodoo dolls into contortions.
<lamont> jbailey: uh, yes.
<lamont> and no, I don't know why.
<lamont> if I did. we could fix the kernel bug.
<lamont> which is affectionately (and incorrectly) known as "the expect bug"
<lamont> see the gcc-4.0 build-deps... doko was the one who figured out the hack (and created expect-tcl8.3)
<jbailey> We should have a race, who gets working Signals first, the Hurd or parisc-linux? =)
<lamont> jbailey: test build running now
* lamont grumbles at jbailey for having the same version number for his binutils test-package version
<jbailey> lamont: Sorry, I don't bump it until I'm ready to upload.  This one unconditionally applies it everywhere.
<lamont> right
<jbailey> It's really one of those "please only add me by hand in a chroot and you should have to think reasonably hard about doing this"
<lamont> otoh, making it -3ubuntu1.0 would be a clue...
<lamont> heh
* jbailey lkes "are you sure?" prompts that aren't easy to answer reflexively. =)
<lamont> jbailey: SCORE!!!!
<lamont> checking for strerror... yes
<lamont> checking for compress in -lz... yes
<lamont> checking for ios_base support in C++ standard library... yes
<jbailey> lamont: Izgood?
<lamont> sim
<jbailey> doko: Awake?
<jbailey> doko: It seems sparc and hppa both appreciate this binutils better than a swift kick in the teeth.
<jbailey> doko: So I'd like your final blessing to upload with this patch only applying for hppa and sparc, and with the testsuite disabled on those archs.
<doko> jbailey: sounds fine.
<doko> maybe after the release we should change the name from binutils-static to ld-static
<jbailey> I named it that in case it needed to grow more than just ld.
<doko> then let's watch how it grows in breezy+1 :-)
<lamont> so then.  jbailey: yes, I'm happy with the new binutils
<lamont> jbailey: how soon should I expect an upload?
<jbailey> I'm trying to decide if I want to pick a quote for the top of the changelog file...
<jbailey> Feh, my mind is blanking on how to do ifneq ($(DEB_HOST_ARCH),sparc) or ifneq ($(DEB_HOST_ARCH),hppa)
<jbailey> Do I have to nest them?
<jbailey> Solved a different way.
<jbailey> elmo: Around?
<lamont> ifeq ($(arch),$(findstring $(arch),hppa sparc))
<jbailey> lamont: What's the best way to bootstrap a breezy chroot these days for hppa from a running sid system?
<lamont> I _think_ you can just debootstrap it...  but no.
<lamont> libgcc2 isn't in main, so life sucks
<jbailey> Well, the ubuntu debootstrap scripts aren't in Debian, are they?
<lamont> debootstrap hoary from people.ubuntu.com/~lamont/ubuntu-hppa/tree and then dist-upgrade
<jbailey> libgcc2? =(
<jbailey> You have an abi event with libgcc?
<jbailey> s/have/had/
<lamont> well, doko did.
<lamont> http://people.ubuntu.com/~lamont/hoary.buildd
<lamont> debootstrap with that script
<jbailey> When this is done, can I just dist-upgrade off of archive.ubuntu.com?
<lamont> no.  ports.ubuntu.com
<lamont> deb ports.ubuntu.com/ubuntu-ports breezy main restricted ....
<lamont> deb-src archive.ubuntu.com/ubuntu breezy main restricted ....
<lamont> hppa-hacks/expect-tcl8.3-dev_5.43.0-2_hppa.deb
<lamont> hppa-hacks/expect-tcl8.3_5.43.0-2_hppa.deb
<lamont> hppa-hacks/expectk-tk8.3_5.43.0-2_hppa.deb
<lamont> hppa-hacks/gcc-3.4-hppa64_3.4.4-5ubuntu1_hppa.deb
<lamont> hppa-hacks/libgcc2_4.0.1-4ubuntu4_hppa.deb
<lamont> hppa-hacks/palo_1.9_hppa.deb
<lamont> that's what I have in a local repository which sources.list.main includes
<jbailey> Err..
<lamont> those are copies/symlinks to the universe packages
<jbailey> Okay, so if I add universe, will I be fine?
<lamont> right
<jbailey> Oh good. =)
<jbailey> Aside from the kernel not booting, is ia64 releasing with Breezy?
<lamont> note that if you have universe debs in sources.list, and you build a main package, you may get incorrectly-satisfied build-depends...
<lamont> ia64 is tracking breezy nicely
<jbailey> Right.  At this point I just want to make sure that the binutils package actually applies the patch on hppa correctly.
<lamont> except for that little kernel issue
<jbailey> The testsuite disabling I've tested.
<lamont> ok
<jbailey> Hmm.  debootstrap seems stuck on I: Checking component main on http://people.ubuntu.com/~lamont/ubuntu-hppa/tree...
<lamont> it should be happy...
<lamont> you told it hoary, yes
<lamont> ?
<jbailey> debootstrap --variant=buildd hoary hoary http://people.ubuntu.com/~lamont/ubuntu-hppa/tree
<jbailey> And I updated the hoary.buildd from the location you have.
<jbailey> s/have/game/
<jbailey> GAVE
<jbailey> DAMMIT
<jbailey> ROAR
<jbailey> don't mind me.
<lamont> lol
* lamont builds a tarball for jbailey
<jbailey> Oh, it's done something useful.
<jbailey> How nice of it.
<elmo> jbailey: ?
<jbailey> You don't have lvm2 or klibc-utils on hppa yet? =( 
<jbailey> hmm
<jbailey> elmo: I've added some stuff to make it possible to specify per-arch which ones should disable the testsuite, and also to make it honour DEB_BUILD_OPTIONS=nocheck
<jbailey> elmo: I'd like you to consider these for Debian as well.  Will you take a look at the Ubuntu packae that I upload, or do you need a patch in the BTS?
<elmo> jbailey: azeem made a patch for the latter already which is in the BTS
<elmo> I'm sort of disinclined to make it easy to disable the test suite per-arch, but I'll see what it looks like
<elmo> vorlon + drow approved binutils cvs for sid, btw
<jbailey> Well, I wrapped the testsuite stuff in ifeq ($(CHECK),), and at the top I set CHECK based on DEB_BUILD_OPTIONS
<jbailey> the sideeffect is that you can trivial define CHECK whenever you'd like for other reasons.
<jbailey> cool on the cvs binutils for sid.
<jbailey> It'll be nice to get this cleaned up everywhere.
<jbailey> lamont, elmo: While you're both hereish, any luck on hppa build logs?
#ubuntu-toolchain 2005-09-06
* jbailey listens to the crickets. =)
* lamont notes that rookery has no buildd.ubuntu.com entry in /etc/apache2/sites-enabled
<lamont> jbailey: wget http://people.ubuntu.com/~lamont/breezy.tar.gz (all 111MB of it...)  That's breezy,albeit with sources.list* that need to be edited.
<lamont> (hppa, buildd chroot)
<lamont> and way out of date, fwiw
<jbailey> Will it include whatever the lvm2 and klibc failures are?
<jbailey> It would be really nice to install ubuntu-minimal in this chroot. =)
<lamont> that's a chroot, not logfiles
<lamont> that chroot is (supposed to be) essential+build-essential
<jbailey> Ah. =)
<jbailey> woohoo, it looks like it included the patch for hppa and sparc correctly on the hppa build.
<lamont> does that mean it'll get uploaded shortly?
<jbailey> I'm just checking to make sure that the testsuite doesn't get run.
<jbailey> ISTR j5k being a bit speedier than this.
<jbailey> But that might have been ccache love. =(
<jbailey> lamont: Aside from that, it's all packaged up and waiting for me to sign/put it.
<lamont> heh
<lamont> avg build time is ~90 minutes
<jbailey> Thanks for the hint.  It won't tkae that long.
<jbailey> The testsuite is supposed to run midway through the build.
<jbailey> Although, I guess I should let it finish the whole way to make sure that it doesn't copy the testresults somewhere unconditionally.
<elmo> LARGE AND IN CHARGE.  BREEZY-AUTOTEST IS BACK.
<jbailey> Uh oh, James has been drinking and hacking again....
<jbailey> ;)
<fabbione> morning
<jbailey> Heya Fabio
<fabbione> hey jb
<jbailey> fabbione: Any last things before I go pass out?
<fabbione> jbailey: no.. i am still working to recover my box
<fabbione> good night dude :)
<fabbione> the damage is really really really weird
<jbailey> =(
<jbailey> Good luck with it.
<fabbione> thanks
<jbailey> tomorrow is glibc hacking day. =)
<fabbione> ehhe
<fabbione> time to fix the ipv6 resolver?
<jbailey> Probably not before preview freeze, but right after it, yeah.
<fabbione> ok
<jbailey> Or rather, during it, and I'll get you to test it.  Commit after preview freeze.
<fabbione> yeah that's an easy thing to test
<jbailey> I don't have a proper v6 setup here, so it's too hard for me to feel safe with it.
<fabbione> sure..
<fabbione> no problem at all
* lamont-away wonders who uploaded the debian binutils
<lamont-away> gnbd_monitor.c:575: warning: missing sentinel in function call
<lamont-away> wth is a sentinel in this context?
* jbailey does the 'summon doko' dance.
* lamont notes that libgcj6-dev is b0rked.
<lamont> (undeclared Depends: libglitz1-dev, although a rebuild should make the Dep go away)
#ubuntu-toolchain 2005-09-07
<lamont-away> doko: any words on "internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101"??
<jbailey> lamont-away: What arch, which gcc?
<infinity> lamont-away : Fixed in 4.1, apparently, no one's backported a patch.
<doko> lamont-away: reported upstream as PR21123
<infinity> Or is that "will be fixed in 4.1"?
<lamont-away> yeah - found the kde/debian page
<jbailey> doko	/query doko
<lamont-away> http://lists.debian.org/debian-devel-announce/2005/09/msg00000.html
<jbailey> Feh
<lamont-away> jbailey: what if he doesn't want to talk to himself???
<doko> jbailey: ?
<jbailey> lamont-away: I've never met a computer geek that didn't talk to himself. =)
<lamont-away> dude - that's the _COMPUTER_ we're talking to!!!
<lamont-away> well, if there's a computer around, that is.
<lamont-away> doko: btw, any plans for a gcc-4.0 upload soonish, before I upload my no-change upload for glitz?
<doko> lamont-away: I don't plan any 4.0 uploads for breezy at the moment
<lamont-away> ok
<lamont-away> I'll work through getting approval and upload it
<jbailey> doko: I was chatting with pinskia in #gcj yesterady.  It sounds like the 4.1 Java stuff contains a few nice bits
<doko> jbailey: yes, there are some improvements, although it still the same compiler, not the rewrite by tromey
<jbailey> Ah, too bad.
<jbailey> Getting the generics bits in there would've been nice.
<jbailey> He also mentioned that for the rest of the compiler at this point there's only 100 regressions vs. 4.0 right now.
<jbailey> Handy chatting with the bugmaster. =)
<doko> yes, on top to the 200 regressions in 4.0 from earlier versions :-)
<jbailey> Mmm, aren't those all versus 2.95?
<jbailey> Noone thinks that far back.  4.0 versus 3.3 is a bit of a dream. =)
<doko> hmm, I don't know the exact numbers, splitted up for different versions ...
<elmo> doko: ?
<doko> yep
<elmo> doko: -ECHAN, see #u-d
<lamont> gcc-4.0 uploaded to fix glitz crap
#ubuntu-toolchain 2005-09-08
<infinity> jbailey : (from the gcc-4.0/amd64 build log) lib32z1-dev: Depends: libc6-dev-i386 but it is not installable
<infinity> jbailey : This clearly seems Not Good.
<doko> infinity: fixed in zlib_1.2.3-3ubuntu4
<infinity> doko : Danke.
#ubuntu-toolchain 2005-09-09
<lamont-away> and hppa gets a second buildd.
<lamont> doko: gdc_py.c:30:20: error: Python.h: No such file or directory
<lamont> gdc_py.c:31:23: error: cStringIO.h: No such file or directory
<lamont> please fix python-gdchart_0.6.1-9ubuntu1
* lamont double checks to make sure that's really a breezy-autotest error
<lamont> yep.  iz ftbfs everywhere
<doko> $ apt-cache show python-gdchart
<doko> Package: python-gdchart
<doko> Priority: optional
<doko> Section: python
<doko> Installed-Size: 136
<doko> Maintainer: Jonas Smedegaard <dr@jones.dk>
<doko> Architecture: amd64
<doko> Version: 0.6.1-8ubuntu2
<lamont> 0.6.1-9ubuntu1 is the current source in the archive, and it's ftbfs
<lamont> and /me isn't sure what depends to drop on what...
<lamont> hrm.. actually, looks like adding python2.4-dev should fix it
<lamont> but I really need to sleep
<lamont> and actually, it probably doesn't meet criteria for upload until after preview-freeze lifts
#ubuntu-toolchain 2005-09-10
<lamont-away> dpkg-deb: building package `lib32gcc1' in `../lib32gcc1_4.0.1-4ubuntu1+ia32.libs.1.4ubuntu1_ia64.deb'.
<lamont-away> dpkg-deb: failed to open package info file `debian/lib32z1/DEBIAN/control' for reading: No such file or directory
<lamont-away> dh_builddeb: command returned error code 512
<lamont-away> you guys broke ia64!  shame on you
<lamont-away> hrm.. I wonder if I just requested biarch support on ia64.....
#ubuntu-toolchain 2005-09-11
<fabbione> morning
#ubuntu-toolchain 2006-09-09
<theCore> what is the first program in Ubuntu's toolchain?
<Keybuk> the general definition of a toolchain is there isn't a "first" program :p
<theCore> oh
<theCore> gcc, glibc, binutils?
<Keybuk> e.g. gcc is written in C, so needs gcc
<Keybuk> and uses make to be built, which is written in C, so needs gcc
<Keybuk> and both use glibc, which is written in C and uses make, so needs both
<theCore> I see
<theCore> I just building a quiz, for #ubuntu-trivia, I thought it could be a good question
<theCore> do you know any hard questions?
<Keybuk> what kind of questions are you thinking of?
<theCore> one-liners
<Keybuk> there's fun Ubuntu trivia
<Keybuk> "Which Ubuntu core developer originally wrote dpkg?"
<theCore> lol
<Keybuk> or more fun
<Keybuk> "How many Ubuntu core developers have been, or currently are, maintainers of dpkg or apt?"
<theCore> thanks, I save this one for the quiz
<Keybuk> I think of bad ones though :-/
<Keybuk> "In total, how many laptops have been stolen during Ubuntu conferences?"
<theCore> shoot :)
<Keybuk> it's probably about 10 so far
<theCore> that's nasty
<theCore> it will be the third quiz I do today, I'm losing inspiration...
<theCore> s/losing/short of/
<Keybuk> that's a lot of quizzes
<theCore> 25 questions each
<Keybuk> I've never even heard of #ubuntu-trivia :p
<Keybuk> I'm curious now,  what was the last quiz you did? :p
<theCore> an hour ago
<theCore> the log are at http://peadrop.com/trivia/
<Keybuk> <theCore> 20. Write a regex that parse phone-numbers.
<Keybuk> heh
<Keybuk> .+
<theCore> hehe
<Keybuk> <theCore> 21. What is the standard treading library for Linux?
<Keybuk> not pthreads
<Keybuk> (technically)
<theCore> bthread?
<Keybuk> Native Posive Threading Library would be the correct answer
<Keybuk> gah, POSIX :p
<theCore> ah
<Keybuk> previously it was LinuxThreads
<Keybuk> both happen to implement the pthread_* functions, of course
<theCore> I'm giving a quiz now
<theCore> 1. Complete the description: Upstart is an <??>-based replacement for <??>
<theCore> hehe
<Keybuk> alchohol ... life
<theCore> lol
<Keybuk> heh at Mark's FAQ
<Keybuk> he's actually ommitted the real reason that "breezy badger" is so named
<Keybuk> oh, no, he vaguely has
<Keybuk> "Our naming scheme is stupid, what's next?  Bendy Badger?!"
<Keybuk> "I LIKE IT!"
<Keybuk> mdz nearly killed me
<theCore> rofl!
<theCore> Keybuk:  just a random question: does Python has first-class functions?
<Keybuk> no idea
<Keybuk> I've never really understood what that means :p
<theCore> Which Ubuntu core developer originally wrote dpkg?
<theCore> who is it
<theCore> it isn't you Keybuk?
<theCore> Ian Jackson?
<Keybuk> no
<Keybuk> iwj
<Keybuk> yeah
<theCore> you maintained dpkg, isn't it?
<Keybuk> yes, as did Ben Collins
<theCore> did all Ubuntu core-dev maintained dpkg?
<Keybuk> no
#ubuntu-toolchain 2007-09-03
<arthur-> doko_: dpkg-deb: building package `gdc-4.1' in `../gdc-4.1_0.24-4.1.2-16exp1_kfreebsd-amd64.deb'.
<arthur-> doko_: should be ported on k*bsd*-gnu now =)
<arthur-> aloiret@asdfasdf:~/gdc-4.1/gdc-4.1-0.24-4.1.2/debian/gdc-4.1$ ./test 
<arthur-> Hello from kfreebsd-amd64!
<doko> lamont, lamont`: how dies java work on hppa
<doko> s/dies/does/ ;)
<doko> if it does, please build a gcc-snapshot for the archive
<arthur-> doko: can I give you tomorrow a patch for gdc/sparc so you test build + a sample D prog?
<arthur-> since I don't have access to the sparc anymore
<doko> arthur-: maybe not before the weekend
<arthur-> doko: ok
#ubuntu-toolchain 2007-09-06
<doko> lamont, lamont`: hppa gcj ping
<lamont> doko: yes?
<lamont> any happy news from the config.guess world?
<doko> lamont: can you build ecj/gjdoc now, and on which machines?
<lamont> interestingly, debian's hppa buildds are both A500s running 64-bit, and ubuntu's are both Jxxxx machines running 32-bit kernels...
<lamont> now as in when did you last upload something new?
<doko> lamont: currently I upload hppa binaries
<lamont> gjdoc 0.7.8-1 built successfully onhppa's buildd.  0.7.8-2 did not
<lamont> ecj hasn't built on debian's buildd since 3.2.2-2
<doko> lamont: could you just test build those and discard the resulting binaries? do the gutsy builds succeed?
<lamont> pretty sure I did that already... will do it again right now
<lamont> Exception in thread "main" java.lang.IncompatibleClassChangeError
<lamont>    at org.eclipse.jdt.internal.compiler.impl.CompilerOptions.getMap(CompilerOptions.java:418)
<lamont> there's ecj
<lamont> checking if uudecode can decode base 64 file... yes
<lamont> checking if gij-4.2 works... configure: error: The Java VM gij-4.2 failed (see config.log, check the CLASSPATH?)
<lamont> make: *** [config.status]  Error 1
<lamont> and gcj
<lamont> gjdoc-0.7.8/config.guess
<lamont> hppa2.0-unknown-linux-gnu
<lamont> I wonder if that's related...
<lamont> doko: you were going to check on when/who added the {2.0,1.1} to config.gues
<lamont> s
<doko> lamont: see my post to parisc-linux, it's unlikely to be changed, but I'll update gjdoc
<lamont> ok
* lamont goes afk for about an hour
#ubuntu-toolchain 2007-09-07
<lamont> doko: any clues on java/hppa stuff?
<doko> lamont: sorry, no. I didn't try further
<doko> as I say, works for me on the a500
<lamont> ok.  I'll see what I can do about reproducing the failure on my A500 then
<lamont> doko: maybe at some point I'll want to steal a tarball of the toolchain on your machine.
<doko> lamont: sure, /scratch/packages/gcc/
<lamont> thanks
<lamont> it'll take me a while before I get to it.. hopefully this weekend - no guarantee though
<aquo> hi
<aquo> anybody awake?
<arthur-> aquo: yes
<aquo> I installed ubuntu-minimal with debootstrap and examined the installed packages with aptitude
<aquo> libgcc1 has version 4.2.1
<aquo> and libstdc++6 has version 4.2.1 too ...
<aquo> if i would install gcc it would have version 4.1
<aquo> gcc depends on gcc-4.1 ...
<aquo> build-essentials depends on gcc ...
<aquo> which is the official compiler for gutsy? gcc-4.1 or gcc-4.2?
<arthur-> aquo: aptitude install gcc; gcc --version should give you an answer
<arthur-> aquo: gcc package come from gcc-defaults source package, which provide a symlink on /usr/bin/gcc to the current default gcc version
<aquo> arthur-: ok, gcc depends on gcc-4.1, but all the libs are 4.2. why?
<aquo> shouldn't have the compiler the same version as the libgcc and libstdc++?
<arthur-> aptitude show libstdc++6
<arthur-> Version: 4.2.1-4
<arthur-> aquo: is g++-4.1 installed?
<aquo> i just installed ubuntu-minimal, nothing else.
<arthur-> aquo: this is libstdc++6-4.2-dev for gcc-4.2 and libstdc++6-4.1-dev for gcc-4.1
<aquo> i am just analysing dependencies for some gutsy-based custum installation
<aquo> ok, again ...
<aquo> if i install ubuntu-minimal i get libstdc++6-4.2 and libgcc1 for 4.2 ...
<aquo> but if i would install build-essentials i would get an gcc with version 4.2, not with version 4.2?
<aquo> why?
<aquo> but if i would install build-essentials i would get an gcc with version 4.1, not with version 4.2?
<aquo> sorry for the error
<arthur-> because gcc-4.2 is not the default in gutsy
<aquo> ok, but why doesnt libstdc++6 doesn't match the default compiler?
<aquo> if i install ubuntu-minimal and build-essentials i get a system wit libstdc++6-4.2 and libstdc++6-4.1-dev
<aquo> so headers and library doesn't match
<aquo> same with libgcc
<arthur-> aquo: maybe libstdc++6-4.2 is a dep providd by dh_shlibdeps, which mean that libstdc++6-4.2-dev was installed in buildd
<arthur-> I don't know
<arthur-> provided*
<arthur-> so c++ packages depends on libstdc++6-4.2
<arthur-> doko: can you please commit gdc-svn-updates?
<doko> done
<arthur-> thanks
#ubuntu-toolchain 2007-09-08
<Mithrandir> aquo: does it matter?  The 4.1 and 4.2 packages are binary compatible.
<Mithrandir> also, they answer to the question about what the default gcc is "varies by architecture"
