#ubuntu-toolchain 2006-03-13
* lamont grumbles at gcj-4.0.  or maybe it's launchpad...
<doko> lamont: will be demoted to universe, if that helps
<jbailey> Demoting lamont?  Say it's not so!
<lamont> jbailey: sigh
<doko> "if that helps" =)
<jbailey> doko: It would mean less work for him to do. =)
<lamont> doko: it's more that once gcj-4.0 builds on i386, then libgcj6 becomes uninstallable on any architecture that's not done building it yet
<lamont> at least, every time you bump the versioned depend on libgcj-common
<doko> jbailey: just send you email about glibc on powerpc
<lamont> that's actually more of an archive issue than a doko issue, but it's more fun to blame doko
<doko> lamont: good hint, will fix that
<jbailey> doko: Cool, thanks.
<lamont> doko: the issue is that libgcj-common is arch: all
<doko> lamont: can you get some hppa guys to fix the java thing?
<jbailey> doko: Just on the phone with a customer.  I haven't looked at your email yet, sorry. =(
<lamont> and the archive stuff drops earlier versions of it, even though arch: foo still needs it, since there's a newer package of that name.
<lamont> doko: I think someone is working on it, but dunno with what speed.
<lamont> what exactly is the failure?
<lamont> or issue
<doko> http://lists.parisc-linux.org/pipermail/parisc-linux/2006-February/028428.html
<doko> http://lists.parisc-linux.org/pipermail/parisc-linux/2006-February/028439.html
<doko> http://lists.parisc-linux.org/pipermail/parisc-linux/2006-March/028470.html
<lamont> -Wl,-soname -Wl,liba1.so.0 
* lamont giggles
<lamont> it had email yesterday, so that's a good sign
<jbailey> doko: So it *doesn't* do it on Ubuntu now?
<doko> no, don't ask me why ... I did repeat both test-suites on the same machine (Power5)
<doko> lamont: what exactly is the problem with libgcj-common? there is no versioned dependency on it
<jbailey> doko: It can still be discrepancies between the glibc on Debian and the one in Ubuntu.
<jbailey> They're using gcc-4 in Debian, they have some extra patches and such.
<jbailey> Because of the Dapper lifecycle, I've tried to be *really* conservative.
<jbailey> The excitement starts for us the day after Dapper releases.
<jbailey> MWAHAHAHAHAHA
<doko> yes, seems to be a good decision ...
<jbailey> Well, ideally a week before so that all new things in 6.10 get build with gcc-4.1, glibc-2.4.
<jbailey> I argued with drow a bit about this, I didn't think it was a good decision for Debian either.
<lamont> gcj-4.0-base Depends: libgcj-common (>= 4.0.2-8) bu t4.2.0-7ubuntu3 is to be installed
<lamont> or something like that
* lamont bootstraps gcj-4.0 again, to make life easier for infinity once the hppa buildd is existant
<doko> lamont: that's an unversioned dependency now, but honestly I didn't expect hppa that far behind ...
<lamont> doko: hppa has been offline (and remains so) ever since the switch to soyuz.  I'm hoping that we get buildd's online in the DC sometime in the next week or so.
<doko> fabione, infinity: cmov is everywhere, even in hoary in sarge, looking further ...
<infinity> doko: <blink>.. You'd think we would have had complaints before now if it was actually causing a problem...
<doko> infinity: we do have the kernel emulation for it turned on?
<infinity> I have no idea if there even is kernel emulation for it.
<infinity> But Sarge users (many of whom are custom-kernel-compiling types) would be screaming if Sarge didn't work on the old C3..
<infinity> So maybe we're not seeing what we think we're seeing here.
#ubuntu-toolchain 2006-03-14
<lamont> Setting up gij-4.1 (4.1.0-0ubuntu1) ...
<lamont> gcj-dbtool-4.1: error while loading shared libraries: libgcc_s.so.4: cannot open shared object file: No such file or directory
<lamont> dpkg: error processing gij-4.1 (--configure):
<lamont>  subprocess post-installation script returned error exit status 127
* lamont grumbles at doko
<infinity> Maybe gcj-4.1_4.1.0-1ubuntu2 would treat you better?
<lamont> yeah, probably
<lamont> I was trying to avoid that 8 hour build, though...
<lamont> that was from gettext_0.14.5-2ubuntu3's log, fwiw
<lamont> anyway, bed for me.
<jbailey> doko: Is g[ic] j-4.1 the released version?
<doko> yes
<jbailey> Cool, thanks.
#ubuntu-toolchain 2006-03-15
<lamont> checking for gettimeofday... no
<lamont> checking for time... no
<lamont> checking for ftime... no
<lamont> configure: error: no function found to get the time
* lamont grumbles at gcj-4.1
<lamont> dear doko: please fix python2.4's os.getlogin() to not raise an execption [breezy] .  kthxbye
<lamont> python -c 'import os; print os.getlogin()'
<lamont> Traceback (most recent call last):
<lamont>   File "<string>", line 1, in ?
<lamont> OSError: [Errno 2]  No such file or directory
<lamont> and the cool part is watching it stat through a path looking for <string>
<lamont> (with strace)
<lamont> interestingly, seems to be fixed in dapper already
#ubuntu-toolchain 2006-03-18
<doko> jbailey: ask michael meeks on the patches (irc  michael_)
#ubuntu-toolchain 2006-03-19
<mjg59> doko: Our elilo problems are binutils-related
<mjg59> Any ideas what might have broken efi-ia32 building?
<doko> mjg59: no, is the source package in the archive?
<mjg59> Yes
<mjg59> I haven't traced whether it's gnu-efi that ends up broken (and hence all efi apps are), or if it's ok and elilo is broken
<doko> hmm, how could I test if it's broken or not?
<mjg59> doko: Good question. 
<mjg59> Unfortunately the answer is probably "Run the binaries", but...
<mjg59> In theory it's possible to run an EFI environment under qemu or something, but I've never done it
<doko> me neither :-/
<doko> is it supposed to work with vmware?
<mjg59> I'd assume so
<mjg59> But I don't know where to get hold of the test environment
<mjg59> doko: Ok, the breakage appears to purely be in elilo
<mjg59> I can build gnu-efi with the new binutils, and elilo still works as long as I build it with the old binutils
<doko> mjg59: ok, so I assume we have to do a binary search with different binutils.
<mjg59> doko: The obvious difference (looking at the headers) is that the .dynsym and .reloc sections are in the reverse order
<mjg59> The only difference in the disassembly is that some of the addresses are slightly different
<mjg59> In the broken one, they're all 4 bytes later
<mjg59> So my suspicion is in the section ordering...
<mjg59> Or the fact that the .dynsym section is slightly larger in the working one
<doko> mjg59: I'm looking at it today
<mjg59> doko: Ok, thanks
<mjg59> doko: Would you like a copy of a working and a broken binary?
<doko> mjg59: sure, might help. most likely I'll have to ask you anyway ...
<mjg59> doko: www.codon.org.uk/~mjg59/tmp/efi
<doko> got it
<mjg59> Ok, if I edit the linker script to force the section ordering to be the same, it still fails
<mjg59> The only obvious difference now is that the .dynsym section is smaller
<mjg59> (In the broken one)
<doko> mjg59: could you check http://people.ubuntu.com/~doko/binutils_2.16.1cvs20060314-0ubuntu1_i386.deb (current upstream)
<mjg59> doko: Will do once I get home (30 minutes or so)
<mjg59> doko: Still broken
<doko> mjg59: hmm, ok, going backward then tomorrow
<mjg59> doko: Are the earlier cvs packages available anywhere?
#ubuntu-toolchain 2008-03-14
<user8877> hi all
<user8877> who speak russian ?
<soren> Russians.
<\sh> lol
#ubuntu-toolchain 2009-03-12
<rbansal> Hi Guys, I need a MIPS32 toolchain with NPTL support, so can anyone help me in this regard?
