I recently built a third party source on the Mac, only to find it had a number of unresolveds (link errors.)

If you build in XCode, the tool is kind enough to tell you what’s referencing the unresolved(s). From the commandline, it’s not so obvious.

Since this is third party code, I don’t want to have to go through the hassle of building an XCode project — but I need to find out which modules were referencing the link unresolveds.

Finally, after a bit of head-scratching, I got the solution — so I can share it, here, if you’re unlucky enough to be searching for this needed capability:

The Solution – Getting the Module/Filename That References the Unresolved

You need to enable a link flag ‘-y’, followed by the unresolved symbol (you’ll get that from the failed link output.) Go into the Makefile and find LDFLAGS (’ld’ is the gnu linker — this is the typical Makefile variable for the options) and add the ‘-y’ flag, followed by the symbol, like this:

LDFLAGS = -y__2435ZClass5FunctioniiiEi [rest of options]

Some of the symbols can get quite long — make sure you paste and copy the whole thing, including the leading underscores. Next time you do a build, the link step will output a line as to what module in your project references that symbol (yay.)

Your work’s not necessarily over — the lib I was building uses a very complex class hierarchy, and it wasn’t apparent which lines of code were causing the unresolved, even though I knew what file it was happening in. If that’s the case, then what I do is selectively #ifdef out parts of the file until I can make the unresolved symbol appear and disappear in subsequent links. Then I can narrow it down to the offending line and fix it. (You get a whole bunch of other unresolveds as you comment out sections of the code — ignore those, of course.)

Tedious, but it works.

I imagine the same would apply in a linux/bsd environment — anything that’s using the Gnu toolsuite.

rickb

Now that the Mac has finally settled down, I’ve been moving my development efforts off of Windows and onto the Mac.  And just recently, I’ve done a partial upgrade to Leopard (hedging my bets by installing it on an external USB drive.  Best of both worlds – I can boot Leopard off the USB, and Tiger off the internal.)

XCode is a reasonable IDE – better with the Leopard incarnation.  The integration with gdb is tight – I’m having to go to the cl gdb less frequently.  Qt is working just fine on the Mac, with no surprising ‘Mac’ gotchas.  (In fact, I’ve gotten more ‘gotchas’ in the linux environment than I have Mac.)(Or Windows.)

A few things I miss in the Windows environment:

• Visual Studio has better capability to look at out-of-scope expressions.  If I want to examine the contents of a pointer, it’s easier in VS than in Xcode.
• Visual Studio’s ability to debug Javascript in IE is simply awesome – it looks and behaves pretty much like any other language in the IE.
• Windiff is still the best windowed comparison program in the land.

For PHP development, Zend’s Eclipse IDE port works fine on the Mac (and the latest incarnation adds a lot of features.)  For first cut debugging of Javascript, the Firefox debugger handles most cases – although in a crunch, I’m tempted to go back to MSVS for the more puzzling situations.

Still, for the most part, I’ve been ‘living in the environment’ and haven’t been tempted to shift back over to Windows for anything in particular.

So,  the Mac is becoming pretty much my mainstream preferred development environment.  With the addition of Parallels and a few scattered VM’s , I can do the verification builds and debugging on Windows and Linux as necessary, using net shares to access the central development environment.  There’s a bit of a time penalty for going this way – but I don’t build frequently in the VM’s and the trade-off for not having to carry more than one machine more than compensates for a slightly slower build.

Ah.  There is one area where the Mac is really hands-down the preferred platform: imaging.  For one thing, you can color profile both displays – an annoying shortcoming in Windows (XP, anyway).

It took a couple of runs, but I got Ubuntu (the ‘K’ version) up and running under Parallels on the Mac. So, I’ve got four environments on a single machine. Basically good, but I can only run two VM’s at a time, it seems. Too much memory whack trying to run all three. I’ll have to play with memory tweaks to see if I can get three VM’s to play together. Windows just requires a bunch, so launching that VM means taking up a third of the machine’s resources.

The Rationale

Several, really – one, I’m a command-line junkie, and KDE’s command window is simply the best – a tabbed version that allows grouping of several command windows together. This is a good thing, since I will often have six or more command windows open on two or three different machines/servers at a time. Tabbing them in logical groups keeps the desktop clutter down.

Secondly, I want all three environments for cross-platform development testing. A lot of the new development platforms are coming up under open source – eclipse, Qyoto, Qt, Ruby (on Rails), PHP, etc., etc. Linux is the place to hammer those out, and Ubuntu is the easiest of the bunch to install and keep updated.

(Aside: Parallels on the Mac is in version 3, and seems to have improved, for the most part.  There are the usual gripes in the forums from the usual cranks, but on the whole, it seems to be working well.  Also: version 3 adds 3d support to the Windows VM, an important consideration for a 3d graphics software developer. )

Now, I need to hook up four screens…

Next investigation is automating the .rss feeds from WordPress.

I’ve extolled the virtues of Qt extensively, and will continue to do so – it’s a great toolkit for cross-platform UI development.

Same for Open Inventor (TGS’ version, particularly), for the 3D graphics world.

But, getting those environments is costly: enough to consider having to mortgage the baby and the house, if you don’t have the backing of a major corporation.

Thus the dilemma I faced when needing to write an architectural feasibility exploration program. What to use?

We had Open Inventor, but no Qt. And I needed it longer than a month, so the trial version was not a consideration. The first attempt was to use our OIV with the straight Win32 API.

Yeah, ok, you can do that, but it’s a lot of lines of code, and it isn’t quick. Not exactly an agile environment. Need to do something better.

The Solution

Web investigations led me to wxWidgets for the UI. wxWidgets might be considered the poor sister to Qt (although devotees would argue that.)

And, for an Open Inventor solution, there is either the horse’s mouth – SGI themselves – or the COIN implementation from the Systems In Motion folks in Finland, who provide an open-source version. The SGI is open-source, too, but it doesn’t come with an SoWin implementation, so COIN looked like the better answer.

And, they’re both free – completely free in the case of wxWidgets – less free, but ok for internal/demo use in the case of COIN.

The Conclusion

They worked great! I had to hook up the SoWin directly into the wxWidgets idle loop, but that’s not onerous. Create an SoWinExaminerViewer, parent it with a win HANDLE (available from the widget), and things were spinning, soon enough.

More to discuss in this line, but they look very promising for low-budget investigations or even products that can’t sustain the full investment of their much more expensive counterparts. This is much more true in the case of wxWidgets, since it’s use is free and completely unrestricted. If you’re going to use COIN in a commercial product, you will have to pay…

More to come…

rickb