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...
[#] Mon Jul 28 2014 13:37:19 EDT from LoanShark @ Uncensored
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.
[#] Mon Jul 28 2014 15:21:18 EDT from IGnatius T Foobar @ Uncensored
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.
[#] Mon Jul 28 2014 16:13:20 EDT from dothebart @ Uncensored
last time I cared blastwave.org was the most reliable source for fresh solaris ports.
[#] Mon Jul 28 2014 16:33:48 EDT from LoanShark @ Uncensored
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.
[#] Mon Jul 28 2014 16:35:34 EDT from LoanShark @ Uncensored
(if it isn't completely clear, doing things as described above will link zlib with the compiler toolchain you're building, but not with binaries generated by that toolchain - by default.)
If I did that, of course, I'd have to ensure that I install the library somewhere on the OS. It's yet another dependency I would need to track.
If I do it my way, I don't have that dependency, and setup is simplified.
Perhaps I should point out that the two functions I needed out of the updated zlib was 1. compressBound, which simply calculates an estimate of how much space is needed for the compression, and 2. ceil, which is used by compressBound for its calculation, is normally included in 'math', but for some peculiar reason I can't link that library into the compiler.
Neither of these functions are revolutionary or terribly difficult to implement.
If I needed 10 functions, some of which involved some relatively intricate programming that would be unwise of me to attempt, yeah, I would suffer the setup dependency. But for the price of creating two very simple functions, avoiding a setup dependency seems like the better way to go.
At least, that's my reasoning.
[#] Tue Jul 29 2014 09:18:46 EDT from dothebart @ Uncensored
since docker (LXC) seems to be hot tech, see this one:
FIG seems to be a really nice tool:
That looks rather useful... isolated dev environments in a flash.
Fucking hell... trying to read anything about Docker is like reading a web site full of nothing but buzzwords.
I feel like I'm listening to Weird Al's "Mission Statement" tune.
I assume eventually I'll read something that actually has some real meat to it, but honestly, I'm incredibly turned off by all this buzzword shit.
[#] Tue Jul 29 2014 11:18:56 EDT from dothebart @ Uncensored
thats because of its 95% LXC, some added guts, and LOTS of marketing.
Gah... fucking marketing...
The usual enmity between engineering and marketing continues.
Go to page: ...  ...