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
there).

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...

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...

Heh...

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.

Heh...

Things related to Linux that you should probably avoid saying in the military:

Booting the Colonel now.

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...

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

Right, but installing a newer version of zlib in /usr/local or some other prefix is not "altering the OS"

It isn't altering the OS if you want to quibble, but it's forcing me to have to change something I suspect is kind of primal to the operating system such that it isn't what it originally was anymore, which I fear could have a rippling effect on the rest of the system.

Or, at the very least, I need to alter as little of the target OS as possible when installing our application. From a packager's perspective, I don't want to have to deal with upgrading the gzip library on a system, regardless of how moldy it is, just so my software works. Better if my software can work with the OS as-is, even if the OS is ridiculously and hopelessly out of date.

More work for me, yes, but necessary given what these guys are trying to do. Although, amusingly, I may be throwing all of this effort away soon if they upgrade their courses.

As for Solaris, I figured that out independantly (but thank you for the information, as who knows how long it might have taken me to find the difference). That was indeed the problem. I have it busy compiling gcc 4.7.4 now. With any luck, this will go more smoothly than past attempts.
It's already been at it for a good while now, which is encouraging.

Hm... actually, modifying the code to handle what was missing in the native zlib might have cost me less effort than having to install an updated zlib for these OSes. I shall never have to deal with updating the zlib (forgetting to do so, pulling into the rpm I need to build, or whatever). Theoretically, once I build this (particularly if I link to my libs statically), I am free to simply copy the binary where I want it, and it should work.

We'll see as I get further into this.

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

/opt/sfw is on pretty much every Sun system over here ... and their numbers are dwindling as people figure out it's a lot easier to just use Linux.

Oh, I got around the 'tar' problem, incidentally, by compiling it from GNU's sources rather than using the packaging system.

Because, at the end of the day, you can compile almost anything and make it work with enough willpower.

It isn't altering the OS if you want to quibble, but it's forcing me

to have to change something I suspect is kind of primal to the
operating system such that it isn't what it originally was anymore,
which I fear could have a rippling effect on the rest of the system.

Ok, if you install a library in /usr/local it goes onto the compiler include path by default, which may not be what you want. So. Install it in, say, /opt/gnu, along with the rest of the toolchain you're installing, and you won't have that problem.

This is the usually recommended way to build a stack of dependencies that may be differently versioned from what's included in the base OS.