This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: shared object of CDL.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]