a wily blog

I’m sure these things are obvious to seasoned Solaris developers, but here are a few things I’ve learned today:

• gcc 3.4.3 does not support threads on Solaris. The “-pthread” option doesn’t exist for Solaris except in later versions, so upgrade your compiler or use the Sun compiler (where you’ll use “-mt” to request threaded code).
• scons on Solaris assumes you are using a Sun compiler and applies flags as such, even when you’re using gcc. Yes, even if it detects and uses gcc. See the note about “-KPIC” in the scons changelog.
• boost doesn’t really compile on Solaris with Sun C++ 5.8, but you can hack stuff to make it sorta work.
  This relates to boost 1.40.0. There are two main issues:
  • int64_t and friends don’t get defined. You’ll have to patch cstdint.hpp. Here’s my hacked replacement.
  • The Sun compiler doesn’t do return object optimization, which means that code like:
    
    class Foo {
    private:
    Foo(Foo& f);
    public:
    explicit Foo(int i);
    };

    Foo bar(int x) {
return Foo(x);
}

    doesn’t work. The call to Foo(x) works fine, but the compiler thinks you need to copy the resulting Foo object in the act of returning it to the caller, which is commonly optimized out these days. Here’s a replacement for the affected boost/thread/detail/thread.hpp. Of course boost 1.41 doesn’t have the same problem since the return type for the affected function is different.

For reference, a couple of illustrative error messages:

• int64_t problem:
  
"/home/daniel/boost_1_40_0/boostdir/include/boost/date_time/time_duration.hpp", line 264: Error: int64_t is not a member of boost.
"/home/daniel/boost_1_40_0/boostdir/include/boost/date_time/time_resolution_traits.hpp", line 48: Error: int64_t is not a member of boost.

• Return value optimization problem:
  
"/home/daniel/boost_1_40_0/boostdir/include/boost/thread/detail/thread.hpp", line 344: Error: boost::thread::thread(boost::thread&) is not accessible from boost::move(boost::detail::thread_move_t).


---

I’m sure that most of my audience will find this incomprehensible, but I have high hopes that Google will index this properly and find it for a poor head-scratching soul with similar frustrations.

Have a nice day!

I was very, very annoyed that the 0.10 release of nautilus-open-terminal changed the accelerator from “t” to “e”, meaning that I could no longer right-click on my gnome desktop and press “t”.

Rather than unlearn years of muscle memory and learn to press “e” instead, I built my own version that reverts the change.

Here’s the fixed SRPM and RPM for Fedora 11 i586:
source: nautilus-open-terminal-0.13-2ac.fc11.src.rpm
binary: nautilus-open-terminal-0.13-2ac.fc11.i586.rpm

I know, the accelerator got changed to fix some bug that was filed against Ubuntu, but I don’t use “New Tab” (nor can I find it anywhere in nautilus). So I achieved victory by getting the source, changing a few lines, and rebuilding, since this is open source. Hooray!

Have a nice day.

(footnote: The problematic change was noted as: ‘Change “Open in Terminal” accelerator to “e”, for not conflicting with “New Tab”‘)

Update:
Versions for Fedora 12 (beta right now):
RPM: nautilus-open-terminal-0.17-4ac.fc12.i686.rpm
SRPM: nautilus-open-terminal-0.17-4ac.fc12.src.rpm

Although dovecot comes with its own full-text indexed search, it doesn’t seem to be enabled by default, at least in Fedora 10.  This is a shame.  For me, it makes a search for body text take a few seconds rather than a couple minutes.

To fix, modify your /etc/dovecot.conf and restart dovecot.

• Add fts and fts_squat to the mail_plugins line in your protocol section (protocol imap for me).

Specifically, look for:

protocol imap {
...
#mail_plugins =
...
}

and change it to look more like:

protocol imap {
...
mail_plugins = fts fts_squat
...
}

• Add fts = squat to the plugins section.

plugins {
...
fts = squat
...
}

Sadly, there was no Ubuntu help forum thread that made all this blindingly obvious, so I hope this post fills that need. This all worked on Fedora 10 with dovecot 1.1.10.

Have a nice day.

Recently I’ve needed to install a virtual machine on my spiffy RHEL 5.3 system, so I turned to VMWare, since its free Server software (1.0 series) worked fine on Ubuntu Dapper.  So I tried installing Server 2, because newer is better, right (you know where I’m going…)?

Server 2 does user-level authentication, so you need to specify the admin user at setup time.  That will be the only user (initially) that can touch the vmware instance.  This means that if you disable the root password, then you should not choose ‘root’ as that user.

So this is fine, except that I couldn’t login initially.  The trick is that VMWare does its own user authentication off of the normal /etc/{passwd,shadow} files, and I was authenticating with Kerberos as an AFS user.

Here’s how to fix things.  You need to modify /etc/vmware/pam.d/vmware-authd .  Upon installation, it contains:

#%PAM-1.0
auth   required   pam_unix.so   shadow nullok
account  required  pam_unix.so
You need to add a line so it looks like:

#%PAM-1.0
auth sufficient  pam_krb5.so use_first_pass  refresh_creds debug 
auth   required   pam_unix.so   shadow nullok
account   required  pam_unix.so
I used /etc/pam.d/system-auth as a reference. (I’m not sure the ‘debug’ part is needed.)

Since I couldn’t find anything online (this is one thing that google didn’t really know) that fixed things, I hope this is useful and saves a few hours or so for somebody somewhere.  The closest post I found didn’t seem to have a clear resolution and solution.

Update: If something gets borked and it says your user is unauthorized, you can set the admin user by editing the value in the <ACEDataUser> tag in /etc/vmware/hostd/authorization.xml .

Let me know if I’ve missed anything–all I can say is that this worked for me.