[01:41] <jbailey> doko: ping?
[01:48] <doko> jbailey: pong
[01:49] <jbailey> doko: I'm having a bitch of a time tracing down this last error from ld, hoping you can suggest something.
[01:50] <jbailey> When I install the libc6{-dev}-amd64 packages, ld tells me:
[01:50] <jbailey> /usr/bin/ld: warning: ld-linux-x86-64.so.2, needed by /lib64/libc.so.6, not found (try using -rpath or -rpath-link)
[01:51] <jbailey> The NEEDED section doesn't list a path in libc.so.6, so the implicit -L/lib../lib64 that collect2 hands over ought to be enough, I think.
[01:51] <jbailey> If I make a symlink in /lib to /lib64/ld-linux-x86-64.so.2, it compiles, and I can remove it after, so there's no runtime requirement.
[01:51] <jbailey> Just that for some reason ld beleives that there's a link time requirement.
[01:52] <jbailey> If I add an -rpath line to it, it works fine, but I think that it shouldn't be needed.
[01:53] <jbailey> (The warning is follow by some symbol errors which are in the ld-...so.2 - so it's not just randomly warning me)
[01:54] <doko> hmm, look at the i386-biarch patch in gcc-3.4. LINK_SPEC wants /lib64/libc.so.6
[01:54] <jbailey> Which is right.
[01:56] <jbailey> is it possible to get ld to dump out a list of what it thinks are the available libraries and howit resolved them?
[01:57] <jbailey> It seems almost certainly like a glibc problem, the same collect2 line done with amd64-libs works fine, but readelf -a looks basically the same between the two.
[01:57] <doko> hmm, not that I know of
[01:58] <doko> you see this with gcc-3.4 or gcc-4.0 ?
[01:58] <jbailey> -3.4
[01:58] <jbailey> So far I'm onyl working with that until I get the glibc built.
[01:58] <doko> and does the link step work with 4.0 (if you're doing only this one with 4.0)?
[01:59] <jbailey> Dunno.  I'll dig up a biarch gcc-4.0 to try that with.
[01:59] <jbailey> glibc doesn't build with gcc-4.0, so I hadn't been looking at that at all.
[01:59] <doko> just compared the biarch patches. 4.0 is missing the LINK_SPEC chunk
[02:00] <jbailey> Oh, hmm.
[02:19] <jbailey> YAR
[02:19] <jbailey> I wish I smoked so that I could stomp off and have one.
[02:19] <jbailey> It seems that biarch amd64 wants /lib64 and /usr/lib64 added to ld.so.conf
[02:20] <jbailey> doko: So my glibc is fine.  I just need to either put this hackery into ld.so.conf, I guess. =(
[02:21] <jbailey> Or fix it properly in the linker, I guess.
[04:42] <doko> jbailey: How is this solved for amd64 native?
[04:43] <doko> or isn't this an issue, because lib is a symlink to lib64?
[04:43] <jbailey> amd64 native has hackery in glibc to mke this all just work.
[04:43] <jbailey> My current build has the hackery in for i386 too.
[04:43] <jbailey> amd64 will need additional hackery to deal with /lib32 correctly.
[04:44] <jbailey> (but it's all in the same .h file in glibc)
[04:44] <doko> oh, fine.
[06:44] <elmo> fuck's sake
[06:44] <elmo> does anyone know how CONFIG_MAC gets defined?
[06:46] <jbailey> elmo: Context?
[06:46] <elmo> powerpc kernel builds
[06:46] <elmo> it's not mentioned in .config, but I'm getting some compile errors with breezy kernel and a custom config
[06:46] <jbailey> elmo: Try #ubuntu-kernel, better audience there.
[06:46] <elmo> meh
[06:46] <elmo> i'm about ubuntu'ed out of channels, never mind
[06:47] <jbailey> I'm thinking specifically zul, who does alot of kernel stuff with Fabio
[06:53] <fabbione> hey elmo
[06:54] <fabbione> elmo: iirc CONFIG_MAC is defined only on PPC32..
[06:55] <fabbione> if you need, i can check but arch/ppc/Kconfig (grep for MAC) is a good place to start
[07:09] <doko_> fabbione: gettext on sparc: please look at the config.log file to see, why the jar test fails.
[07:10] <fabbione> doko_: thanks i will :)
[09:52] <doko_> fabbione: do you have a sparc live CD, either hoary or breezy?