[06:22] <fabbione> morning
[05:52] <Keybuk> 'sup?
[05:53] <doko> yep
[05:54] <doko> jbailey: how can we get the search path for the linker for 64bit binaries on a 32bit system?
[05:56] <jbailey> So a system where you can't actually run the linker?
[05:59] <doko> we don't have one, when building gcc and libraries biarch
[06:18] <jbailey> There's no guaranteed way right now.
[06:19] <jbailey> Probably the best bet would be do so something with bfs.
[06:19] <jbailey> bfd
[06:19] <Keybuk> can't you just ship ldd in the bi-arch libc6-dev packages
[06:19] <jbailey> Keybuk: ldd just called ld.so with some parameters.
[06:19] <Keybuk> right
[06:19] <jbailey> calls, even.
[06:19] <Keybuk> so make that work ;)
[06:19] <jbailey> If you can't run a binary of the target architecture, there no option there.
[06:20] <jbailey> If you could, ldd has already been hacked to select the right ld.so. =)
[06:20] <Keybuk> I don't understand why these library packages are being produced if they can't work?>
[06:21] <Keybuk> so far this bug reads like "we're doing some shit that can't possibly work AND IT'S YOUR FAULT!"
[06:21] <jbailey> They can work, you just need a capable kernel.
[06:22] <jbailey> So install the right one. =)
[06:22] <jbailey> The problem with using objdump and such is that there's no way to know what glibc considers to be the linker path.
[06:22] <jbailey> linker search path, rather.
[06:23] <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?
[06:23] <jbailey> And it'll change over time as we do multiarch.
[06:23] <jbailey> Keybuk: Probably 'cause people want to build them at home or such.
[06:24] <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
[06:27] <jbailey> The base system builds the package fine.
[06:27] <jbailey> It's just a cross compiler at that point.
[06:28] <Keybuk> there's more to building a package than just compiling, as you know well
[06:40] <doko> they do work, if you do have the right kernel
[06:43] <jbailey> doko: Right, but you can build the stuff either way.  You just can't run testsuites or ldd on it.
[06:43] <jbailey> Or use built-sources in any way.
[06:43] <Keybuk> but the point is that if these source packages need "the right kernel" to build, they should ensure they do before they try
[06:43] <Keybuk> and right now, they're not
[06:44] <doko> elmo would be "happy", if we do that for powerpc and i386 ...
[06:49] <jbailey> Keybuk: Right.
[06:50] <jbailey> The joys of the multiarch setup.
[06:50] <jbailey> I don't even know how possible it would be to bend glibc into doing a cross-ldd.
[07:13] <doko> jbailey: what about the libc6-dev-amd64 headers for libc6-dev on i386? Can you estimate, if that's doable?
[07:13] <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' :-(
[07:14] <jbailey> doko: Yeah.  Just need to add that include SEARCHDIR hook, I guess.
[07:14] <Keybuk> lamont: no
[07:14] <Keybuk> it'd be easy to do
[07:14] <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...
[07:14] <doko> jbailey: SEARCHDIR hook?
[07:14] <lamont> Keybuk: yeah
[07:15] <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.
[07:15] <jbailey> If it didn't find the header, try the main ones.
[07:15] <lamont> jbailey: is there a glibc upload coming anytime soon?
[07:15] <doko> jbailey: it already does, but for C++ headers only
[07:15] <jbailey> lamont: doko asked for one yesterday to help sparc along.  Got something for me?
[07:16] <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?
[07:17] <lamont> ISTR hppa got built with gcc-3.4....
[07:17] <lamont> jbailey: or is glibc now building with the default gcc?
[07:17] <Keybuk> dpkg-deb --fsys-tarfile /path/to/deb | tar xv -C /where/to/extract "*.so" | xargs $COMMAND
[07:17] <Keybuk> lamont: ^ :p
[07:17] <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
[07:18] <doko> jbailey: in which directory should gcc search the x86_64 headers?
[07:18] <lamont> Keybuk: heh.  I'd have figured that out... :-)  But I guess I'll still buy you a beer sometime
[07:18] <jbailey> lamont: No, everything is building with 3.4 still
[07:19] <jbailey> doko: Mmm.  I think Tollef's proposal was /usr/include/GNU-TRIPLE wasn't it?
[07:19] <jbailey> So /usr/include/x86-64_linux ?
[07:19] <doko> jbailey: look at biarch-include-ix86.dpatch and add something. but I'm unsure, if fixincludes is aware of that
[07:20] <jbailey> I thought fixincludes was a noop on Linux these days.
[07:20] <jbailey> The system headers sould already be gcc safe.
[07:20] <doko> jbailey: that directory is already searched for.
[07:21] <Keybuk> jbailey: /usr/include/x86_64-linux-gnu
[07:21] <jbailey> Keybuk: Yes, dear.
[07:21] <doko> 4.0 only ...
[07:21] <jbailey> Ah, that's probably why I didn't notice it, lemme check it.
[07:23] <jbailey> doko: Is this a new thing?
[07:24] <jbailey> Oh. duh, pass -m64 to cpp, Jeff
[07:25] <doko> gcc-4.0 (4.0.1-1) unstable; urgency=high
[07:25] <doko>  * Disable multiarch-includes; redo biarch-includes to include the paths
[07:25] <doko>     for the non-default biarch, when called with -m32/-m64.
[07:25] <lamont> Keybuk: it got bigger. :-)
[07:25] <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&
[07:26] <Keybuk> zcat|awk can be replaced by grep-dctrl
[07:27] <lamont> true.
[07:27] <lamont> but then I'd have to remember grep-dctrl. :-)
[07:28] <Keybuk> that reminds me
[07:29] <Keybuk> I need to figure out why #13306/#322595 talks about dpkg-deb
[07:30] <lamont> grep-dctrl -s Filename -n . /org3/ubuntu/dists/breezy/*/binary-hppa/Packages.gz
[07:31] <lamont> sadly, the version of grep-dctrl on the best machine for the job doesn't read .gz files very well..
[07:35] <Keybuk> gah, found _another_ dpkg disappear/replaces bug *sigh*
[07:37] <doko> jbailey: why don't you want to install the x86_64 headers in libc-dev, as done by amd64-libs-dev?
[07:38] <jbailey> Where did amd64-libs-dev install them?  I thought that they hadn't installed them for some reason.
[07:41] <jbailey> Right, I had tried installing them in /usr/include/x86_64-linux and it hadn't worked.
[07:41] <jbailey> But I see that that's not the search path now.
[07:41] <jbailey> So I'll do that.  Easy enough.
[07:42] <lamont> doko: could you look at that hppa patch and see if it's sensible in 3.4 as well?
[07:46] <lamont> doko: which version of gcc-defaults switched hppa back to 4.0?
[07:46] <lamont> (not clear from the changelog if it was 27 or 28)
[07:47] <lamont> 27
[07:50] <jbailey> lamont: Do you need other fixes in glibc for the next upload?
[07:50] <lamont> jbailey: not that I know of
[07:51] <lamont> +glibc (2.3.5-1ubuntu7hppa1) breezy; urgency=low
[07:51] <lamont> +
[07:51] <lamont> +  * drop glibc234-hppa-remove-mallocdef
[07:51] <lamont> that's all I have locally, and that was in -1ubuntu8, so all should be happy.
[07:55] <lamont> doko/jbailey: so correct me if I'm wrong, but no .so files should have _GLOBAL_OFFSET_TABLE_ in the dynamic syms, right?
[07:56] <jbailey> lamont: I'd have to check the ELF spec to be really sure, but I don't remember ever seeing it.
[07:57] <lamont> well, it's only fatal when two of them have it. :-)
[07:57] <jbailey> Right. =)
[07:58] <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."
[07:58] <jbailey> But it's extern.
[07:58] <jbailey> (by spec)
[07:58] <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.
[08:00] <jbailey> Anything can reference it, though, it should just not be provided by them.
[08:36] <lamont> right.  thanks.
[08:42] <jbailey> lamont: I still haven't gotten access to j5k again, but doko gave me access to his hppa box.
[08:42] <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.
[08:47] <lamont> interestingly, we just have local absolute symbols that have that value, it appears.
[08:48] <lamont> IOW, it may just be that I took the debian issue and extrapolated it onto ubuntu
[08:49] <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....] 
[08:49] <jbailey> 'k
[08:50] <jbailey> Or I wonder if it's something historical from the 2.3.2 glibc that only showed up in that archive.
[08:50] <jbailey> But since breezy is built with 2.3.5 in its entirety.
[08:51] <lamont> I think it was actually something that showed up with 2.3.5-built-by-gcc-4.0
[08:51] <lamont> which is to say, I may be doing overkill in bootstrapping gcc :-)
[08:52] <jbailey> Erm.
[08:52] <jbailey> Don't do that. =)
[08:52] <jbailey> Actually, no.
[08:52] <jbailey> You can't have done that without serious patching.
[08:52] <jbailey> It just won't build at this point.
[09:00] <lamont> jbailey: right.
[09:01] <lamont> our glibc is build with 3.4, and is FTBFS with 4.0, correct?
[09:01] <jbailey> Right.
[09:01] <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
[09:02] <lamont> ./usr/lib/libapt-pkg-libc6.3-6.so.3.10 00116b7c g DO *ABS* 00000000 Base _GLOBAL_OFFSET_TABLE_
[09:02] <lamont> plenty of entries like that
[09:02] <lamont> but they're all local, not exported
[09:02] <jbailey> I will do the gcc-4 hackery for 6.04
[09:11] <lamont> $no_build_regex = ".";
[09:11] <lamont> that just makes me feel dirty.
[09:12] <jbailey> Should that not be .* ?
[09:12] <lamont> if the regex exists in the string, it's a match
[09:12] <jbailey> Ah. 'k.
[09:12] <lamont> so the only thing that '.' doesn't match is an empty line
[09:12] <lamont> that's on the hppa/breezy buildd
[09:14] <lamont> jbailey: not sure what debian did for their 2.3.5 glibc...
[09:14] <jbailey> What do you mean?
[09:17] <lamont> well, they felt that they had to binNMU glibc after fixing gcc-4.0...
[09:18] <lamont> so it would seem that they did a 2.3.5 build with gcc-4.0, no?
[09:18] <jbailey> Err..  They shouldn't have, unless gotom's been playing with some of the gcc-4 patches.
[09:18] <jbailey> I told them I didn't think it was a good idea and got into an argument with drow and gotom, though.
[09:19] <jbailey> Ayup
[09:19] <jbailey> I also don't know for certain that we're using the same hppa patches between Debian and Ubuntu.
[09:19] <lamont> the last time glibc was built by the buildd was 2.3.2.ds1-22
[09:20] <jbailey> I did the backport for Ubuntu, and I think gotom did his own.
[09:20] <lamont> which is to say, we have no build logs
[09:20] <jbailey> Even better!
[09:20] <jbailey> =)
[09:21] <jbailey> lamont: I was good!  I didn't even ask!
[09:21] <lamont> jbailey: heh
[10:10] <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?
[11:11] <jbailey> lamont: The stage1 compiler gets built with the ccache.
[11:11] <jbailey> lamont: After that, I'd be surprised if you ever poluted the cache.  It calls itself explicitely by pathna,e
[11:22] <lamont> ah, true