P
Paul Sander
I want to build ruby in a cross-compile mode in which the results of a comp=
ilation are installed in some arbitrary directory, then are placed in an ar=
chive, then are unpacked from the archive in their final location on a larg=
e number of machines. The --prefix option of the configure script can be u=
sed to change the final destination, but it is overloaded to be both the co=
mpile-time destination and the runtime search path. In my case, these are =
distinct. Furthermore, the build must run without root permission (and I w=
ould not want to corrupt an existing installation anyway), the final locati=
on requires root permission for writing, and the result of "make install" i=
n my sandbox will not be available on most of the machines on which the arc=
hive is installed.
To illustrate the problem, I run a build as normal user in /sandbox/ruby/sr=
c, and install the results in the /sandbox/ruby/install tree where the bin,=
lib, share, and other directories are created. I run this procedure:
mkdir -p /sandbox/ruby/install
cd /sandbox/ruby/src
/configure --prefix=3D/sandbox/ruby/install
make
make install
cd /sandbox/ruby/install
find . -print | cpio -o > /sandbox/ruby.cpio
Now I install the archive on the target machine:
scp /sandbox/ruby.cpio remote:~/ruby.cpio
ssh remote
su
mkdir -p /usr/foo
( cd /usr/foo && cpio -id ) < ruby.cpio
This is a simplified illustration of the method; the actual procedure is mo=
re complicated than this. The src tree of the sandbox is actually read-onl=
y so the build results are actually deposited elsewhere. Additionally, rub=
y is only one of several products built in this sandbox, and the whole thin=
g is wrapped in a complicated make-based procedure. There may even come a =
time when I must build ruby with an actual cross-compiler targeting a diffe=
rent architecture than the build machine, for an embedded system that has n=
o ability to develop software. But the above presents the relevant aspects=
of the method.
The issue is that programs like gem have hard-coded into them the location =
into which the "make install" step deposited them. If you run "gem environ=
ment", you see that it expects the location of the ruby executable to be /s=
andbox/ruby/install/bin/ruby, and the search paths are similarly set. Note=
that the sandbox is not available on the remote machine.
Granting permission to install into /usr/foo on the build machine is not an=
option because it's a production environment and we can't even temporarily=
corrupt that location while other procedures are running. And we don't wa=
nt to copy the world into a chroot environment for the purpose of building =
this sandbox. (That would not work anyway because ruby isn't the only thin=
g that gets built in that sandbox, and other things require an intact /usr/=
foo tree.)
So, how do others build and operate ruby in an environment like this?
P.S. Having a tool invoke a prior version of itself to build itself, as is=
done with ruby 1.9.2, violates a fundamental tenet of release engineering:=
You shall not unwind history to reproduce yourself. I see from the archi=
ves of this list that others have also reported this issue. When will this=
oversight be fixed?
This email and any attachments may contain confidential and privileged mate=
rial for the sole use of the intended recipient. Any review, copying, or di=
stribution of this email (or any attachments) by others is prohibited. If y=
ou are not the intended recipient, please contact the sender immediately an=
d permanently delete this email and any attachments. No employee or agent =
of TiVo Inc. is authorized to conclude any binding agreement on behalf of T=
iVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a=
signed written agreement.
ilation are installed in some arbitrary directory, then are placed in an ar=
chive, then are unpacked from the archive in their final location on a larg=
e number of machines. The --prefix option of the configure script can be u=
sed to change the final destination, but it is overloaded to be both the co=
mpile-time destination and the runtime search path. In my case, these are =
distinct. Furthermore, the build must run without root permission (and I w=
ould not want to corrupt an existing installation anyway), the final locati=
on requires root permission for writing, and the result of "make install" i=
n my sandbox will not be available on most of the machines on which the arc=
hive is installed.
To illustrate the problem, I run a build as normal user in /sandbox/ruby/sr=
c, and install the results in the /sandbox/ruby/install tree where the bin,=
lib, share, and other directories are created. I run this procedure:
mkdir -p /sandbox/ruby/install
cd /sandbox/ruby/src
/configure --prefix=3D/sandbox/ruby/install
make
make install
cd /sandbox/ruby/install
find . -print | cpio -o > /sandbox/ruby.cpio
Now I install the archive on the target machine:
scp /sandbox/ruby.cpio remote:~/ruby.cpio
ssh remote
su
mkdir -p /usr/foo
( cd /usr/foo && cpio -id ) < ruby.cpio
This is a simplified illustration of the method; the actual procedure is mo=
re complicated than this. The src tree of the sandbox is actually read-onl=
y so the build results are actually deposited elsewhere. Additionally, rub=
y is only one of several products built in this sandbox, and the whole thin=
g is wrapped in a complicated make-based procedure. There may even come a =
time when I must build ruby with an actual cross-compiler targeting a diffe=
rent architecture than the build machine, for an embedded system that has n=
o ability to develop software. But the above presents the relevant aspects=
of the method.
The issue is that programs like gem have hard-coded into them the location =
into which the "make install" step deposited them. If you run "gem environ=
ment", you see that it expects the location of the ruby executable to be /s=
andbox/ruby/install/bin/ruby, and the search paths are similarly set. Note=
that the sandbox is not available on the remote machine.
Granting permission to install into /usr/foo on the build machine is not an=
option because it's a production environment and we can't even temporarily=
corrupt that location while other procedures are running. And we don't wa=
nt to copy the world into a chroot environment for the purpose of building =
this sandbox. (That would not work anyway because ruby isn't the only thin=
g that gets built in that sandbox, and other things require an intact /usr/=
foo tree.)
So, how do others build and operate ruby in an environment like this?
P.S. Having a tool invoke a prior version of itself to build itself, as is=
done with ruby 1.9.2, violates a fundamental tenet of release engineering:=
You shall not unwind history to reproduce yourself. I see from the archi=
ves of this list that others have also reported this issue. When will this=
oversight be fixed?
This email and any attachments may contain confidential and privileged mate=
rial for the sole use of the intended recipient. Any review, copying, or di=
stribution of this email (or any attachments) by others is prohibited. If y=
ou are not the intended recipient, please contact the sender immediately an=
d permanently delete this email and any attachments. No employee or agent =
of TiVo Inc. is authorized to conclude any binding agreement on behalf of T=
iVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a=
signed written agreement.
