This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: shared object of CDL.
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