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.
[#] Wed Jul 23 2014 10:54:30 EDT from IGnatius T Foobar @ Uncensored
I would call Linus.
Linus will just change the kernel ABI so your program doesn't work at all anymore.
[#] Wed Jul 23 2014 10:54:40 EDT from IGnatius T Foobar @ Uncensored
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.
[#] Fri Jul 25 2014 18:56:07 EDT from LoanShark @ Uncensored
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.
[#] Fri Jul 25 2014 18:58:30 EDT from LoanShark @ Uncensored
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 /
[#] Fri Jul 25 2014 19:01:16 EDT from LoanShark @ Uncensored
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...
[#] Fri Jul 25 2014 19:14:42 EDT from vince-q @ Cascade Lodge BBS
you might be the only guy in the world...
Now why does that sound like a lead-in to a song in a b'way musical...
Yep, it's an ancient Red Hat system, but I have to support it. The company really needs to move on to more modern technology, but it would require them to do a lot of work that, given current workloads, they can't accomplish.
But they need to figure it out before their competition points out how antiquated they are.
I only had to make two new functions to get it to compile properly. The point is to work with the operating system as-is, so it made more sense for me to alter the compiler than to alter the OS. Really weird situation, as it isn't how you'd normally work. But, I've proven (to myself at least) that you can build the modern compiler on an extremely old OS. I'd say the only compiler feature that had to go involved the libsanitizer stuff. Everything else seems to be intact.
I got a whiff of dealing with Solaris next. I think the trickiest thing there might be getting the damned thing to untar without fucking up. I'm going to go with the theory that I don't have enough space, and try to create a drive for the thing that's larger than the 30 gig drive I already created for it. But, I'm not really sure that's the nature of the problem.
It's kinda fun, jumping into this sort of stuff again. I'm thankful I have the time to focus on it, rather than having to have something out in a couple of minutes from yesterday.
Things related to Linux that you should probably avoid saying in the military:
Booting the Colonel now.
[#] Mon Jul 28 2014 13:36:40 EDT from LoanShark @ Uncensored
I got a whiff of dealing with Solaris next. I think the trickiest
thing there might be getting the damned thing to untar without fucking
up. I'm going to go with the theory that I don't have enough space,
and try to create a drive for the thing that's larger than the 30 gig
drive I already created for it. But, I'm not really sure that's the
nature of the problem.
Could be you need gnu tar, and you can download binaries of that from the usual suspect Sun ports site - used to be sunfreeware.com was the best place to go, and it's still around, though I don't know if it's still your best bet. However, you should definitely save yourself some time by downloading the newest binaries that are available from there before you try to build something even newer.
If it's not a gnu tar thing, "df" is the command to check available space on the filesystem...
Go to page: ...  ...