Purely static build of Ruby

[rcoder]

I'm trying to find out whether it's possible to build a completely
static Ruby binary under Linux. Basically, I'm trying to support IA-32
and Itanium systems with a single binary, and since IA-32 shared
objects can't be loaded by GNU ld on Itanium, I'm hoping that a static
binary could be a fix.

Has anyone managed to build a static Ruby binary with, at minimum, the
OpenSSL library included? I can get most of the way through the build
using the normal Ruby build infrastructure, but I keep getting
undefined reference errors for 'krb5_*' symbols. I'm sure I can force
the inclusion of the proper Kerberos libs, but before I bang my head
against this all day, I'd like to see what if any luck the veterans
around here have had with purely-static Ruby builds.
Thanks,

Lennon
rcoder.net

 

[Eric Schwartz]

I'm trying to find out whether it's possible to build a completely
static Ruby binary under Linux. Basically, I'm trying to support IA-32
and Itanium systems with a single binary, and since IA-32 shared
objects can't be loaded by GNU ld on Itanium, I'm hoping that a static
binary could be a fix.

Actually, ia-32 shared libraries can be loaded just fine on Itanium;
depending on your distribution, this may require installing some
compatibility libraries, but there's no problem there. Contact your
distribution vendor for more information. If you're using Debian,
contact the maintainer for the ia32-libs package.

-=Eric

 

[rcoder]

Eric Schwartz wrote:
[...]

Actually, ia-32 shared libraries can be loaded just fine on Itanium;
depending on your distribution, this may require installing some
compatibility libraries, but there's no problem there. Contact your
distribution vendor for more information. If you're using Debian,
contact the maintainer for the ia32-libs package.

There is somewhat of a problem with installing compatibility libraries,
since I'm trying to build a single binary package which can be
distributed to customers who may be running IA-32, or may be using
Itanium. We can't require that end users install other packages for
compatibility, since our stuff is supposed to work on a "bare" install
of Red Hat.

If nothing else, I can always just include IA-32 and Itanium .SO files,
and import the proper set at runtime, but I'm trying to minimize the
distributed file size. Unfortunately, total size is a big deal, because
I'm being pressured to use a language other than Ruby to build our tool
if I can't come up with a simple cross-platform support solution.

If distributing either the compatibility libraries, or versions of the
shared libs for both platforms, pushes the file size over that of a
static C++ or Java (via GCJ) binary, then one of my current key
arguments for Ruby (smaller distribution size due to .rb source files
being more compact than equivalent binaries) ceases to be true, and
higher forces may make me switch to a compiled language.

So, I'm just trying to get a feel for whether it's even possible to
build Ruby as purely-static binary with OpenSSL support. If not, then I
can look into distributing a bunch of compatibility libraries, but that
gets ugly quickly once you have at least two major libc versions and
two architectures to support.

Lennon
rcoder.net

 

[David Ross]

Eric Schwartz wrote:
[...]

Actually, ia-32 shared libraries can be loaded just fine on Itanium;
depending on your distribution, this may require installing some
compatibility libraries, but there's no problem there. Contact your
distribution vendor for more information. If you're using Debian,
contact the maintainer for the ia32-libs package.

There is somewhat of a problem with installing compatibility libraries,
since I'm trying to build a single binary package which can be
distributed to customers who may be running IA-32, or may be using
Itanium. We can't require that end users install other packages for
compatibility, since our stuff is supposed to work on a "bare" install
of Red Hat.

If nothing else, I can always just include IA-32 and Itanium .SO files,
and import the proper set at runtime, but I'm trying to minimize the
distributed file size. Unfortunately, total size is a big deal, because
I'm being pressured to use a language other than Ruby to build our tool
if I can't come up with a simple cross-platform support solution.

If distributing either the compatibility libraries, or versions of the
shared libs for both platforms, pushes the file size over that of a
static C++ or Java (via GCJ) binary, then one of my current key
arguments for Ruby (smaller distribution size due to .rb source files
being more compact than equivalent binaries) ceases to be true, and
higher forces may make me switch to a compiled language.

So, I'm just trying to get a feel for whether it's even possible to
build Ruby as purely-static binary with OpenSSL support. If not, then I
can look into distributing a bunch of compatibility libraries, but that
gets ugly quickly once you have at least two major libc versions and
two architectures to support.

Lennon
rcoder.net

Static ruby on Redhat requires you to download the static libraries of
the software you need. Most of the software is shared, the libraries are
shared. Few software in the OS are static, therefore you need *every*
static library you will need. Depending on which Redhat version you
have. Its easy to perform what you are needing to do.

--dross

yes I know redhat because I just now. Everyone just hush if they think
about jumping on my BSDism


Yes, it is possible on Redhat, but you need to download the rpms that have

 

[Phil Tomson]

I'm trying to find out whether it's possible to build a completely
static Ruby binary under Linux. Basically, I'm trying to support IA-32
and Itanium systems with a single binary, and since IA-32 shared
objects can't be loaded by GNU ld on Itanium, I'm hoping that a static
binary could be a fix.

Has anyone managed to build a static Ruby binary with, at minimum, the
OpenSSL library included? I can get most of the way through the build
using the normal Ruby build infrastructure, but I keep getting
undefined reference errors for 'krb5_*' symbols. I'm sure I can force
the inclusion of the proper Kerberos libs, but before I bang my head
against this all day, I'd like to see what if any luck the veterans
around here have had with purely-static Ruby builds.

Seems I recall you have to edit etc/Setup (in the Ruby source directory).
From the Ruby source README:

" 4. Remove comment mark(#) before the module names from ext/Setup (or
add module names if not present), if you want to link modules
statically.
"

and in fact, there is an openssl listed in etc/Setup:

....
#nkf
#pty
#openssl
#racc/cparse
#readline
....

Try removing the '#' and then do a './configure' and then 'make'.
I think that should work and should do what you want.

Phil

 

[Eric Schwartz]

There is somewhat of a problem with installing compatibility libraries,
since I'm trying to build a single binary package which can be
distributed to customers who may be running IA-32, or may be using
Itanium. We can't require that end users install other packages for
compatibility, since our stuff is supposed to work on a "bare" install
of Red Hat.

Well, that's your decision. I think if you plan to distribute only
one set of shared objects, then the best answer is to require the
customer to install the ia32 loader, which does ship with Red Hat
(though it's not, as you point out, installed by default). If they
have a legitimate copy of RHEL, then they will have the CDs, and your
install process can simply include the "install ia32 libs" step in
your installation instructions.

If nothing else, I can always just include IA-32 and Itanium .SO files,
and import the proper set at runtime, but I'm trying to minimize the
distributed file size. Unfortunately, total size is a big deal, because
I'm being pressured to use a language other than Ruby to build our tool
if I can't come up with a simple cross-platform support solution.

You're working on a 64-bit system, I'm afraid; size is just there.
OTOH, you'll have the same problem distributing 32-bit and 64-bit .so
libraries as well.

If distributing either the compatibility libraries,

You don't have to-- Red Hat has distributed them already; you just
need to take advantage of that. If the customer has Red Hat already,
they have the compatibility libraries; they just may have not
installed them.

or versions of the shared libs for both platforms, pushes the file
size over that of a static C++ or Java (via GCJ) binary, then one of
my current key arguments for Ruby (smaller distribution size due to
.rb source files being more compact than equivalent binaries) ceases
to be true, and higher forces may make me switch to a compiled
language.

I think Ruby is a great language, but if you're arguing based solely
on size of distributed code (and interpreter), then you may well
deserve to lose, I'm afraid. However, be sure to point out that
you'll have the exact same set of issues with compiled binaries as
with distributing Ruby, as far as increased size of libs for 64-bit
native and 32-bit native, or needing compatibility rpms, and that your
development process will be much slower.

So, I'm just trying to get a feel for whether it's even possible to
build Ruby as purely-static binary with OpenSSL support. If not, then I
can look into distributing a bunch of compatibility libraries, but that
gets ugly quickly once you have at least two major libc versions and
two architectures to support.

I completely understand your desire not to ship compatibility
libraries, but isn't that what the distro vendor is for? On RHEL3,
you should only need the glibc-2.3.2-*.i686.rpm package. All I can
suggest is that you (collective) re-evaluate your decision not to
require the customer to install rpms distributed with their Red Hat
installation. If you can clear that hurdle, then you should be free
and clear.

-=Eric

 

[Phil Tomson]

Well, that's your decision. I think if you plan to distribute only
one set of shared objects, then the best answer is to require the
customer to install the ia32 loader, which does ship with Red Hat
(though it's not, as you point out, installed by default). If they
have a legitimate copy of RHEL, then they will have the CDs, and your
install process can simply include the "install ia32 libs" step in
your installation instructions.

It shouldn't be necessary to go to these lengths as it should be fairly
trivial to create a static Ruby (see previous post). I happen to know the
situation that Lennon is in and I know that requiring the customer to
"install ia32 libs" won't fly.

I think Ruby is a great language, but if you're arguing based solely
on size of distributed code (and interpreter), then you may well
deserve to lose, I'm afraid.

Well, that's not the only argument, but it was one of the compelling ones:
The C++ version needed to be statically linked with libstdc++ in order to
run on Itanium. The binary (for a fairly trivial program) ended up being
about 12MB. Ruby & associated libs and scripts should weigh in under 3MB.

However, be sure to point out that
you'll have the exact same set of issues with compiled binaries as
with distributing Ruby, as far as increased size of libs for 64-bit
native and 32-bit native, or needing compatibility rpms, and that your
development process will be much slower.

Exactly (see above).

I completely understand your desire not to ship compatibility
libraries, but isn't that what the distro vendor is for? On RHEL3,
you should only need the glibc-2.3.2-*.i686.rpm package. All I can
suggest is that you (collective) re-evaluate your decision not to
require the customer to install rpms distributed with their Red Hat
installation. If you can clear that hurdle, then you should be free
and clear.

I really don't think it'll be necessary to ship compatibility libs.
Statically linking openssl and Ruby shouldn't be all that hard (see
previous post).

Phil

 

[Phil Tomson]

Has anyone managed to build a static Ruby binary with, at minimum, the
OpenSSL library included? I can get most of the way through the build
using the normal Ruby build infrastructure,

Ooops, sorry, that probably means that you did what I suggested in my
previous post...

but I keep getting
undefined reference errors for 'krb5_*' symbols. I'm sure I can force
the inclusion of the proper Kerberos libs, but before I bang my head
against this all day, I'd like to see what if any luck the veterans
around here have had with purely-static Ruby builds.

Don't you have to get the source to OpenSSL and compile that to a .a
first and then build Ruby with static linking for openssl? Seems like I
was playing with this several months ago. I thought it was successful, but
maybe not. I'm pretty sure this should be doable.

Also, I wonder if you need a different version of OpenSSL?

Phil

 

[rcoder]

At least with 1.8.2-preview2, the Ruby OpenSSL module won't compile
statically, even with the static libs for OpenSSL installed on the
system. That was the source of the 'krb5_*' symbol errors I mentioned
in the initial post.

I think that, in general, requiring the IA-32 compatibility RPMs *may*
be an option, but requires going outside the small group I'm working in
to additional product teams, since the tool I'm developing is an add-on
utility, not a standalone application.

In other words, the footprint and compatibility issues are key only
because we're supposed to add seamlessly onto the existing software,
without any major new dependencies or bloat.

Just to make things even more interesting, we not only have to support
Linux on IA-32 and Itanium with a single binary, we also have to
support Windows on both architectures with the same code base, and
provide GUI functionality on all of them.

 

[Phil Tomson]

At least with 1.8.2-preview2, the Ruby OpenSSL module won't compile
statically, even with the static libs for OpenSSL installed on the
system. That was the source of the 'krb5_*' symbol errors I mentioned
in the initial post.

It could be that you need a different version of OpenSSL. You might want
to check with whoever it is that makes the OpenSSL bindings for Ruby.

Perhaps you need libkrb5.a ?

Also, have you tried with 1.8.1 ?

I think that, in general, requiring the IA-32 compatibility RPMs *may*
be an option, but requires going outside the small group I'm working in
to additional product teams, since the tool I'm developing is an add-on
utility, not a standalone application.

Yeah, it's a pain.

In other words, the footprint and compatibility issues are key only
because we're supposed to add seamlessly onto the existing software,
without any major new dependencies or bloat.

Just to make things even more interesting, we not only have to support
Linux on IA-32 and Itanium with a single binary, we also have to
support Windows on both architectures with the same code base, and
provide GUI functionality on all of them.

Just when you get all of this working Intel will drop the Itanium ;-)

Actually, now that HP has dropped the Itanium it's only a matter of
time... (and HP was the instigator of the Itanium in the first place, so
Intel can't be too happy about this)


Phil

 

[Eric Schwartz]

Actually, now that HP has dropped the Itanium it's only a matter of
time... (and HP was the instigator of the Itanium in the first place, so
Intel can't be too happy about this)

Just a bit of quick rumor control: HP has NOT dropped the Itanium. We
are discontinuing production of two Itanium workstations, but we are
still committed to the IA64 platform, and are actively developing new
products based on it. If you have any further questions or concerns
relating to HP's support of Itanium, please contact your local HP
sales office-- they'll be happy to show you all sorts of kit, I'm
sure.

-=Eric

 

[Phil Tomson]

Just a bit of quick rumor control: HP has NOT dropped the Itanium. We
are discontinuing production of two Itanium workstations, but we are
still committed to the IA64 platform, and are actively developing new
products based on it. If you have any further questions or concerns
relating to HP's support of Itanium, please contact your local HP
sales office-- they'll be happy to show you all sorts of kit, I'm
sure.

I stand corrected...

....though I still suspect that Itanium's days are numbered.

BTW: What types of things are you using Ruby for at HP?

Phil

 

[Eric Schwartz]

...though I still suspect that Itanium's days are numbered.

I can assure you they are not. Further would probably get me a Severe
Talking-To, but I am quite certain Itanium is not going anywhere--
quite the opposite.

BTW: What types of things are you using Ruby for at HP?

I have built a test harness to support our integration testing of
various Linux distros on Itanium servers. We're currently redesigning
it, and the new version may not use Ruby, but I'm lobbying for it.

-=Eric