This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: shared object of CDL.
- From: Bart Veer <bartv at ecoscentric dot com>
- To: taru at debian dot org
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Fri, 9 Aug 2002 10:27:37 +0100 (BST)
- Subject: Re: [ECOS] shared object of CDL.
- References: <xe07kj1hhyf.wl@station63.tokyo.redhat.com>
- Reply-to: bartv at ecoscentric dot com
>>>>> "Masato" == Masato Taruishi <taru@debian.org> writes:
Masato> The attached patch will create a shared object of CDL and
Masato> ecosconfig will use it. The version number of this shared object
Masato> is now libcdl.so.0.0.0 and soname is libcdl.0. It can be used by
Masato> sciprt languages such as perl, python, and ruby by creating
Masato> a libcdl binding for the script language (of course, there is no
Masato> binding yet).
Masato> In addition, the patch includes a support of concurrent make
Masato> to speed up compile time for SMP machines.
Masato> I remove diffs for auto-generated files such as configure and
Masato> Makefile.in etc, even though the repository includes these files
Masato> because it increases the size of this mail. So you need to invoke
Masato> the following command to enable this feature:
Masato> * libtoolize
Masato> * aclocal
Masato> * automake
Masato> * autoconf
Masato> in the following directory:
Masato> ecos/host/libcdl, ecos/host/infra and
Masato> ecos/host/tools/configtool/standalone/common/
Masato> I don't check this patch on Windows.
I am not convinced I want this in the current sources. Turning libcdl
into a shared library is of little benefit unless there are a
significant number of applications using it, and right now the only
such applications are ecosconfig and the GUI configuration tool.
Keeping libcdl as a static library means that, for binary releases,
there is one less file to ship and install. It also means that you do
not have to install anything in a system directory such as /usr/lib,
or modify ld.so.conf
More importantly, it adds a possible source of portability problems. I
am sure that using libtool for libcdl will work fine for various Linux
systems. However I know that various people also use the host-side
tools on other Unix systems, e.g. Solaris. For Windows systems, it is
currently required that the host-side code builds under cygwin with
gcc, and unfortunately also with Visual C++ because of the
requirements of the GUI configuration tool (although right now I can
no longer test building with VC++, only under Linux or cygwin).
A while back I did investigate using libtool to turn libcdl into a Tcl
dynamically loadable extension. IIRC at the time there were problems
with C++ code such as libcdl, on some types of system anyway,
related to initialization and static constructors.
Is there a specific reason why you want libcdl to become a shared
object? If not, my preference would be to keep it as a simple static
library for now, in the interest of portability.
Bart
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss