[ECOS] shared object of CDL.

[Masato Taruishi]

At Fri,  9 Aug 2002 10:27:37 +0100 (BST),
Bart Veer wrote:

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

I believe it's an enough reason that there are 2 applications. For
example, I've already gotten the result that the total disk size of
ecosconfig and configtool are smaller than static version.

here is shared version:

  419872 2002-08-08 06:40:01 ./usr/bin/ecosconfig-bin
10066304 2002-08-08 06:40:01 ./usr/bin/configtool
 3617600 2002-08-08 06:40:01 ./usr/lib/libcdl.so.0.0.0

and here is static version:

 2830800 2002-07-20 11:46:11 ./usr/bin/ecosconfig-bin
13469936 2002-07-20 11:46:11 ./usr/bin/configtool

(These are binaries for ia64/linux)

See http://buildd.debian.org/build.php?&pkg=ecos for more info.

> 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

You can do this with the following:

./configure --disable-shared

Currently, I'm afraid that there is no way to create a shared library
even if I want it.
 
> 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).

IIRC, libtool is what provides a compatibility about shared libraries on
several systems. I've watched some libtool-aware programs run on Solaris
, HP-UX and cygwin. There may be a system that libtool doesn't support,
but I guess that the number of such systems is less than one which libtool
supports, and if we face the system we can add the support code to libtool.

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

Specify --disable-shared on such systems by hand?
Or check host_{cpu,vendor,os} in configure.in and disable it forcibly
if the system has problems.

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

Because I want CDL plugin, or extented module, for python. In order
to realize this, I believe it's a better way to create a shared library.

Thanks for your excellent works to the host-side tools.

-- 
Debian Project http://debian.org/ - Masato Taruishi <taru@debian.org>

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss