Another maddening Visual C++ bug
I’ve run across some infuriating Visual C++/vcbuild behavior that, as it turns out, is a bug that was “just found too late to make it into the 2005 product. [Microsoft] will most certainly be addressing it as soon as we possibly can”
The gist of it? If you have a solution with two or more DLL projects, one dependent upon the other, and you use the “Link Library Dependencies” linker option to automatically link against the lib produced by the project being dependened upon, the IDE will compile and link find but vcbuild (and msbuild) will fail to link. Upon inspecting the build log, you see that the library that should’ve been linked in is not.
So, add that to the growing pile of shit that never should’ve made it into RTM and will be fixed in the next version of Visual Studio.
How is it that msbuild can suck so bad and be MS's Grand Unified Build System!?
Today I’m working on a simple automated build system for my new employer. With the taste of Microsoft kool-aid still lingering on my tongue, I naturally went with MSBuild, a tool for whom Microsoft marketing either failed utterly, or simply couldn’t be bothered to try.
On its face, MSBuild is a reformulation of the Visual Studio project files in nant-like terms, which (supposedly) unifies powerful GUI project support (that is, Visual Studio) with the power and flexibility of a task-based build system like nant. Under the covers, however, it becomes obvious that MSBuild is but a pale shadow to nant, and as an added bonus it laughs dismissively when asked about Mono support.
The real kicker, however, is the way Visual C++ is made to sit at the back of the build bus. From a third party article comes this:
Visual C++ support for MSBuild is coming, but not as soon as we’d like. For the Visual C++ .NET 2005 release, the project file format will be similar to the XML-based structure used in Visual C++ .NET 2003. The reasons for the lack of inbuilt MSBuild support are varied, but the main issue for Visual C++ will continue to be the need for the Visual C++ team to spread their resources between managed and native compilation, and the need to ensure that technologies such as MSBuild that come from the managed side offer adequate support for all the native features that Visual C++ continues to offer. The amount of work completed by the Visual C++ team during the Whidbey development cycle has been Herculean, and the fact that MSBuild support is not fully there in the next version is certainly understandable.
Hmm. Well, thank you very much, Visual C++ team, for your Herculean efforts; nevermind that they are all for naught as Visual C++ is and remains a second class citizen to the younger, hotter, more easily distracted languages like C# and VB.NET. So what, then, do you get if you use MSBuild against a .vcproj file? Well:
However, you can pass a solution file containing a C++ project to MSBuild and MSBuild will cause the C++ program to get built. There is an MSBuild task called VCBuild that uses a tool called VCBuild.exe http://www.gotdotnet.com/team/cplusplus/ to compile up the project. The VCBuild tool, C++ compiler, and linker seem to be installed with the Framework (or possibly the Framework SDK, I carelessly forgot to check).
(From http://www.winfx247.com/247reference/msgs/0/1759.aspx)
Hmm. So, if I have a .sln file with Visual C++ projects, I can build them from the command line with MSBuild? Neat! I’ve only been able to do that for the last four years with devenv! Lame.
Contrast this with nant; yes, I have to use an exec task to launch vcbuild, but this is what you get from MSbuild as well. Nant, however, doesn’t stop there; you get a rich set of built-in tasks, a stupid-easy extension mechanism, all sorts of intrinsic functions, and a well-understood, well-maintained open codebase. What do you get with MSBuild? The smug satisfaction reserved for those who use the MS tool no matter how much worse it sucks than all the others.
Screw that. You’ve got a way to go, MS, before I ditch nant…
Follow up from Johannes Ernst on group membership and lightweight ID management
A few weeks ago, I emailed Johannes Ernst, asking him how (if at all) he saw lightweight URL-based ID management technologies like LID being used to express group membership semantics. As he promised, he’s put together a long post on group implementation in LID, which answers my questions.
On the plus side, I’m encouraged to see that this type of use case has been on the minds of the ID management players for at least a year, and that they recognize at least as clearly as I do how powerful this concept could be. However, it’s not implemented yet, which means I don’t get to play with it. Too bad; the possibilities for (creative) destruction boggle the mind.
Back from brief Colorado trip
I’m back from my brief trip to Colorado to visit my siblings in college and my grandfather. I left Thursday night and returned early this morning. The general shittiness of travel notwithstanding, I enjoyed seeing my family and am glad I went. I was particularly struck by the strong command of English and generally positive disposition demonstrated by virtually all retail and service workers in the Fort Collins/Denver/Colorado Springs area; it makes it all the harder to return to Herndon where I have to strain my ears to discerne the expletives the heavily-accented clerk/waiter/cabbie throw at me.
Tomorrow I begin my official employment at AppAssure, doing all manner of cool software engineering in a relaxed atmosphere within walking distance of at least one reputable drinking establishment.
More MySQL and disk full problems
The MySQL//var partition full problems continue. Though I repaired the watchdog table, I get the following error whenever I try to view the log in drupal:
user warning: Incorrect key file for table '/var/tmp/#sql_31f_0.MYI'; try to repair it query: SELECT w.*, u.name, u.uid FROM watchdog w INNER JOIN users u ON w.uid = u.uid ORDER BY w.wid DESC LIMIT 0, 50 in /usr/local/www/drupal/includes/database.mysql.inc on line 120.
Note that this query joins two tables: users and watchdog. There is no #sql_31f_0 table in the query. However, MySQL is creating a temp table with which to perform the join, and /var doesn’t have enough space to hold a copy of the intermediate results of the join, since watchdog has grown too large.
I could truncate watchdog, but the real problem is that /var is too small (250MB). So, I added another virtual disk, /dev/ad3, which is a 2GB disk that I’ll dedicate to /var/db/mysql.
The Adding Disks section of the FreeBSD handbook covers adding a new disk pretty thoroughly.
Then I moved the contents of /var/db/mysql over to the new volume (which I screwed up a bit; hint: preserve the privs!), and put an entry in /etc/fstab to mount /dev/ad3s1d to /var/db/mysql.
I then created the my.cnf file in /var/db/mysql, and added the following:
[mysqld]
tmpdir=/var/db/mysql/tmp
To put temp tables in /var/db/mysql/tmp instead of /var/tmp, so they won’t exhaust the /var filesystem anymore. And voila!
Mysql Error After Disk Full Problem
Last weekend my problem with disk space exhaustion resurfaced, and seemed to upset MySQL, as I get the following warning when I log into Drupal:
user warning: Table ‘./drupal/watchdog’ is marked as crashed and should be repaired query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (1, ‘user’, ‘Session opened for root.’, 0, ”, ‘http://apocryph.org/?q=user/login’, ‘http://apocryph.org/?q=user/login’, ’65.89.8.127′, 1153755477) in /usr/local/www/drupal/includes/database.mysql.inc on line 120.
I’ve not seen this message before, and don’t know how to repair. Perhaps the MySQL docs…
I found a decent article on repairing MySQL tables; it’s pretty straightforward:
bonzo# mysql -u www -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 38 to server version: 5.0.9-beta
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> use drupal;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> check table watchdog;
+-----------------+-------+----------+-----------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------------+-------+----------+-----------------------------------------------------------------------+
| drupal.watchdog | check | error | Table './drupal/watchdog' is marked as crashed and should be repaired |
+-----------------+-------+----------+-----------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> repair table watchdog;
+-----------------+--------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+-----------------+--------+----------+----------+
| drupal.watchdog | repair | status | OK |
+-----------------+--------+----------+----------+
1 row in set (1.09 sec)
mysql> \q
Bye
That was easy…
Things I won't miss when I leave BE
My last day with BearingPoint is a week from day, on Thursday 27 July. As I go through my last days here, I’m taking stock of the things I won’t miss:
- The circuitous parking deck
- The funny smell in the corridors outside the elevators on the parking deck levels
- The depressing, silent elevator ride every morning
- Overhearing painfully cliche Dilbert-esque elevator banter
- Waiting in line for the damn microwave
- The 12 square feet of billboard space dedicated to CYA regulatory compliance posters explaining my rights to decline a polygraph and earn minimum wage
- The immensely annoying ringtone on my Cisco IP phone (yes, I could change it, but it’s easier to curse the darkness than light a candle)
- Remembering to log into my phone every morning
- Wearing an ID badge everywhere I go
- Dressing up every day for no good reason
- Paying $5 for the privilege of wearing jeans on select Fridays
- Commuting on the toll road every day
- Being the only person in the company who has used
gdborWinDbgto solve hard problems - Abusing an endless supply of good coffee
- Having to violate corporate IT policy on pain of death and termination in order to run any operating system developed within the last five years
- Developing .NET apps on a Dell Latitude D600 identical to the ones BE hands out to all its other employees, be they admin assistants, management units, business analysts, or senior developers
- Developing software with Oracle 8i
- Security policies that can be summarized as “fuck it, just unplug the damn thing, your work isn’t that important”
- Keeping a timesheet, daily, on pain of death and termination
- Wondering which key employee will be leaving this month
- Overhearing other employees tell eachother how ready they are to go home at the end of the day, and knowning how they feel
- Counting the days until the next weekend
- Sunday evening depression in anticipation of work on Monday
Of course, it’s not been all (or even mostly) bad, but as I’m on my way out, I can’t help but notice all the little things that have bugged me for over two years, and delight in the knowledge I will suffer them no longer.
Happy Birthday
Today is my 26th birthday. How fitting that something as insignificant as a 26th birthday should fall on a Monday and be spent at the office fixing bugs. My family came over yesterday to celebrate, so there’s not much left to do on this the actual day except skip the gym and eat until I lose consciousness.
Leaving BearingPoint
Effective Thursday 27 July, I have resigned from BearingPoint, and am moving on to AppAssure, a very small, early-stage startup building some next generation technology that [NDA filter].
I was soured on BE after the unceremonious end of my Iraq tour, but even before then I was growing restless and looking for something with a more deeply technical component. AppAssure gives me that in spades, with everything from a kernel-mode driver component through high-performance user-mode C++ server work and C#/.NET GUI tools. It’s also small and early stage, which means low bullshit and high upside.
In my 2.5 years at BE I’ve learned alot of non-tech soft skills at BE, made some great relationships, and traveled abroad to Europe and the Middle East, but it’s definitely time to move on.
Running out of space on /var thanks to MySQL
This morning I noticed the /var filesystem was at 100% capacity on bonzo, leaving MySQL somewhat hosed. Upon poking around in /var (which, sadly, I only made about 300MB) I removed a CVSUp catalog for the FreeBSD src tree that was taking up alot of space, and with the time that bought, sought a permanent fix.
First, I see three big files in /var/db/mysql: ib_logfile0, ib_logfile1, and ibdata1. Upon a bit of googling, I found these were the tablespace and log files for the InnoDB storage engine in MySQL, somewhat akin to the data and log device files SQL Server uses.
The problem, though, is that none of my databases use InnoDB. The MyISAM storage engine is fine for my needs, and considerably less complicated. So, I poked around for the my.cnf config file that’s supposed to be in /var/db/mysql, but it’s not there, suggesting the InnoDB stuff was compiled in. At any rate, I moved the files elsewhere and made sure my databases were still working, which they are if you’re reading this.
Longer term, I need to grow the /var filesystem…