[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Purely static build of Ruby

rcoder@gmail.com

9/29/2004 5:59:00 PM

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

12 Answers

Eric Schwartz

9/29/2004 8:49:00 PM

0

"rcoder@gmail.com" <rcoder@gmail.com> writes:
> 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
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.

rcoder@gmail.com

9/29/2004 9:39:00 PM

0

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

9/29/2004 9:58:00 PM

0

rcoder@gmail.com wrote:

>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


ptkwt

9/29/2004 10:39:00 PM

0

In article <1096480722.300929.155700@k17g2000odb.googlegroups.com>,
rcoder@gmail.com <rcoder@gmail.com> wrote:
>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

9/29/2004 10:55:00 PM

0

"rcoder@gmail.com" <rcoder@gmail.com> writes:
> 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
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.

ptkwt

9/29/2004 11:15:00 PM

0

In article <eto7jqc65zj.fsf@wilson.emschwar>,
Eric Schwartz <emschwar@pobox.com> wrote:
>"rcoder@gmail.com" <rcoder@gmail.com> writes:
>> 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.

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.

>
>> 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.

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).

>
>> 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.

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

ptkwt

9/29/2004 11:39:00 PM

0

In article <1096480722.300929.155700@k17g2000odb.googlegroups.com>,
rcoder@gmail.com <rcoder@gmail.com> wrote:
>
>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@gmail.com

9/29/2004 11:48:00 PM

0

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.

ptkwt

9/30/2004 12:10:00 AM

0

In article <1096501697.454462.174890@k26g2000oda.googlegroups.com>,
rcoder@gmail.com <rcoder@gmail.com> wrote:
>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

9/30/2004 12:45:00 AM

0

ptkwt@aracnet.com (Phil Tomson) writes:
> 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
--
Eric Schwartz email: emschwar@hp.com
Hewlett-Packard Company Phone: +1 970 898 7443
Linux and Open Source Lab (LOSL)