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