FAM, g++, escalation

Wednesday, 11. 7. 2007  –  Category: all, sw

The full context for this is just too shonky so it’s omitted here. FAM is a file monitoring system from SGI that some Linux distros link their courier-imapd against (the SGI OSS pages for it needs some love, it’s seemingly abandoned). The ‘drop-in’ FAM replacement, gamin, doesn’t provide enough FAMness to fly:

Nov  7 14:03:45 localhost imapd: Failed to connect to socket /tmp/fam--
Nov  7 14:03:45 localhost imapd: Failed to create cache file: maildirwatch (lemon@example.com)
Nov  7 14:03:45 localhost imapd: Error: Input/output error

So we’re left with either rebuilding Courier to not link against it (this is a non-starter, no SRPMs available for this version and I can’t wholesale replace it owing to “control panel” sillyness), or installing FAM itself. For which there are no RPMs, and the source RPMs break owing to a g++ change that occurred ages ago.


/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <x> header for the </x><x .h> header for C++ includes, or <iostream> instead of the deprecated header </iostream><iostream .h>. To disable this warning use -Wno-deprecated.
../include/BTree.h:240: error: expected constructor, destructor, or type conversion before 'BTree'
../include/BTree.h:352: error: expected constructor, destructor, or type conversion before 'BTree'
../include/BTree.h:408: error: expected constructor, destructor, or type conversion before 'BTree'
../include/BTree.h:503: error: expected constructor, destructor, or type conversion before 'BTree'
../include/BTree.h:561: error: expected constructor, destructor, or type conversion before 'BTree'
../include/BTree.h:591: error: expected constructor, destructor, or type conversion before 'BTree'
make[2]: *** [Client.lo] Error 1

</iostream></x>

Struggling to remember C++ resulted in this patch:

--- fam-2.6.10.orig/fam/SmallTable.h    2003-04-15 05:21:43.000000000 +0100
+++ fam-2.6.10/fam/SmallTable.h 2007-11-07 13:50:14.000000000 +0000
@@ -98,7 +98,7 @@
 }
 
 template &lt;class Tkey, class Tvalue&gt;
-SmallTable&lt;Tkey, Tvalue&gt;::Closure
+typename SmallTable&lt;Tkey, Tvalue&gt;::Closure
 SmallTable&lt;Tkey, Tvalue&gt;::position(const Tkey&amp; key) const
 {
     unsigned l = 0, r = n;
Only in fam-2.6.10/: fam-2.6.10.tar.gz
diff -ur fam-2.6.10.orig/include/BTree.h fam-2.6.10/include/BTree.h
--- fam-2.6.10.orig/include/BTree.h     2003-04-15 05:21:19.000000000 +0100
+++ fam-2.6.10/include/BTree.h  2007-11-07 13:55:15.000000000 +0000
@@ -236,7 +236,7 @@
 //  to the right and returns them.
 
 template &lt;class Key, class Value&gt;
-BTree&lt;Key, Value&gt;::Closure
+typename BTree&lt;Key, Value&gt;::Closure
 BTree&lt;Key, Value&gt;::Node::remove(unsigned j)
 {
     Key k = key[j];
@@ -348,7 +348,7 @@
 }
 
 template &lt;class Key, class Value&gt;
-BTree&lt;Key, Value&gt;::Closure
+typename BTree&lt;Key, Value&gt;::Closure
 BTree&lt;Key, Value&gt;::Node::next(const Key&amp; pred) const
 {
     if (!this)
@@ -404,7 +404,7 @@
 //  nodes as necessary on the way back.
 
 template &lt;class Key, class Value&gt;
-BTree&lt;Key, Value&gt;::Closure
+typename BTree&lt;Key, Value&gt;::Closure
 BTree&lt;Key, Value&gt;::insert(Node *p, const Key&amp; key, const Value&amp; value)
 {
     if (!p) return Closure(key, value, NULL);
@@ -499,7 +499,7 @@
 //  Returns UNDER if node p is too small afterward, OK otherwise.
 
 template &lt;class Key, class Value&gt;
-BTree&lt;Key, Value&gt;::Status
+typename BTree&lt;Key, Value&gt;::Status
 BTree&lt;Key, Value&gt;::underflow(Node *p, unsigned i)
 {
     assert(p);
@@ -557,7 +557,7 @@
 
 
 template &lt;class Key, class Value&gt;
-BTree&lt;Key, Value&gt;::Closure
+typename BTree&lt;Key, Value&gt;::Closure
 BTree&lt;Key, Value&gt;::remove_rightmost(Node *p)
 {
     int i = p-&gt;n;
@@ -587,7 +587,7 @@
 //  back up.
 
 template &lt;class Key, class Value&gt;
-BTree&lt;Key, Value&gt;::Status
+typename BTree&lt;Key, Value&gt;::Status
 BTree&lt;Key, Value&gt;::remove(Node *p, const Key&amp; key)
 {
     if (!p)
diff -ur fam-2.6.10.orig/libfam/Client.c++ fam-2.6.10/libfam/Client.c++
--- fam-2.6.10.orig/libfam/Client.c++   2003-04-15 05:21:25.000000000 +0100
+++ fam-2.6.10/libfam/Client.c++        2007-11-07 13:24:28.000000000 +0000
@@ -34,7 +34,7 @@
 #include &lt;syslog.h&gt;
 #include &lt;errno.h&gt;
 
-#include &lt;iostream.h&gt;
+#include &lt;iostream&gt;
 
 #include &quot;fam.h&quot;
 #include &quot;Client.h&quot;

Well, that was fun.

No, I’m building JDK *elsewhere*

Tuesday, 10. 2. 2007  –  Category: all, sw, vague

Lousy licensing click throughs:

[root@two /usr/ports-work/distfiles ] 0 # curl --referer http://www.eyesbeyond.com/freebsddom/java/JDK15JRLConfirm.html -v -d"patchset=6" -d "accept=ACCEPT" -O http://www.eyesbeyond.com/freebsddom/java/download_patchset15_jrl.cgi

FreeBSD, ruby 1.8.2, libpthreads

Wednesday, 09. 12. 2007  –  Category: all, vague

Anecdotally people recommend not using libpthread with Ruby on FreeBSD. I’ve duly always told the port to not use it, but ldd has always shown that it’s linked. autoconf insists on configuring the build with it, despite the --disable-pthread flag.

My long time response to this was *shrug* – Ruby seems fine. Until a weird production problem, unrepeatable on stage, where certain Rails stacks (those running in development mode to expose some aspect of the Globalize plugin to translators) crashed badly, with SIGBUS or SIGILL.

I came across this script:

$ ruby -e 'def d(x); p x; d x+1; end; d 0'

which exposes the problem perfectly. With a pthread’d Ruby it dumps core, with a no-thread Ruby it gracefully raises stack level too deep (SystemStackError)

More here

Update:

I discussed this on the FreeBSD ports list, discussion here.

Seems like the problem is on its way out.

« Older Entries
Newer Entries »