24 April 2005

Solaris 10: Yet another development tip

A little note about something to be careful of when compiling and developing applications within a non singlebyte locale (a Unicode or locale other than "C"). You should always check the man pages of the utilities you're using in your build process or anywhere else first before using them. Some of the utilities that are in /usr/bin or /bin only properly handle singlebyte locales and won't work properly in others.

For example, the "tr" utility in /bin/tr or /usr/bin/tr will fail with a not-so-helpful message about "bad string" when in reality you've given it perfectly valid input. This is a result of it not supporting singlebyte locales. Instead, you will have to use /usr/xpg4/bin/tr or /usr/xpg6/bin/tr which support multi-byte locales.

Technorati Tag

19 April 2005

Solaris 10: A Few Development Tips and Solutions

Like me, after setting up Solaris 10 and getting your development environment going with the gcc that comes "in the box" (or "in the iso" as is the most likely case), you may have run into bizarre errors when running "configure" for programs you tried to compile and install. "configure" spouts things like system unable to compile programs, no proper compiler installed and so forth. You may also have encountered errors about missing symbols that look like they come from libstdc++. Well, be mystified no more. Four easy steps to a more blissful development environment:

1) Remove /usr/ucb from your path. You probably won't miss it, and unless you have the SUN studio tools installed, it's best if it's not in your path anyway (due to /usr/ucb/cc I believe).

2) Apply the fix found here for SUN's possible oversight.

3) Add /usr/sfw/bin to your $PATH (preferably *first* in my opinion)

4) Add /usr/ccs/bin to the *end* of your $PATH

Have fun!

Technorati Tag .

09 April 2005

Need a quick way to kill the X server?

Recently I had an X11 program misbehave and esentially make my JDS desktop unresponsive to my input. Since I don't have another system nearby where I can login in via SSH and kill Xorg manually, I've just been hitting the reset button because for some odd reason Control + Alt + BackSpace doesn't kill the server by default with Solaris 10 (on some systems possibly?).

Well, I happened to post about this on the Solaris x86 Yahoo Group Mailing List and Adrian Saul along with Casper Dik of SUN were kind enough to post the solution, and why it was needed. The solution is simple, add the below to the bottom of your /etc/X11/xorg.conf:

Section "ServerFlags"
Option "HandleSpecialKeys" "Always"

Solved the problem rather nicely, fear misbehaving X11 programs no more!

Technorati Tag

07 April 2005

Packaging Options?

Continuing on with my journey into the world of Solaris...

A problem has confronted me, namely what to do about packaging. Yes, Solaris 10 comes with it's own packaging system. However, let's be honest, it's not nearly as convenient to use as RPMs are, especially when you need the ability to rebuild packages on demand easily.

Since the company I work for uses RPMs to manage all of our software installs via an apt-get repository (which works really, really well by the way) now on RedHat Enterprise Linux boxen I wanted something as similar as possible. I first tried to compile the latest RPM source on my own, and discovered that it was disappointingly Linux focused (Linux isn't UNIX folks, please stop using non-portable functions, etc.). Enter OpenPKG.

OpenPKG provides me with a way to migrate our existing software management structure with fairly little pain over to Solaris 10 while retaining all the conveniences and benefits of both binary and source package management. It also makes people happy that might have otherwise been unhappy with my constant push to move from a Linux platform to Solaris 10.

Some people might think it's rather abhorrent to have multiple packaging systems on their Solaris box, but I don't think so. Especially since this way, I can isolate all the packages or custom versions of common libraries we use into its own directory tree without interfering with SUN's packages in any way and feel safe in the assurance that any changes to my OpenPKG tree won't impact the rest of my system in any permanent fashion.

Yes, I already considered other solutions such as pkgsrc, pkg-get, and so on. However, none of them really have the elegance or simplicity that I needed for managing a completely custom software repository comprised of both binary and source packages. I am interested in other projects out there that are similar to RPM if they exist. Leave a comment if you know about something I don't...

Technorati Tag