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