Re: [Confuse-devel] Fwd: Small patches for const/shared

[Nathan Phillip Brink]

On Fri, Oct 08, 2010 at 04:18:55PM +0000, Jens Rehsack wrote:
> >>> The second patch allows users to enable libconfuse' shared library target.
> >>> I don't see any reason to prevent it at all. Linking compatibility can be 
> >>> solved
> >>> with appropriate library version numbers
> >>> (http://www.lrde.epita.fr/~adl/autotools.html).
> >
> > Even with AC_DISABLE_SHARED, one may specify --enable-shared to
> > ./configure to get a shared libconfuse library. Thus, this patch isn't
> > necessary for users or distributions to compile shared libraries for
> > libconfuse. (for example, Gentoo passes --enable-shared to confuse's
> > ./configure script).
> 
> I tried that first (Ubuntu 10.04 LTS), and it didn't work.

I also just tried that on ubunto-10.04LTS:

$ http://savannah.nongnu.org/download/confuse/confuse-2.7.tar.gz
$ tar -xvzf confuse-2.7.tar.gz
$ cd confuse-2.7
$ ./configure --prefix=/usr --enable-shared
$ mkdir _destdir
$ make DESTDIR="${PWD}"/_destdir install -j
$ find _destdir -name '*.so'
_destdir/usr/lib/libconfuse.so

address@hidden:~/confuse-2.7$ cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.1 LTS"


I get a shared library with no problem ;-).

> > However, I also would like to see shared objects enabled by default as
> > well. And, yes, if the ABI changes between releases, I hope to make
> > sure that the libtool's -version-info flag is set properly. However, I
> > think that moving a function's argument from being non-const to being
> > const doesn't affect the ABI...
> 
> Not a C ABI ;)
> A C++ ABI would be affected.

If my understanding is correct, the C and C++ ABI are identical for
confuse. Nothing special is done in confuse.h for C++ except the
normal extern "C". A C++ program would be accessing and using the same
symbols as a C program.

The idea that ABI changes when moving from ``int a(const char *b);''
to ``int a(char *b);'' is that in the first case, the compiler and
programmer will know that the string passed as argument b will not be
modified. Thus, certain optimizations could be made such that a
program compiled against the ``int a(const char *b)'' definition would
be incompatible after the system library moved to having a() edit the
string b. But the reverse change should not encounter this problem.

-- 
binki

Look out for missing apostrophes!

pgp_x9aPzvFYd.pgp
Description: PGP signature