The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Friday, February 16, 2007

The one-off server

“It looks like I'll have to create a new virtual server for it,” I said to Smirk. “But I know exactly how to set it up.” We're moving our spam firewall from the Boca Raton Data Center to the Charlotte Data Center and in the interim (if all goes well, about eighteen hours), we need something to sling the email about.

“So this poor virtual computer will be doing nothing but email then?”

“Just email,” I said. “For the next day or so.”

“A virtual slave,” said Smirk. “and a short lived one at that.”

“'Fraid so.”

“So, are you making DNS changes?”

“Nope,” I said. “I plan on giving it the same IP address as our spam firewall, shutting down the ethernet port the actual spam firewall is plugged into, and routing the traffic to the virtual server.”

“So it doesn't even have an identity of its own,” said Smirk.

“Nope.” By this time, we were both laughing maniacly, but it's one of those times you had to have been there to get it (and I know I'm not recounting the conversation even remotely close).

It takes just a few minutes to create the server and get it configured, and in a day or two, it'll be killed just as quickly.

So much for Pinocchio.

Update later today …

Think I spelled ``maniacly'' wrong? Think again


Bunny acts as my editor, sending me spelling errors and grammar mistakes. So it wasn't terribly surprising to find the following note from her:

“maniacally” as in “laughing” …

I knew when writing this entry that I was in trouble with the word “maniacly.” “But I did a Google search,” I said to Bunny. “And that's what came out.”

Bunny looked at me suspiciously, and started a few Google searches of her own. And she found:

Morphemes, not just words, can enter the realm of pleonasm: Some word-parts are simply optional in various languages and dialects. A familiar example to American English speakers would be the allegedly optional “-al-”, probably most commonly seen in “publically” vs. “publicly”—both spellings are considered correct/acceptable in American English, and both pronounced the same, in this dialect, rendering the “publically” spelling pleonastic in US English; in other dialects it is “required”, while it is quite conceivable that in another generation or so of American English it will be “forbidden”. This treatment of words ending in “-ic”, “-ac”, etc., is quite inconsistent in US English—compare “maniacally” or “forensically” with “eroticly” or “heroicly”; “forensicly” doesn't look “right” to any English speakers, but “erotically” doesn't look “right” to many Americans. Some (mostly US-based) prescriptive grammar pundits would say that the “-ly” not “-ally” form is “correct” in any case in which there is no “-ical” variant of the basic word, and vice versa; i.e. “maniacally”, not “maniacly”, is correct because “maniacal” is a word, while “agnosticly”, not “agnostically”, must be correct because "agnostical" is (arguably) not a real word. This logic is in doubt, since most if not all “-ical” constructions arguably are “real” words and most have certainly occurred more than once in “reputable” publications, and are also immediately understood by any educated reader of English even if they “look funny” to some, or do not appear in popular dictionaries. Additionally, there are numerous examples of words that have very widely-accepted extended forms that have skipped one or more intermediary forms, e.g. “disestablishmentarian” in the absence of “disestablishmentary”. At any rate, while some US editors might consider “-ally” vs. “-ly” to be pleonastic in some cases, the vast majority of other English speakers would not, and many “-ally” words are not pleonastic to anyone, even in American English.


In other words, we're both correct. “And this is why I love English,” she said.

That explains things

I got an answer to my query about linking:

Unix linkers.
Fri, 16 Feb 2007 14:18:53 -0500 (EST)

SPC posts:

So let me get this straight: I link against the library, and the program doesn't work. I link against the object files, and it works just fine.


Anybody care to explain?

I have had stuff like this happen to me periodically. It is basically a weakness in the design of UNIX linkers. Sadly, a modern UNIX machine with gigs of RAM and high speed multiple CPU's is still linking like it's a PDP-11.

One possability is that there is a netsnmp.a somewhere in the system library path [there is, which explains why my recompiled version with debugging information didn't work—heck, that explains quite a bit of the wierdness even though the version that was installed and the version I installed were the same —Editor] and it doesn't match the headers you are compiling against. But you probably did install the libraries yourself—beware! Sometimes on Linux they have shared libraries that the linker will try to link against first! I think -V or -vv will print out the commands GCC is actually doing. Or just try adding -L/home/spc/apps/net-snmp-5.1.2/snmplib [I did—it didn't work. I think I'll have to uninstall the system supplied SNMP libraries —Editor]

And I would not use the “~” there since GCC won't expand it and your shell probably wouldn't either. But that's just the most obvious. I've had far more “interesting” problems with UNIX linkers.

At least, my most common problem has been that when you have lots of circular references I always end up naming library files 20 times on the command line. A modern linker will continue to resolve from libraries until all dependencies are satisfied.

Normally failing to list say syscore.a 10 times on the command line simply results in an error. However, this stupidity can work both ways—sometimes you end up pulling in the wrong object module in that pile of libraries because UNIX just goes through the libraries one at a time rather than resolving symbols from their nearest source (like the library that just generated the external!).

There are other bad things that can happen to you too; weak symbols are normally “NULL” (usually all 0's) unless they happen to be satisfied explicitly (by say, naming a .o)—the linker won't go looking for them. Combine that with defensive software that does something dumb (meaning: not crash) on an unexpected NULL pointer and you can get strange behavior like that.

And lets not forget some systems that try to make everything a shared library call even if you specify a .a (Oh, I see this awesome .so here for you—haha). UNIX shared libraries just suck. Avoid them unless you enjoy say bleeding out of your ass—in which case go for it!

What I've found (and I'm not even linking for UNIX, I just happen to be linking on UNIX) is that I make a linker definition file—which yeah, it's totally GNU specific—that can then tell the linker what to do (the GROUP() directive will often resolve libraries the way they are supposed to be resolved).

But I've learned almost never to use .a files under UNIX. I just build up a list of 1,000 or so .o files for my latest creation and let the linker chug through them.

Welcome to the future!


[links added by me —Editor]

A lot of information there that I wasn't even aware of, like weak symbols, linking scripts and the GROUP() directive. I can see I have quite a bit of reading to do.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.