Seems to me you have to know Vim to play the game, I really didn't get too far before becoming frustrated. You
are the black cursor not the guy in the center of the screen.
that's rather neat, actually.
I'd love to play that sometime when I'm not at work.
Playing with Fedora today.
Maybe I don't quite understand the issue that lead someone to say something like this, but supposedly we can't build binary RPMs because we haven't paid for a Red Hat Developer's license or somesuch.
That doesn't strike me as true, though, so I'm looking into things myself.
Hence, installing Fedora. Well, that, and I wanted to look at systemd and see how well I can set up our services to auto-start in that environment's configuration scheme.
Lots of toe-dipping this year.
I'll say this for Fedora, though... it looks pretty out of the box.
But I'm not sure I like the whole 'grab the screen and pull up' screen-locking mechanism they use. I'm sure I can configure something else, but... this isn't a touch-screen.
fleeb, you should use centos to compile.
these are guaranteed to produce library dependencies with RHEL.
with fedora you've got bleeding edge, and may not find your libs over there.
Oh, nice to know!
I've at least managed to learn how to work with systemd with Fedora. But it's a little weird that one form of logging to syslog works, while the other one I use doesn't (yeah, this is difficult to explain well).
Mon Jul 07 2014 07:51:09 AM EDT from dothebart @ Uncensored
Maddog is digitizing his ye olde VHS-Tapes:
Linus talk at dec.
Nice! Thanks for that.
I would call Linus.
Linus will just change the kernel ABI so your program doesn't work at all anymore.
Free network equipment shape gallery designed to allow #LibreOffice and#OpenOffice users to create network
Holy hell, but I managed to compile Gnu GCC 4.7.3 on Valhalla. I'm feeling plucky, though... building GCC 4.8.3 on it now.
Honestly, compiling these damned compilers feels like I'm beating code into submission. Seriously.
'nm' complains that it doens't understand the -p option? No problem. the
'nm' that it's calling is actually 'exec' (for some insane reason), so I just replaced it with the binutil/nm-new that it should have used in the first place. Shit like this.
Valhalla's version of zlib doesn't have compressBound, which is required by the latest version of binutils, which is required by GCC now? No problem, I'll write it myself. Oh, that function needs 'ceil', which is in -lm, but I can't link it? I'll create my own 'ceil'. How hard can it be?
I'm beating this fucking code into submission.
Valhalla's kernel lacks an __NR_exit_group interrupt, which libsanitizer wants? No problem, configure --disable-libsanitizer and try again.
This effort is kind of silly.
Get a recent version of binutils and uncompress it into the gcc-4.8.3 folder (from the gcc-4.8.3.tar.gz you unpacked). Follow other instructions (like getting other dependencies, etc). configure --prefix=[wherever] --disable-libsanitizer (but from within a different folder, because you can't cross the streams, heh). Then make.
Make *will* fail. Because something stupid happens, and gcc/nm is actually 'exec' for some dumb reason. cp buildutils/buildutils/nm-new gcc/nm and try again. Oh, it doesn't put 'binutils' in the right place. Move their binutils to binutils.orig, then ln -s binutils.orig/binutils to binutils. make again.
Waiting for that to go wrong so I can fix the next problem.
I get to do all of this kind of nonsense again with solaris, incidentally, since these guys have an ancient version of that OS they would like for us to support.
Is it worth it, you may wonder, to use a modern compiler? I think so. But it sure seems silly.
Oh, and s/buildutils/binutils/g above.
Aand, I figured out why I had to do some of that stupid wonkiness earlier.
The binutils archive presumes to be the top-level of the gcc archive, rather than a sub-folder. So, I have to copy the subfolders to the top-level gcc bits (taking care not to obliterate anything already there).
In any event, after yet another attempt to recompile the whole thing (java fails to compile on this system, so I'm not including it), it seems to be much happier. Well, also my zlib modifications are still there.
Aaand, that's that. GCC 4.8.3's gcc and g++ installed on a Red Hat Valhalla machine. I'm currently 'testing' it by compiling something really tough on it. If it can handle boost, it's good enough for my needs, and I'll have something that should do what we need for this product.
I get to do all of this again with Solaris. But, I have a better idea what I need to do now. It ought to be easier this next time.
The binutils archive presumes to be the top-level of the gcc archive,
rather than a sub-folder. So, I have to copy the subfolders to the
top-level gcc bits (taking care not to obliterate anything already
This sounds like "the old way" to do it, or a historical artifact that is still (partially?) supported in the Makefiles. I think it's more standard these days to build binutils as a separate project, "make install" it to your chosen prefix, and then configure gcc, making sure the configure script sees your desired version of binutils...
But if you're building a cross-compiler, I can't speak to that.
Also, I worry that you may be straying a bit far from what's well-supported, what with all those custom functions... (why not just build a more recent zlib?)
and sorry, what's Valhalla? I only see references to an ancient version of Red Hat that went by that name.
and sorry, what's Valhalla? I only see references to an ancient
version of Red Hat that went by that name.
aaaand never mind. You really are working on some ancient systems.
I advise: rm -rf /
Aaand, that's that. GCC 4.8.3's gcc and g++ installed on a Red Hat
Valhalla machine. I'm currently 'testing' it by compiling something
you might be the only guy in the world...