<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9">
</HEAD>
<BODY>
On Thu, 2003-12-18 at 13:17, Tingle, Alex wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>I plan to build omniORB binaries for a variety of Unix platforms, so that
Duncan can upload them to Sourceforge. How does everyone think I should
package the binaries?
1. The very simple option: Just follow the normal build procedure.
mkdir build; cd build
../configure
make; make veryclean
cd ../..
tar cvfz omniORB-binaries.tgz omni
Originally, Duncan & I agreed that I would build the binaries as normal and
then just tar up the omni directory again. Users could then just use the
normal `make install'. However once I started to do that, it occurred to me
that it wouldn't necessary be much use to anyone but me.
`../configure' finds a copy of `install' that doesn't necessarily exist on
someone else's box. So `make install' is likely to fail.
Would the result be useful to people on it's own, even though `make install'
might not work?
2. Do a build install, and then tar up the install directory.
mkdir /tmp/omniORB-binaries
mkdir build; cd build
../configure --prefix=/tmp/omniORB-binaries
make; make install
cd /tmp
tar cvfz omniORB-binaries.tgz omniORB-binaries
This would give people a pre-installed version of omniORB, but without any
of the documentation or source code. They could untar it into a home
directory or even just copy the files into /usr/local or wherever. Would
this be useful?
3. Something else?
Perhaps a new configure script, designed to find just basic things like
`install'. I'm open to suggestions.
Finally, there is the issue of non-omniORB libraries. If these binaries are
to be useful for people without C++ compilers installed, they will need the
C++ runtime libraries. It's usually OK to distribute the runtime libraries
for commercial compilers, but should I bother? Put another way: is a binary
distribution any use without the C++ runtime libraries?
</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
Isn't there some libtool black magick that allows for selective static/dynamic linking ?<BR>
What I mean is cut the stdc++ lib deps for the omniORB shared libraries. At least for Linux :-).<BR>
<BR>
Why ? Well, I develop on RH9/Fedora C1 and the deployment machines are older RH systems,<BR>
like 7.2 and 7.3. While a plain C program can be copied in binary form from FC1 to RH 7.2,<BR>
a C++ one cannot (RH7.2 doesn't have libstdc++.so.5); yes, I could build all my required libraries<BR>
with all of the three (yes, three) versions of g++ (2.96, 3.2.3 and 3.3.2), this would require quite<BR>
an amount of effort and management.<BR>
<BR>
So, a possible and probable use would be distributing omniORB client programs in binary form,<BR>
without requiring anything special on the machine except the orb configuration file (since <BR>
omniORB libraries would have come from a rpm package or something similar).<BR>
<BR>
Regards,
<PRE><TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>--
Radu-Adrian Popescu
CSA, DBA, Developer
Aldratech Ltd.
+40213212243</PRE>
</TD>
</TR>
</TABLE>
</PRE>
</BODY>
</HTML>