| fabbione | morning | 06:22 |
|---|---|---|
| === 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 | ||
| Keybuk | 'sup? | 05:52 |
| doko | yep | 05:53 |
| doko | jbailey: how can we get the search path for the linker for 64bit binaries on a 32bit system? | 05:54 |
| jbailey | So a system where you can't actually run the linker? | 05:56 |
| doko | we don't have one, when building gcc and libraries biarch | 05:59 |
| jbailey | There's no guaranteed way right now. | 06:18 |
| 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:19 |
| 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:20 |
| === lamont [n=lamont@15.238.5.97] has joined #ubuntu-toolchain | ||
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| jbailey | The base system builds the package fine. | 06:27 |
| jbailey | It's just a cross compiler at that point. | 06:27 |
| Keybuk | there's more to building a package than just compiling, as you know well | 06:28 |
| === 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 | ||
| doko | they do work, if you do have the right kernel | 06:40 |
| 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:43 |
| doko | elmo would be "happy", if we do that for powerpc and i386 ... | 06:44 |
| jbailey | Keybuk: Right. | 06:49 |
| 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. | 06:50 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| === jbailey turns on the amd64 box. | ||
| jbailey | doko: Is this a new thing? | 07:23 |
| jbailey | Oh. duh, pass -m64 to cpp, Jeff | 07:24 |
| 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:25 |
| Keybuk | zcat|awk can be replaced by grep-dctrl | 07:26 |
| lamont | true. | 07:27 |
| lamont | but then I'd have to remember grep-dctrl. :-) | 07:27 |
| Keybuk | that reminds me | 07:28 |
| Keybuk | I need to figure out why #13306/#322595 talks about dpkg-deb | 07:29 |
| lamont | grep-dctrl -s Filename -n . /org3/ubuntu/dists/breezy/*/binary-hppa/Packages.gz | 07:30 |
| lamont | sadly, the version of grep-dctrl on the best machine for the job doesn't read .gz files very well.. | 07:31 |
| Keybuk | gah, found _another_ dpkg disappear/replaces bug *sigh* | 07:35 |
| doko | jbailey: why don't you want to install the x86_64 headers in libc-dev, as done by amd64-libs-dev? | 07:37 |
| jbailey | Where did amd64-libs-dev install them? I thought that they hadn't installed them for some reason. | 07:38 |
| === jbailey checks the hoary setup again. | ||
| 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:41 |
| lamont | doko: could you look at that hppa patch and see if it's sensible in 3.4 as well? | 07:42 |
| 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:46 |
| lamont | 27 | 07:47 |
| === 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? | 07:50 |
| lamont | jbailey: not that I know of | 07:50 |
| 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:51 |
| 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:55 |
| jbailey | lamont: I'd have to check the ELF spec to be really sure, but I don't remember ever seeing it. | 07:56 |
| lamont | well, it's only fatal when two of them have it. :-) | 07:57 |
| jbailey | Right. =) | 07:57 |
| 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. | 07:58 |
| jbailey | Anything can reference it, though, it should just not be provided by them. | 08:00 |
| lamont | right. thanks. | 08:36 |
| === 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. | 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:42 |
| lamont | interestingly, we just have local absolute symbols that have that value, it appears. | 08:47 |
| lamont | IOW, it may just be that I took the debian issue and extrapolated it onto ubuntu | 08:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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. | 08:52 |
| lamont | jbailey: right. | 09:00 |
| 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:01 |
| 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:02 |
| lamont | $no_build_regex = "."; | 09:11 |
| lamont | that just makes me feel dirty. | 09:11 |
| 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:12 |
| lamont | jbailey: not sure what debian did for their 2.3.5 glibc... | 09:14 |
| jbailey | What do you mean? | 09:14 |
| lamont | well, they felt that they had to binNMU glibc after fixing gcc-4.0... | 09:17 |
| 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:18 |
| === lamont just shrugs | ||
| 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:19 |
| 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:20 |
| === 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! | 09:21 |
| lamont | jbailey: heh | 09:21 |
| 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? | 10:10 |
| 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:11 |
| lamont | ah, true | 11:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!