#ubuntu-toolchain 2005-08-22
<fabbione> morning
<Keybuk> 'sup?
<doko> yep
<doko> jbailey: how can we get the search path for the linker for 64bit binaries on a 32bit system?
<jbailey> So a system where you can't actually run the linker?
<doko> we don't have one, when building gcc and libraries biarch
<jbailey> There's no guaranteed way right now.
<jbailey> Probably the best bet would be do so something with bfs.
<jbailey> bfd
<Keybuk> can't you just ship ldd in the bi-arch libc6-dev packages
<jbailey> Keybuk: ldd just called ld.so with some parameters.
<Keybuk> right
<jbailey> calls, even.
<Keybuk> so make that work ;)
<jbailey> If you can't run a binary of the target architecture, there no option there.
<jbailey> If you could, ldd has already been hacked to select the right ld.so. =)
<Keybuk> I don't understand why these library packages are being produced if they can't work?>
<Keybuk> so far this bug reads like "we're doing some shit that can't possibly work AND IT'S YOUR FAULT!"
<jbailey> They can work, you just need a capable kernel.
<jbailey> So install the right one. =)
<jbailey> The problem with using objdump and such is that there's no way to know what glibc considers to be the linker path.
<jbailey> linker search path, rather.
<Keybuk> then why is this a problem?  surely the machines which will be building these bi-arch packages will have "the right kernel" on them?
<jbailey> And it'll change over time as we do multiarch.
<jbailey> Keybuk: Probably 'cause people want to build them at home or such.
<Keybuk> I really don't see how this is a dpkg-dev bug; if the base system can't support building these packages, then they shouldn't be being built
<jbailey> The base system builds the package fine.
<jbailey> It's just a cross compiler at that point.
<Keybuk> there's more to building a package than just compiling, as you know well
* lamont wonders if doko uploaded a new gcc-4.0 to breezy
<doko> they do work, if you do have the right kernel
<jbailey> doko: Right, but you can build the stuff either way.  You just can't run testsuites or ldd on it.
<jbailey> Or use built-sources in any way.
<Keybuk> but the point is that if these source packages need "the right kernel" to build, they should ensure they do before they try
<Keybuk> and right now, they're not
<doko> elmo would be "happy", if we do that for powerpc and i386 ...
<jbailey> Keybuk: Right.
<jbailey> The joys of the multiarch setup.
<jbailey> I don't even know how possible it would be to bend glibc into doing a cross-ldd.
<doko> jbailey: what about the libc6-dev-amd64 headers for libc6-dev on i386? Can you estimate, if that's doable?
<lamont> Keybuk: I assume there isn't a nice dpkg command that says 'extract all the .so's from this deb and feed them as arguments to $COMMAND' :-(
<jbailey> doko: Yeah.  Just need to add that include SEARCHDIR hook, I guess.
<Keybuk> lamont: no
<Keybuk> it'd be easy to do
<lamont> doko: I'm trying to figure out if gcc-3.4 has the issue as well, or if it was just because I inherited some gcc-4.0-built .so's when I was testing...
<doko> jbailey: SEARCHDIR hook?
<lamont> Keybuk: yeah
<jbailey> As in, I'd have to install the headers in some other location, and gcc would have to be told to search there first.
<jbailey> If it didn't find the header, try the main ones.
<lamont> jbailey: is there a glibc upload coming anytime soon?
<doko> jbailey: it already does, but for C++ headers only
<jbailey> lamont: doko asked for one yesterday to help sparc along.  Got something for me?
<doko> jbailey: hmm, hppa needs one as well, but with a fixed gcc-4.0, or don't you build hppa with gcc-4.0?
<lamont> ISTR hppa got built with gcc-3.4....
<lamont> jbailey: or is glibc now building with the default gcc?
<Keybuk> dpkg-deb --fsys-tarfile /path/to/deb | tar xv -C /where/to/extract "*.so" | xargs $COMMAND
<Keybuk> lamont: ^ :p
<lamont> jbailey: actually, I just need to do a fresh and clean build of it, and I see that -1ubuntu8 hasn't been uploaded for hppa, so all is good on that front
<doko> jbailey: in which directory should gcc search the x86_64 headers?
<lamont> Keybuk: heh.  I'd have figured that out... :-)  But I guess I'll still buy you a beer sometime
<jbailey> lamont: No, everything is building with 3.4 still
<jbailey> doko: Mmm.  I think Tollef's proposal was /usr/include/GNU-TRIPLE wasn't it?
<jbailey> So /usr/include/x86-64_linux ?
<doko> jbailey: look at biarch-include-ix86.dpatch and add something. but I'm unsure, if fixincludes is aware of that
<jbailey> I thought fixincludes was a noop on Linux these days.
<jbailey> The system headers sould already be gcc safe.
<doko> jbailey: that directory is already searched for.
<Keybuk> jbailey: /usr/include/x86_64-linux-gnu
<jbailey> Keybuk: Yes, dear.
<doko> 4.0 only ...
<jbailey> Ah, that's probably why I didn't notice it, lemme check it.
* jbailey turns on the amd64 box.
<jbailey> doko: Is this a new thing?
<jbailey> Oh. duh, pass -m64 to cpp, Jeff
<doko> gcc-4.0 (4.0.1-1) unstable; urgency=high
<doko>  * Disable multiarch-includes; redo biarch-includes to include the paths
<doko>     for the non-default biarch, when called with -m32/-m64.
<lamont> Keybuk: it got bigger. :-)
<lamont> zcat /org3/ubuntu/dists/breezy/*/binary-hppa/Packages.gz | awk '/^Filename: / {print $2}' | while read i ; do mkdir -p unpack; dpkg --fsys-tarfile /org3/ubuntu/$i | tar xv -C unpack "*.so.*" 2>/dev/null | (cd unpack; while read f; do x=$(objdump -T $f | grep _GLOBAL_); [ -n "$x" ]  && echo ${i##*/} $f $x;done); rm -rf unpack; done > bogus 2>&1&
<Keybuk> zcat|awk can be replaced by grep-dctrl
<lamont> true.
<lamont> but then I'd have to remember grep-dctrl. :-)
<Keybuk> that reminds me
<Keybuk> I need to figure out why #13306/#322595 talks about dpkg-deb
<lamont> grep-dctrl -s Filename -n . /org3/ubuntu/dists/breezy/*/binary-hppa/Packages.gz
<lamont> sadly, the version of grep-dctrl on the best machine for the job doesn't read .gz files very well..
<Keybuk> gah, found _another_ dpkg disappear/replaces bug *sigh*
<doko> jbailey: why don't you want to install the x86_64 headers in libc-dev, as done by amd64-libs-dev?
<jbailey> Where did amd64-libs-dev install them?  I thought that they hadn't installed them for some reason.
* jbailey checks the hoary setup again.
<jbailey> Right, I had tried installing them in /usr/include/x86_64-linux and it hadn't worked.
<jbailey> But I see that that's not the search path now.
<jbailey> So I'll do that.  Easy enough.
<lamont> doko: could you look at that hppa patch and see if it's sensible in 3.4 as well?
<lamont> doko: which version of gcc-defaults switched hppa back to 4.0?
<lamont> (not clear from the changelog if it was 27 or 28)
<lamont> 27
* lamont has debs which definitely predate the switch from 3.4->4.0 for hppa, which have the _GOT_ bug
<jbailey> lamont: Do you need other fixes in glibc for the next upload?
<lamont> jbailey: not that I know of
<lamont> +glibc (2.3.5-1ubuntu7hppa1) breezy; urgency=low
<lamont> +
<lamont> +  * drop glibc234-hppa-remove-mallocdef
<lamont> that's all I have locally, and that was in -1ubuntu8, so all should be happy.
<lamont> doko/jbailey: so correct me if I'm wrong, but no .so files should have _GLOBAL_OFFSET_TABLE_ in the dynamic syms, right?
<jbailey> lamont: I'd have to check the ELF spec to be really sure, but I don't remember ever seeing it.
<lamont> well, it's only fatal when two of them have it. :-)
<jbailey> Right. =)
<jbailey> "The symbol _GLOBAL_OFFSET_TABLE_ may reside in the middle of the .got section, allowing both negative and non-negative subscripts into the array of addresses."
<jbailey> But it's extern.
<jbailey> (by spec)
<jbailey> So I'm guessing based on that, that no, it should be provided by one of the startup bits from glibc, or generated by gcc.
<jbailey> Anything can reference it, though, it should just not be provided by them.
<lamont> right.  thanks.
* lamont will update his sanity checkers to bomb any such .debs then.
<jbailey> lamont: I still haven't gotten access to j5k again, but doko gave me access to his hppa box.
<jbailey> lamont: If you have a testcase that produces it, I'd be interested in looking at it to see at least which piece is doing the bad generation.
<lamont> interestingly, we just have local absolute symbols that have that value, it appears.
<lamont> IOW, it may just be that I took the debian issue and extrapolated it onto ubuntu
<lamont> but since we've switched to 4.0 on hppa/breezy, I'll build that, glibc, rebuild gcc-4.0, and upload the latter 2, and then just see how it goes before I start nuking things....] 
<jbailey> 'k
<jbailey> Or I wonder if it's something historical from the 2.3.2 glibc that only showed up in that archive.
<jbailey> But since breezy is built with 2.3.5 in its entirety.
<lamont> I think it was actually something that showed up with 2.3.5-built-by-gcc-4.0
<lamont> which is to say, I may be doing overkill in bootstrapping gcc :-)
<jbailey> Erm.
<jbailey> Don't do that. =)
<jbailey> Actually, no.
<jbailey> You can't have done that without serious patching.
<jbailey> It just won't build at this point.
<lamont> jbailey: right.
<lamont> our glibc is build with 3.4, and is FTBFS with 4.0, correct?
<jbailey> Right.
<lamont> in which case, I should be able to just build the new glibc (with 3.4), and then use that in the build of the new gcc-4.0, and all is well
<lamont> ./usr/lib/libapt-pkg-libc6.3-6.so.3.10 00116b7c g DO *ABS* 00000000 Base _GLOBAL_OFFSET_TABLE_
<lamont> plenty of entries like that
<lamont> but they're all local, not exported
<jbailey> I will do the gcc-4 hackery for 6.04
<lamont> $no_build_regex = ".";
<lamont> that just makes me feel dirty.
<jbailey> Should that not be .* ?
<lamont> if the regex exists in the string, it's a match
<jbailey> Ah. 'k.
<lamont> so the only thing that '.' doesn't match is an empty line
<lamont> that's on the hppa/breezy buildd
<lamont> jbailey: not sure what debian did for their 2.3.5 glibc...
<jbailey> What do you mean?
<lamont> well, they felt that they had to binNMU glibc after fixing gcc-4.0...
<lamont> so it would seem that they did a 2.3.5 build with gcc-4.0, no?
<jbailey> Err..  They shouldn't have, unless gotom's been playing with some of the gcc-4 patches.
<jbailey> I told them I didn't think it was a good idea and got into an argument with drow and gotom, though.
* lamont just shrugs
<jbailey> Ayup
<jbailey> I also don't know for certain that we're using the same hppa patches between Debian and Ubuntu.
<lamont> the last time glibc was built by the buildd was 2.3.2.ds1-22
<jbailey> I did the backport for Ubuntu, and I think gotom did his own.
<lamont> which is to say, we have no build logs
<jbailey> Even better!
<jbailey> =)
* lamont goes to see if he's critical path on buildd.ubuntu.com or not
<jbailey> lamont: I was good!  I didn't even ask!
<lamont> jbailey: heh
<lamont> hrm... is there any reason to use ccache in the gcc-* builds, or do they just use the internal version of themselves for everything and we're just polluting the cache?
<jbailey> lamont: The stage1 compiler gets built with the ccache.
<jbailey> lamont: After that, I'd be surprised if you ever poluted the cache.  It calls itself explicitely by pathna,e
<lamont> ah, true
#ubuntu-toolchain 2005-08-23
<elmo> lamont/infinity: still missing powerpc daily d-i
* lamont grumbles
<lamont> will check shortly
<doko> jbailey: do you have any outstanding changes for gcc-4.0 ?
<jbailey> doko: I don't think so.
<jbailey> doko: I'm just looking at the glibc packaging for putting the include files in the right place.
<jbailey> I don't think it affects youin any way, though.
<doko> ok, just have to make an update due to the libcairo upload
<jbailey> Actually.
<jbailey> Hmm
<jbailey> Oh cool, /usr/include/GNU-TRIPLE works on ppc too
<jbailey> Nice. =)
<jbailey> I should undo my linux-kernel-header wrappers and just drop those in their various directories.
<doko> yes, I have to backport that to 3.4
<jbailey> Have you thought of the default gcc for 6.04, btw?
<doko> ENOTIME
<doko> it's difficult, assume that it's released in Sep/Oct, then we won't have a .1 release for 6.04
* jbailey nods.
<jbailey> I was more thinking about all the Java work that's gone into 4.1
<doko> even now, we have five or six wrong-codegen fixes not in the gcc, which are already in cvs
<fabbione> doko: speaking of which.. the gcc ice on sparc?
<fabbione> for mysql-*?
<fabbione> i did send you all the info a looong time ago...
<doko> fabbione: use -O2
<fabbione> doko: so i need to do a port upload..
<fabbione> of a package because gcc is broken?
* fabbione larts doko with a large CFLAGS
<doko> http://gcc.gnu.org/PR23454
<doko> fabbione: or use gcc-3.4
<jbailey> fabbione: You're not doing kernel anymore, right?  That should leave you lots of time for gcc hacking. =)
* jbailey hides.
<fabbione> jbailey: no
<fabbione> no way i will start to poke gcc
<doko> fabbione: fix binutils ;-)
<doko> for spaaarc
<fabbione> doko: did the fix made upstream?
<doko> I didn't check
<fabbione> doko: tsk...
<doko> heh, its a spaaaaarc ;-)
* fabbione kills amd64 kernels on i386.. kthxbye
<doko> fabbione looks moped
<lamont> doko: if you get bored, you could look at why cfdisk was segfaulting unless built -O1... (#323463, aka ubuntu #13486) - I'm blaming gcc
#ubuntu-toolchain 2005-08-24
<jbailey> Does ccache invalidate the cache based on compiler version?
<lamont> jbailey: yes
<infinity> doko : make binutils_2.16 stop hating pike7.6 (or vice versa).  kthxbye.
<jbailey> http://people.ubuntu.com/~lamont/buildLogs/p/pike7.6/7.6.27-1ubuntu2/ shows all successful, provide a better bug report.
<jbailey> I know I packed the lart around here somewhere.
* jbailey digs through a box.
<jbailey> Even better..
<jbailey> Enya piano music.
<jbailey> infinity: What problem are you seeing?
<infinity>  /build/buildd/pike7.6-7.6.27/src/interpret.c:1287: error: PIC register 'ebx' clobbered in 'asm'
<infinity> Looks like it's been happening ever since the binutils 2.16 upgrade.
<infinity> (Last successful build was with gcc 4.0.0 and binutils 2.15)
<infinity> Only on i386.  The other 3 arches are fine.
<fabbione> morning
<infinity> While it's entirely possible that "write better inline asm" is the real answer, I don't speak x86 asm..
<infinity> jbailey : Also, there's a failed build log there now (and there's a matching one for the previous version)
<jbailey> Eh, looks from the error like they're not setting up their register spilling correctly.
* jbailey looks up to see what pike is and why it needs direct asm
<jbailey> Recent gcc's are a bit stricted about making sure things mark all their asm constructs correctly.
<jbailey> I'd be surprised if there wasn't a fix in pike's cvs or whatever for it.
<jbailey> If doko hasn't looked by tomorrow, I'll try to do so.
<elmo> infinity: regardless, could you look at de-piking-swig?
<elmo> I think it'd be good to drop the stupid thing
<elmo> and/or should I file a bug
<infinity> Bug.  Too bys right now to remember anything that isn't written down.
<infinity> busy, too.
<infinity> elmo : While you're running spiffy tools, can you tell me what would fall out of the archive if libmysqlclient-lgpl went away?
<infinity> Meh, still a few things, apparently.  I should really recompile those on the sly when no one's looking, so I can drop the vile libmysqlclient10
<chmj> doko: ping 
<doko> chmj: pong
<jbailey> # 1 "main.c"
<jbailey> # 1 "/usr/include/x86_64-linux-gnu/stdio.h" 1 3
<jbailey> Luvly.
<jbailey> doko: Around?
<doko> yes, only short, have to go to my computer shop ...
<doko> broken amd mainboard
<jbailey> Ouch
<jbailey> doko: Is there anything else you need in glibc i386? 
<jbailey> If no, I'll upload this.
<doko> do you build it with 4.0 ?
<doko> ahh, no, you don't need the biarch includes for the glibc _build_
<jbailey> Right. =)
<doko> one thing ... please let libc6-dev-amd64 depend on lib64gcc1, same for powerpc, sparc, s390
<doko> and libc6-dev-i386 on lib32gcc1
<jbailey> 'kay.  Should it be (= ?? )
<jbailey> or >= ?
<jbailey> Or just as long as it's installed?
<jbailey> Hmm, sparc64 already has lib64gcc1 in there.
<jbailey> Oh, not dev, but libc6-sparc64
<jbailey> All of them ought to.
<jbailey> Package: libc6-amd64
<jbailey> Depends: libc6 (= 2.3.5-1ubuntu9), lib64gcc1
<doko> yes, maybe  >= 4.0.1 would be ok?
<jbailey> Are you seeing it not get pulled into sometimes, though?
<doko> yes, but the -dev package as well.
<doko> no, by what?
<doko> you need the libgcc for development
<jbailey> libc6-amd64-dev depends on libc6-amd64, which depends on lib64gcc1
<doko> gcc-X.X can't depend on it, because it suckes in the biarch stuff unconditionally ...
<jbailey> This has been in here for a while, it looks like.
<jbailey> BenC added it on 15 Jul 2005
<doko> ok. and maybe the libc6-amd64-dev can provide a lib64c-dev virtual package
<doko> I don't like b-d's like: libc6-dev-s390x [s390] , libc6-dev-sparc64 [sparc] , libc6-dev-i386 [amd64] , libc6-dev-amd64 [i386] 
<jbailey> Then it will be lib64c-dev [s390 sparc i386]  lib32c-dev [amd64]  ?
<jbailey> That's not much better. =(
<doko> well, I would like to avoid a gcc64 package
<jbailey> Let's think about it and do it for a different upload.
<jbailey> It would be nice to find something elegantish.  like libc-biarch-dev
<jbailey> And have it be a dummy packages on archs without biarch.
<doko> yep, that could be nice as well ...
<doko> then talk with gotom about it, I persuaded him to add lib64c-dev ...
<jbailey> doko: Do you know when you will backport the includedir path to gcc-3.4?
<jbailey> I'd like to fix l-k-h do use those paths.
<doko> done
<jbailey> Cool!
<doko> could you upload glibc first, so that I can depend on it?
<jbailey> doko: Yup, lemme push the upload now, then.
<doko> ok, I'm away now for two hours
<jbailey> 'k
<jbailey> I have an appointment this morning too.
<chmj> erm 
<jbailey> chmj: ?
<chmj> how do I install glibc  ?
<chmj> hi jbailey 
<jbailey> What? =)
<jbailey> If you don't have glibc installed, you likely aren't doing to install anything else. =)
<chmj> erm, right 
<chmj> issit it suppose to come with libc.mo ? 
<chmj> in debian that is 
<jbailey> For i18n?
<jbailey> Oh, in Debian?
<jbailey> No idea off hand.
<jbailey> What are you trying to do?
<chmj> find the package that install libc.mo's in /usr/share/locale/(.*)/LC_MESSAGES/libc.mo
<jbailey> On Debian, it's locales
<chmj> oh right 
<jbailey_> Feh, i386 failed.  /me checks
<jbailey_> forced unwind support unavailable?  wtf?
<elmo> what are our chances of dropping gcc-3.3 from main?
<elmo> grub, libpng, libpng3 and openoffice.org seem to be the only things in main that explicityly b-d on it
<jbailey> I thought doko had said okay to that before, with the goal of 3.4/4.0 only for this release.
<jbailey> (so also dropping 2.95)
<elmo> grub at least looks like it's not going to be >> 3.3 ready
<elmo> the changelog talks about 0.97 being the first to support it
<elmo> I  know doko was working on libpng, dunno if it's fixed yet
<jbailey> lamont, lamont-away: ping?
<jbailey> lamont: I think the gcc wrapper might be confused.
<elmo> lamont: ia64 has a kernel now - reminder about daily d-i builds
<jbailey> doko: I seem to get an FTBFS on gcc-4.0:
<jbailey> The following requested languages were not found: ada
<jbailey> Missing build-dep?
<lamont> elmo: thanks
<lamont> elmo: cronjob enabled, and one kicked manually
<doko> elmo: hmm, looks that I missed the libpng uploads. couldn't reproduce the failures anymore
<doko> jbailey: build log?
<jbailey> doko: Locally with the new glibc in a clean chroot.
<jbailey> I can post it for you, though.
<doko> jbailey: the log would be nice. I'll have my computer probably back on Monday
<jbailey> doko: 'kay.  I'll get to it before that.
#ubuntu-toolchain 2005-08-25
<jbailey> I was checking out the gcc-4.0 ftbfs that filed in Debian.
<doko> which one?
<jbailey> Making sure I could close it in Ubuntu when I discovered that it was ftbfs here.
<jbailey> http://bugzilla.ubuntu.com/show_bug.cgi?id=13660
<doko> ah, yes, that one should be fixed with the biarch include dirs?
<jbailey> I was hoping so, or that it didn't affect us at all (since we were able to build gcc-4.0 before just against the glibc)
<jbailey> But then I had that ftbfs.
<jbailey> So... =)
<doko> the 3.4 with biarch include dirs is in the archives. 
<jbailey> Cool!
* lamont grumbles that doko did another gcc-3.3 upload, but didn't switch to expect-tk8.3 for hppa.
<lamont-away> doko: fwiw, gcc-3.4's logwatch process never exits, until you kill it... :-( [hppa] 
* lamont-away sleeps
<doko> lamont-away: but it does terminate for 4.0?
<lamont-away> dunno - I'll make a note of it next time there's a 4.0 upload
<doko> jbailey: the glibc build did fail on i386 ...
<lamont-away> doko: -9 or -10?
<doko> -9
<lamont-away> (-9 is known/expected, -10 should build...)
<lamont-away> he was grumbling about it earlier
<doko> I don't see a -10
<lamont-away> he was going to upload it sometime "soonish"
<lamont-away> -9 had missing build-depends, iirc
<lamont-away> but it's 0121, I should really crawl into bed
<doko> good night, really :)
<doko> jbailey: if you move around the headers in l-k-h, the headers for the default arch will stay where they are?
<jbailey> ROAR I hate sleeping alone in such a big place.  Noises keep waking me up.
<jbailey> doko: I was testing that gcc-4.0 still built correctly with the new glibc and the build deps in a clean chroot while I was at it.
* jbailey uploads -10 now and then goes back to bed
<doko> heh, think you're in Montreal?
<jbailey> Err..
<jbailey> Is this one of those twilight zone moments where you tell me that I'm really in another universe?
<doko> anyway, do you have a l-k-h package which I can test?
<doko> you didn't move from Toronto to some French province?
<jbailey> Yup.  The province of Qubec, city of Montral.
<jbailey> Hey, I see that the massive failures in gcc-4 biarch went away except in Java and mudflap, cool.
<doko> we disabled mudflap for biarch
<jbailey> doko: But in Toronto we lived on the 11th floor surrounded by concrete.
<jbailey> And it was a 1-room appartment.
<jbailey> Here, there's 4 rooms, and it's woodframe.
<jbailey> So things creak and groan, and they're too far away to just look at from bed.
<doko> and libjava isn't built as well, so the failures are ok
<jbailey> I think what woke me up just now was the door to the outside storage swingning a bit (It's broken and needs to be repaired so that it will stay shut)
<jbailey> But I woke up basically to the sound of a door openning.
<jbailey> *sigh*
<jbailey> glibc ubuntu10 uploaded.
<doko> do you have a l-k-h for testing somewhere?
<doko> thanks
<jbailey> I don't.  I was trying to decide if it's worth it for breezy, or if it's too featurish.
<jbailey> Right now it's setup the same way that ppc/ppc64, sparc/sparc64 and s390/s390x is.
<doko> if we want to build the libs from amd64-libs, it's needed
<jbailey> Why?  I think the current biarch stuff should cover it
<doko> no, that' what drow did mention.
<doko> i.e. ncurses includes the wrong headers. wait ...
<jbailey> Debian's lkh is only vaguely related to Ubuntu's. =(
<jbailey> Lemme double check.
<jbailey> Oh, hmm, I'm on crack it seems.
<jbailey> I thought I had biarch'd i386
<doko> ncurses in my home on chinstrap
<jbailey> Ah, I have done so.
<jbailey> Right.  the asm directories, not the linux/ directory which is common.
<doko> shouldn't it be safe, if we just move the headers for the non-default arch to /usr/include/<arch> ?
<jbailey> It should be, but I think Matt considers those things to be features.
<jbailey> And it should be safe to do it the way it's already done, since that's how it's been for other biarchs in the Sarge release.
<doko> so we have to keep amd64-libs, but drop glibc from it?
<jbailey> No idea.  I wouldn't have considered those features.
<doko> well, one goal was to remove at least amd64-libs
#ubuntu-toolchain 2005-08-27
<lamont-away> *** glibc detected *** double free or corruption (!prev): 0x00021050 ***
<lamont-away> grumble
<lamont-away> iproute build on hpa
<lamont-away> hppa
<lamont-away> make[1] : Entering directory `/build/buildd/klibc-1.0.14'
<lamont-away> MCONFIG:90: klibc/arch/parisc64/MCONFIG: No such file or directory
<lamont-away> make[1] : *** No rule to make target `klibc/arch/parisc64/MCONFIG'.  Stop.
<lamont-away> jbailey broke my kernel
<fabbione> lamont-away: check if there is a parisc dir instead
<fabbione> i had a similar issue with sparc/sparc64
<lamont-away> yep
<fabbione> and check the contents of the 2 :)
<fabbione> in sparc64 there were basically empty files
<fabbione> the sparc one was correct
<lamont-away> heh
* lamont-away tweaks, makes plans to upload tomorrow morning, once he's done sleeping, and the build has had a chance to finish
<doko> infinity: ping
<doko> any way to get the config.log from the ncurses upload for i386? I cannot reproduce it here on a real 32bit system
<infinity> As opposed to a fake one?
<infinity> Oh, I had that same problem with glibc.
<infinity> doko : s/-m64/-m64 -march=x86-64 -mtune=x86-64/
<infinity> doko : gcc-opt on the buildds sets -march/-mtune to CPUs that GCC thinks can't do -m64, so you need to reset it.
<infinity> doko : Either that, or fix GCC to stop whining. :)
<doko> ohh, thanks
<doko> infinity: is this necessary for powerpc as well?
<infinity> doko : We don't use -mtune and -march on PPC...
<infinity> doko : PPC looks to be failing for entirely different reasons.
<doko> yes, I see it. strange. and that's not even the -m64 build ...
<infinity> Yeah, I'm giving it a retry to see if it's just the kernel hating me.
<infinity> If it fails the same, I'll give it a spin on a PPC machine at home where I can debug a bit.
<doko> infinity, lamont-away: gcc-opt should not add anything, when it sees -m64 or -m32 ...
<infinity> Okay, NOW it failed on the configure check.  Meh.  Time to save a build tree and look at it, I guess.
<infinity> Erm.   cc1: error: invalid option 'arch=powerpc64'
<infinity> doko : But we don't set -mtune and -march on powerpc anyway, so you shouldn't need to try to reset them.
<doko> ok
<doko> that was ncurses?
<infinity> Yes.
<infinity> Alternately, find out what GCC sets as the "baseline" on -m64, and set it to that.
<doko> we should fix that stupidity on the buildd ...
<infinity> That's what I did for glibc on amd64, to make sure we got what we wanted.
<infinity> s/fix/alter/
<doko> lamont-away, wake up! ^^^
<doko> :)
<infinity> I'll make sure that we have -mtune/-march parameters for "default", "-m32" and "-m64"... But right now, we don't.
<doko> yes, I think we only need them for a few packages now
<doko> infinity: please could you requeue openoffice.org2 on powerpc? I didn't see that failure before ...
<lamont-away> doko: yeah - I know
<lamont-away> doko: we taught it to not add -march for glibc - what else?
<lamont-away> I need to actually teach it about -m{64,32} equivalence stuff
<doko> I think that's all. At least for the three packages I build ...
<elmo> lamont/infinity: FYI, I'm firing up a rebuilt of main on breezy-at
<jbailey> elmo: Will the results for that just be in the usual ~lamont/... ?
<elmo> I don't know how the logging stuff works, sorry
<jbailey> 'k.
<jbailey> lamont-away, infinity: ^^
#ubuntu-toolchain 2005-08-28
<lamont-away> jbailey: p.u.c~lamont/buildLogs/Test
<lamont-away>  /...
<infinity> elmo : How much do I have to beg for us to try a ppc64 kernel somewhere?... I'm seeing some seriously weird misbehaviors.
<fabbione> morning
<elmo> infinity: I'll have a look this afternoon if I can
<jbailey> infinity: If needed, I run a ppc64 kernel here.
<infinity> jbailey : Unless "here" is one of our buildds, it's not much help. ;)
<infinity> The ppc32 kernels on the buildds are festering bits of poo.
<fabbione> doko: ping?
<fabbione> doko: is there any news about binutils fix for sparc?
<doko> fabbione: I didn't check.
<fabbione> doko: mind to take a look please?
<fabbione> i am a bit reluctanct to touch ninutils
<fabbione> binutils
<fabbione> doko, jbailey: the fix for --as-needed is in binutils cvs head as of today
<fabbione> http://bugzilla.ubuntu.com/show_bug.cgi?id=12822
<fabbione> see the last 2 comments
<fabbione> can we please get it in?
* jbailey_ looks
<jbailey_> *13000 lines of testsuite updates*?
<jbailey_> Ooo, It also fixes the multiple PLT bug?
<jbailey_> lamont, ^^
<jbailey_> I want to spend a bit of time today on initramfs-tools first,
<jbailey_> But after that if doko hasn't done it, I will.
<fabbione> cool
<infinity> jbailey_ : You still have another client connected, and it claims to be asleep.  Make up your mind.
<jbailey_> infinity, I have a guest over.  She was supposed to set an alarm so that I could sit at my desk, so I'm on my laptop in the otoher room.
<jbailey_> Not a big deal.  I would've logged it out usually if I had expected this.
<jbailey_> Although given the choice of the two states....
<infinity> (You need ot run your IRC client in screen, so you can just attach to it from anywhere)
<doko> elmo: did you look at binutils yesterday for the patch as well? ^^^
<jbailey_> infinity, I keep looking at console based IRC sessions, and not being happy with what I find.
<jbailey_> I want screen for X.
<jbailey_> Or rather, X apps.
<jbailey_> vnc isn't quite sufficient.
<lamont> jbailey: amusingly, the _GOT_ bug was gcc-4.0 codegen
<jbailey_> Mmm.. other button.
<elmo> doko: yeah, I'm looking at a new binutils for debian including that patch
<doko> jbailey: ^^^
<jbailey_> Coo.
<elmo> infinity/lamont: ?
<lamont> si?
<elmo> infinity/lamont: all 3 ppc buildds are powerpc64; please don't restart them till you linux32 the builds
<elmo> or whatever the appropriate command is
<lamont> roger
<lamont> uh... yeah... doko/jbailey?
<lamont> anything mortally pressing, or can I stall for a couple hours/
<lamont> ?
<elmo> nothing AFAIK
<elmo> btw, linux32 looks like it works fine
<elmo> $build_env_cmnd='sparc32';
<doko> hmm, OOo2 is failing on ppc with strange errors ... eventually I have to try it on a ppc32 kernel. looks like memory corruption, doesn't fail exactly at the same place
<elmo> ^-- is what vore uses to force builds in 32bit, presumably we just need something similar
<lamont> right
<doko> lamont: but don't use 'sparc32' ;-P
<lamont> lol\
<elmo> and I've installed linux32 in base for all 3, I'll leave the chroots to you; dunno if it's needed there
<lamont> doko: do I want 'linux32' or 'ppc32' or???
<doko> linux32 
<jbailey> lamont: Nothing from me.
<lamont> jbailey: was fishing for the command syntax. ;-)
<jbailey> lamont: *lol* =)
<jbailey> I've never tried linux32 on my ppc system.  Nothing has failed to build because of it.
<lamont> jbailey: 64-bit kernel?
<jbailey> Linux ppc64 2.6.12-7-powerpc64-smp #1 SMP Fri Aug 19 16:03:19 UTC 2005 ppc64 GNU/Linux
<lamont> well, if nothing fails to build, then I'm happy...
<lamont> I assume taht 64-bit kernels still build too?
<jbailey> I haven't done any kernel work on this box at all.
<lamont> (AFAIK, sparc needed the kernel build to be different than the rest of the world, so that it worked...)
<lamont> well, it'll show up as ftbfs issues then, I expect. :-)
<jbailey> But all my glibc and gcc testing for the biarch stuff was done without linux32.
<lamont> cool.
<lamont> I'll kick them sometime this afternoon, if infinity doesn't beat me to it
<elmo> lamont: don't forget the d-i + livecd stuff too
<lamont> elmo: right
#ubuntu-toolchain 2009-08-19
<sadik123> see..i  have loaded ubuntu 9.04 amd desktp...with ekiga 3.2.0 as defualt which dosent have autoanswer mode....how to ena ble it...or  kindly advise me how to load other sipclient which has auto-answer mode in ubuntu 9.04
#ubuntu-toolchain 2017-08-23
<doko> pekkari: you are noisy ...
<pekkari> because the channel shutting dwn?
<doko> no, the channel is not shutting down
<pekkari> then sorry to bother, I'm always willing to improve, let me know if there is something you want to suggest
<pekkari> oops! >D
<pekkari> :D
