#ubuntu-toolchain 2006-01-02
* #ubuntu-toolchain  [freenode-info]  If you're at a conference, please contact freenode staff to make sure we've made special allowance for many users coming into our network from a single internet address ( http://freenode.net/faq.shtml#gettinghelp ). Private messages from unregistered users are currently blocked, except to network staff, services and participating registered users ( http://freenode.net/faq.shtml#privmsg )... Thanks!
<doko> hi fabbione
<fabbione> hi doko
<fabbione> COW
<fabbione> did you upload something?
<doko> yes, remains of C++ stuff
<tonyms> I'm building the binutils package from the package source on Breezy, and notice binutils-2.16.1 has a gcc build-dep.  Could this build-dep not be on c-compiler instead?  I already had gcc-3.4 installed; would that not have been sufficient?
<tonyms> Thanks!  Sorry if this question is overly clueless or in the wrong channel, I'm new to Ubuntu...
<jbailey> tonyms: Usually iif there's a specific build-dep it's done for a reason.
<jbailey> tonyms: Often miscompile problems.
<tonyms> jbailey: depending on gcc (>= 2.95.2) isn't very specific, though.  libtool, say, build-deps on gcc | c-compiler.  Is there any reason this doesn't apply to binutils?  It's annoying to have to install gcc-4.0 when a perfectly viable C compiler already exists on the system.
<jbailey> tonyms: libtool is actually buggy there.  IIRC, it's against policy to depend on thing covered by build-essential if there's no versioned dependancy
<jbailey> In this case, gcc-2.95's dependancy could probably be dropped.
<jbailey> I don't see anything in there that forces gcc-4.0
<jbailey> Aside from regular build-essential fun
<tonyms> Cheers!  Not sure I like the idea of build-essential, though :)  It always uses the system compiler (gcc), which means programs whose codebase hasn't been upgraded so gcc-4.0 can handle it are hosed on my machine.
<jbailey> Anything that hasn't been debugged for gcc-4.0 is pretty much trash material anyway.
<jbailey> At this point, everything in Debian is already done, and all of the actual compliance bugs are pretty much gone from gcc-4.0
<jbailey> The last gcc-3 update has now been released.  Anything before 4.0 is pretty much considered dead.
<doko> jbailey: there will be a last 3.4.6 in February (famous last words ...)
<jbailey> doko: Eh?  I thought he said 3.4.5 was the last.  *sigh*
<jbailey> What's the point of it?  gcc-4.0 isn't that far away from being oldstable.
<tonyms> jbailey: that's all very well, but the C compiler isn't used just to compile Debian.  I would have a hard time convincing management that the system we sell our paying customers is "trash material" :)
<jbailey> tonyms: *lol* possible.  But you might point out that it's probably poorly coded and perhaps some developer education time is needed.
<jbailey> tonyms: Minus the occasional compiler bug, the gcc-4.0 transition is pretty much just moving to code that is actually standards compliant.
<jbailey> We used to host weekly workshops at one company I worked for.  Covered things like this.  It worked out really nicely.
<tonyms> jbailey: we're on our way; we already have migration guides, FAQs and the like, but the transition isn't over yet, so we have to support it for the time being, unfortunately.  Still, I'm learning a fair amount about cross-compiling with GCC :)
<doko> jbailey: yes, I think we should get it into dapper, although it will miss feature freeze a bit
<jbailey> doko: Given that it's not the system compiler, I don't see a problem with that.
<doko> jbailey: yes, I'd like to have the ok from the glibc maintainer ;)
<jbailey> I'd love to do a round of builds with it , but gab's been good with the updats.
#ubuntu-toolchain 2006-01-08
<jbailey> glibc-2.3.6-0ubuntu1 being uploaded now.
<doko> nice
<jbailey> -0ubuntu2 can be the amd64/i386 biarch.
<jbailey> Then -0ubuntu3 can merge in the rest of Debian's patches.
#ubuntu-toolchain 2007-01-03
<lamont> doko: not that you care, but gcc-3.3 is ftbfs on hppa (sid)
<doko>   * Don't build the gcc-3.3-hppa64 package on hppa.
<doko> don't be impatient ;P
<lamont> heh
<lamont> I thought we got rid of that package in sid...
<jbailey> lamont: Don't the Debian police come after your soul for reporting bugs in an Ubuntu channel? =)
<lamont> jbailey: I wasn't reporting a bug
<doko> jbailey: fix glibc so that he can report it here =)
<lamont> I was acknowledging that neither of us care. :-)
<lamont> or is apathy not allowed either?
<jbailey> lamont: It's not, but the people who'd enforce such a rule are also so aflicted ;)
<lamont> ISTR I've reported ubuntu bugs in debian-devel... :-)
<lamont> lol
<doko> how did you survive?
<lamont> doko: I'm me.  non-survival is not an option.
<jbailey> doko: LaMont is light one of those pretty underwater fish.  Looks harmless until you realise that he's covered in neurotoxins.
<jbailey> lamont: Thinking of hppa, since I'm now officially a comaintainer of the glibc port upstream, I may have harder questions for your now about PA =)
* lamont wonders what kind of fish there are, besides "underwater fish"
<lamont> jbailey: woot!  (and on topic, too...)
<jbailey> lamont: Since I can't use Carlos as an excuse for not hacking anymore. =)
<lamont> oh?
<lamont> he's back?
<jbailey> lamont: The classification of fish depends on how you think of it.
<lamont> but in any case, it smells, eh?
<jbailey> Much to my biology prof's dismay, I classified pretty much anything underwater as fish.  Anything on land as either mamal or reptile (where reptiles were things I didn't like) and anything in the air as bird.
<jbailey> All these assume self-propulsion of some sort.
<jbailey> So airplanes and satellites are birds.
<jbailey> ex girlfriends are reptiles.
<jbailey> So are spiders.
<jbailey> Dolphins, whales, and my wife while in the bathtub are all fish.
<lamont> "jbailey - revolutionizing taxonomy"
<jbailey> "The facts, while interesting, are irrelevant."
<lamont> what about red elephants?
<jbailey> Like zebras.
<jbailey> Y'see: Zebras are not white with black stripes.  Nor are they black with white stripes.
<jbailey> If you peel off the stripes, you get a red - and *very* angry - zebra.
<jbailey> lamont: But no, Carlos isn't back aside from the occasional bursts of email.
<jbailey> lamont: More that if he likes the way a patch looks, he'll tell me to just commit it now.
<lamont> ah, woot
<jbailey> lamont: And theoretically as a co-maintainer if I *really* believe the patch is correct, I could just commit it.
<lamont> right
<jbailey> Although for anything other than build fixes, I expect I won't do that soon.
<lamont> ah, so that's the source of the change of status
* lamont needs to run into town to see a notary public for a few seconds
<lamont> and not just because fabbione just showed up
<fabbione> hi lamont :)
<lamont> hi fabbione 
<fabbione> sup?
<jbailey> lamont: Right.  I poked him about it as I've got some trivial unreviewed build patches from August.
<jbailey> So when little header file fixes aren't getting reviewed, it's hard to dig up incentive to do a harder hack.
<jbailey> But, resolved now. So whee.
<lamont> woot.  bbiah
#ubuntu-toolchain 2007-01-04
* Starting logfile irclogs/ubuntu-toolchain.log
<doko> jbailey, fabbione: I reverted binutils back to a FSF snapshot; it's the same as the hjl release (we didn't apply the patches in this release anyway)
<jbailey> doko: Ah, has he finally got the Intel stuff merged upstream now?
<doko> jbailey: seems so. there's still a patches subdirectory where we should maybe pick up some patches
#ubuntu-toolchain 2007-01-05
<fabbione> configure: error:
<fabbione> *** These critical programs are missing or too old: as ld
<fabbione> *** Check the INSTALL file for required versions.
<fabbione> make: *** [/build/buildd/glibc-2.5/stamp-dir/configure_libc]  Error 1
<fabbione> doko: what have you done? :)
<fabbione> checking for as... as
<fabbione> checking version of as... v. ?.??, bad
<fabbione> checking for ld... ld
<fabbione> checking version of ld... v. ?.??, bad
<fabbione> doko: the version in ld/as did change from X.Y.Z to XYZ
<fabbione> is that change permanent?
<fabbione> or just a build error our side?
<doko> fabbione: it's an unmodified snapshot build. apparently the glibc version detection goes wrong
<fabbione> doko: glibc expects a release.. not a cvs snapshot
<fabbione> doko: do you want to fix the binutils version or should i get crazy to fix the glibc detection?
<doko> yes, seeing that now. wondering how this did work with previous snapshots ... I'll fake a version 2.17.50.something
<fabbione> ok
<fabbione> # Accept binutils 2.13 or newer.
<fabbione> AC_CHECK_PROG_VER(AS, $AS, --version,
<fabbione>                   [GNU assembler.* \([0-9] *\.[0-9.] *\)] ,
<fabbione>                   [2.1[3-9] *] , AS=: critic_missing="$critic_missing as")
<fabbione> AC_CHECK_PROG_VER(LD, $LD, --version,
<fabbione>                   [GNU ld.* \([0-9] [0-9] *\.[0-9.] *\)] ,
<fabbione>                   [2.1[3-9] *] , LD=: critic_missing="$critic_missing ld")
<fabbione> doko: that's the reason why i think we should fake the version in binutils
<fabbione> parsing cvs snapshots date will make that check way too compilcated
<doko> the strange thing is that the cvs checkout has 2.17.50, while the tarball produced by upstream has the date ...
<doko> $ ld --version
<doko> GNU ld version 2.17.50 20070103 Debian GNU/Linux
<doko> $ as --version
<doko> GNU assembler 2.17.50 20070103 Debian GNU/Linux
<doko> ok, now changing that to Ubuntu ...
<fabbione> don't change Debian to ubuntu
<fabbione> IIRC we did carry Debian all over and pkgs might rely on that
<doko> the autotools tests rely only on the two first numbers, everything else is a string
<fabbione> yeps
#ubuntu-toolchain 2008-01-03
<ChrisAshton84> not sure if this is the right channel, but I need to find 32 bit tcl libs for x86_64 ubuntu - do you guys know where I could get this?
<Mithrandir> I don't believe we ship those, but you could use a chroot
<ChrisAshton84> Mithrandir: thanks for the suggestion but that's a bit of overkill :-P I managed to install the i386 version using a tool on the x86_64 forum but it installs a broken link :-/
<ChrisAshton84> got it. getlibs available on the forums could be a great save for any x86_64 user w/ unsupported programs to run
