#ubuntu-toolchain 2005-09-19
<lamont> uh - where did binutils-hppa64 go?  and what does gcc-3.4 plan to do about it?
<lamont> doko/jbailey/elmo: ^^^
<jbailey> Err, it was there last I looked.
<jbailey> Can youtell when it dissapeared?
<lamont> my brainfart
<lamont> must look at ports.u.c, not archive.u.c
<jbailey> =)
<lamont> doko: gcc-3.4: logwatch never terminates, so the build hangs (outside of timeouts...)  would be interesting to hear your thoughts on that....
<doko> breezy or unstable ?
<fabbione> lamont: i have seen that happening too once in a while
<fabbione> on sparc breezy
<fabbione> it disappeared on its own
<doko> I don't know how to make that disappear, the trap on exit is removed from the logwatch script.
#ubuntu-toolchain 2005-09-21
<lamont> jbailey: klibc failure with linux32 in the mix.  kthxbye
<lamont> http://buildd.mmjgroup.com/buildLogs/k/klibc/1.0.14-1ubuntu2/klibc_1.0.14-1ubuntu2_20050916-0830-hppa-failed.gz 
<lamont> linux32 /usr/share/misc/config.guess 
<lamont> hppa64-unknown-linux-gnu
<lamont> linux32 uname -m
<lamont> parisc64
<jbailey> lamont: Luvly, thanks.  I'll look at it on j5k.
<jbailey> Hopefully it's up today.
<lamont> jbailey: trivial fix
* lamont tests
<lamont> jbailey: email sent
#ubuntu-toolchain 2005-09-22
<infinity> lamont : Feh, if 'linux32 uname -m' on parisc64 is returning parisc64, not parisc, then parisc64 personalities are broken.  I was almost sure that had been addressed long ago, but maybe not (I never owned a parisc64 machine, so this was all from memory)
<infinity> My parisc machine was a lowly 32-bit C200.
<infinity> lamont : Pretty please, with sugar on top, pester linux-parisc upstream to fix 32/64 kernel personalities, push the patch upstream, and use that patch on your buildd.  :)
<lamont> infinity: parisc _ALWAYS_ returns parisc64
<lamont> always has (on a 64-bit kernel_)
<infinity> No it doesn't.  Only when running a parisc64 kernel.
<lamont> that's what I said. :-)
<infinity> Anyhow, it's broken.  It shouldn't.  That's what personalities are for (it's ALL they're for)
<infinity> We just got it fixed for ppc/ppc64 in 2.6.12, now it's your turn. :)
<lamont> yeah - jbailey's going to beat on the parisc folks, but in the mean time, we'll just do the hack to klibc that has been done everywhere else
<infinity> <nod>
<infinity> I assume you had line-of-sight (and perhaps line-of-office-supply-tossing) with some parisc kernel guys.
<infinity> s/assume/assumed/
<lamont> well... certainly when I have a mirror...
<lamont> but the issue here is talking to the folks that did the implementation, and figuring out what it really should be saying when.
<infinity> If so, tell them to search lkml for ppc64 and uname over the last 4 or 5 months.  Should tell them what to fix. :)
<lamont> and it's not something to change right now...
<infinity> (I could provide a patch, but have no way to test anything)
<lamont> esp since we can't build/install the new (fixed) ubuntu kernel until we have a working klibc...
* infinity wonders idly if this is also broken on s390/s390x..
<lamont> jbailey wondered the same thing, and ran away screaming at 31-bit worlds
<lamont> or something like taht
<infinity> I think arm/arm64 is okay.
<infinity> Yeah, I don't think s390 would bother with a "linux31" binary, they'd just pretend to be 32-bit and carry on. :)
<jbailey> infinity: The fix is almost tribial, but not quite.
<jbailey> infinity: They use the personality to change how they handle signals internally.
<jbailey> It's almost certainly not what they meant.
<infinity> Oh, FUN.
<jbailey> I think I have it mapped out as to what needs to change.
<jbailey> I'm going to sleep on it and do it then.  I have klibc for lamont already.
<jbailey> Just need to hand it to fabio, and then I think that's done for breezy.
<jbailey> (unless someone comes up with another !@#$ing filesystem they want to use as a root one)
* lamont mutters about big kernel changes right before release...
<infinity> Well, there's no docs (afaik) saying you can't extend the use of personalities to do other neat hacks/tricks, just what they SHOULD do (fool userspace into believing you're on a 32/64 bit kernel when you're not)
<lamont> oh, klibc, not the kernel.
<lamont> nm
<jbailey> infinity: What they've done in this case is assume that a 32 bit binary means you want a 32 bit personality.
<jbailey> infinity: I think.  I'm having trouble tracing some of this code. =)
<infinity> That's possibly reasonable.
* lamont waits for his 2.4-kernel-possessing knoppix 3.7 ISO to burn, then he's gonna reboot and head home
<jbailey> It's not how sparc and ppc do it.
<infinity> But they're still not munging uname output, which is the issue.
<infinity> No, it's not what sparc and ppc do in the slightest, but it seems a valid extension to the use of personalities.
<jbailey> sparc and ppc set a threadinfo variable with the info.
<jbailey> Which frightens me to think that they might have PER THREAD shit^Wstuff going on.
<infinity> I suppose this is where I start being greatful that Motorola never announced a 68k-64 CPU.
<jbailey> infinity: Probably.  a 4 mhz 64 bit CPU would really suck for data loads.
<lamont> hehe
<infinity> <grin>
<lamont> 64-bit 8051
<jbailey> I still like the idea of just runnign the whole m68k buildd in a nice emulated environment on a large ia64 machine. 
<infinity> Hey, if they opened up the specs, any goober with access to fab flipchips could get the 68060 scaled ridiculously high, I'm sure.
<infinity> It's just that Motorola never upgraded their fabrication, ever.  New ones are still the old ceramic things you can clock peopl ein the head with.
<jbailey> Why should they, really?  If you wanted a small 32 bit chip, the i386 is good enough.
<jbailey> Last I checked they were still producing those by the assload.
<infinity> <nod>
<infinity> Well, Motorola still produces 68k stuff by the assload too, just not the desktop chips.
<jbailey> YEah, they still have the embedded medical market.
<infinity> The more popular all-in-one stuff with fancy multimedia controllers and such (but, oddly, no MMU) are in high production still.
<lamont> well, I'm off
<jbailey> g'n LaMont
<infinity> Later.
<jbailey> infinity: The other reason in particular that magic isn't a good idea is that it means that all 32 bit binaries would always report parisc from newuname
<infinity> Yes, including a 32-bit 'linux64' binary.
<infinity> That would definitely seem wrong.
* lamont-away grumbles at doko for uploading gcc-3.3 without switching hppa to expect-tcl8.3
<doko> laon-taway, ohh, yes, something I forgot ... is it a FTBFS?
<doko> lamont-away: ^^^
<lamont-away> doko: well, I can babysit it through, but yeah
<doko> lamont-away: no need, m68k died, so I have to reupload
#ubuntu-toolchain 2006-09-18
<fabbione> doko_: i just started a new OOo build on faure with newer libc
<doko_> how far did it go?
<fabbione> i just started..
<fabbione> it still hangs in the same place
<fabbione> i need food now
#ubuntu-toolchain 2006-09-20
<fabbione> doko_: ping?
<tmarble> hello
<doko_> fabbione: pong
<fabbione> doko_: hey dude..
<doko_> tmarble: good morning
<fabbione> i am told that you got access to the Niagara boxes ( or box ) at the datacenter
<fabbione> doko_: do you think you can look into that linking problem Nikolai is having?
<fabbione> i remember i did fix the exact same problem installing lib64stdc++ and rebuilding a C++ apps
<fabbione> but the same doesn't help with that C code snippet
<doko_> hmm, I think, I don't got a key/login yet. I'll ask jbailey
<doko_> which linking problem?
<tmarble> doko_: that would help us immensely
<tmarble> doko_, i need to file the bug... has to do with linking
<fabbione> doko_: the one that Tom did mail to us
<fabbione> doko_: login has been sent to you about 2 weeks ago
<doko_> hmm, I'll look at it, recovering my email currently
<tmarble> doko_ my e-mail to you and fabbione of 9/7 titled "[Fwd: Re: minor trouble with Niagara and Ubuntu] "
<tmarble> shall I resend?
<fabbione> doko_: i did try but with no luck..
<doko_> no, I have the emails on the server
<fabbione> doko_: so help there is appreciated. i am sure it's not a libc6 issue
#ubuntu-toolchain 2007-09-18
* Starting logfile irclogs/ubuntu-toolchain.log
<arthur-> doko: thanks ;-)
<doko> np
<arthur-> doko: would a new gdc-4.1 upload be possible with a -16d1 rev for example?
#ubuntu-toolchain 2017-09-19
<zarzar> i need help finding and installing gcc/g++/as arm-linux-gnueabihf version 4.8.1 on ubuntu
