Chicken-egg problem in building from sources


I can’t remember how many times I built SciDB from sources and it is never painless. This time I got a clean machine (Centos 6.5) and tried to follow the steps verbatim. Long story short: If I make locally only using staging directory, it works ok. For cluster deployment, I need to use


which is great, except that install wipes everything from /opt/scidb/14.3, including 3rdparty which has boost in it, because that’s where the prepare toolchain stuff put it.

For the record, “./ make” finished successfully (I think).
"./ install" complained about missing boost


  1. prepare toolchain puts boost into /opt/scidb/14.3/3rdparty
  2. setup # does its stuff
  3. make # does it and finishes well
  4. install # wants to clear everything from /opt/scidb/14.3
    when I don’t agree, it stops
    when I do agree, it cleans out /opt/scidb/14.3 INCLUDING 3rd PARTY STUFF*
    and then it complains about missing boost

There is a hole in the bucket, dear Liza …
First problem show up when it tries building (why, didn’t make already make it?) Arena.cpp.o
boost/utility.hpp missing, No duh, install wiped out 3rdparty…

So, I probably am missing some simple detail, and once Alex or Paul set me straight I shall probably feel very embarrassed.

Help, please!



Assume you are following the 14.3 build instructions downloaded from
Exactly the same chicken-egg problem is described in Section 6.1:

For local development, you have the flexibility of pointing SCIDB_INSTALL_PATH at an arbitrary
location (the default is <dev_dir>/scidbtrunk/stage/install), but it must be different from
/opt/scidb/$SCIDB_VER. The reason is as follows. A subsequent local-development step, ./
install, will wipe out all content in SCIDB_INSTALL_PATH. But /opt/scidb/$SCIDB_VER cannot be
wiped out, because it contains useful 3rd-party packages (that was installed there using a previous
prepare_toolchain step).
Note: For cluster development you must provide SCIDB_INSTALL_PATH and it must point to

So make a choice. To install to /opt/scidb/14.3, use the ‘cluster development’ method; to install to somewhere else, use the ‘local development’ method.


Does this mean that localhost is not a valid target for setup if I choose the cluster development method?
If the chrooted environment is supposed to take care of having the real /opt/scidb/14.3 be preserved while the install/build wipes out the one in the chrooted universe, then for some reason it is messed up on my test system.

Is that the direction (what’s wrong with my chroot) in which I should look?

Or… can I do a local install and then replicate /opt/scidb/14.3 on the other nodes if I don’t cross mount /opt/scidb?

Still confused …
Mind you, the normal install works just fine, I just need to build a sourcetree that works so we can experiment with UDOs and that test system will be up and down several times daily if not hourly…



‘localhost’ is evil sometimes. The whole build instruction mentions . So…

chrooted environment has nothing to do with preserving /opt/scidb/14.3.

To clear your doubt, ‘local development’ and ‘cluster development’ sections are mutually exclusive. In your case, you should completely igore all sections on ‘local development’. For instance, the step ‘ install’ that wipes /opt/scidb/14.3 only appears in a ‘local development’ section 6.3.

And no, don’t replicate /opt/scidb/14.3 from a local install to the other nodes. The instructions in section 6.4 show you how you can specify multiple IP addresses in the same ‘ scidb_install’ command. Use that.


Thanks for clearing that up.

Can I still use cluster development method if my source and target machines are the same?
In other words, I want this test machine to faithfully reproduce every aspect of the working cluster in as many aspects as possible,
and this includes the tree of necessary files in place. Or am I being silly for thinking this?

And if I can use the cluster method on a single machine, what should I use as target ?
Since, as you say, “localhost is evil sometimes,” should I use, the eth0 ip address or the IB interface 10.0.0.x address?
Thanks again,


BTW: I am using while I wait and I got as far as make which seems to have completed.
Skipped 6.3, it’s local.

But I am running into problems with 6.4, ./ make_packages /tmp/pcakages

[code][scidb@localhost scidbtrunk]$ ./ make_packages /tmp/packages/
WARNING: about to delete all contents of /tmp/packages/* [y]|n: y
Source path: /devdir/scidbtrunk
Script common path: /devdir/scidbtrunk/deployment/common
Build path: /devdir/scidbtrunk/stage/build
SciDB version: 14.3
Executing: build_fast /tmp/packages/

/devdir/scidbtrunk /devdir/scidbtrunk/stage/build
Extracting version
Extracting revision
Version: 14.3.0
Preparing result dir
Cleaning old files from /devdir/scidbtrunk/stage/build
Preparing sources from /devdir/scidbtrunk to /devdir/scidbtrunk/stage/build
Building binary packages insource
error: line 11: Empty tag: Release:
rpmbuild failed
./ ERROR: Command make_packages failed: Abnormal return code: 1 on command [’/devdir/scidbtrunk/deployment/’, ‘build_fast’, ‘/tmp/packages/’]
Make sure commands setup,make,install,start are performed (in that order) before stop,stopForce,tests
[scidb@localhost scidbtrunk]$[/code]


Yes you can use the ‘cluster’ method on a cluster of a single machine; further, the machine can also be the dev box. We’ll make the point clearer in the 14.7 build instructions.
As for the target hostIP, both the eth0 IP and the IB address should work.


I just redid everything from scratch using a real IP address (not
Everything worked up until make_packages which failed again with same messages as in my previous post.

Any ideas?



If I look at the make_packages script, it seems like REVISION is undefined when the source does not come from git or svn.
And in our case, it doesn’t since we just downloaded the tarball from this forum.

So I try exporting REVISION=FOO before the make_pcakages and that seemed to do the trick at least for building packages and installing…
Few more steps left…


Ok, so it worked. The only thing the package build process did not do well is patch the REVISION in case there was no git or svn history of the sources.
The point may be moot, as we are waiting for 14.7’s release and we’ll do this whole thing again, yes?

Cheers, George


I just figured it out. And when I came here to tell you… you already figured out yourself. :smile: I’m impressed.
Yes it’s a mistake on our side. In utils/, REVISION is not set correctly. (We missed it before because our source code tree has .svn in it). The workaround is to set REVISION=7383 (for 14.3) either in the file or externally.
In 14.7 the problem will be fixed.