Re: [Chicken-users] Mac OS X static library names

[Peter Keller]

On Tue, May 15, 2007 at 01:51:20AM -0400, Brandon Van Every wrote:
> This resembles the case of PCRE.  We have our own code for this library.  To
> create a dynamic libchicken, first we create a static libpcre.  The static
> libpcre is compiled with shared flags, so that the .obj files are correct
> with respect to PIC and can be used in the dynamic libchicken.  Can this
> static-within-dynamic approach cause problems?  I did it this way because
> libpcre is used over and over again during the build, like 7 different
> times.  libpcre itself doesn't need to change, as it's only C code not
> Chicken Scheme code, it isn't subject to Chicken Scheme notions of being
> safe or unsafe, nor GUI vs. console.

Yeah, I think it will cause problems. The method by which the problems
appear is if the user also brings in a dynamic pcre library. From a
small inspection of libpcre and libchicken on my linux machine, I can
see some symbols would clash and the library might become unstable in
this situation. 

For example, the pcre_callout, pcre_free, pcre_malloc, and pcre_stack_free
symbols appear to not be text symbols, but instead function pointers
and they appear to be global. So, suppose version A of pcre have one
pcre_free() implementation function, and pcre version B had another. Then
depending on load order, you'd get one or the other and it might not
understand how to free the pointer given to it.

The example from the pcre sources is here:

192 /* PCRE is thread-clean and doesn't use any global variables in the normal
193 sense. However, it calls memory allocation and free functions via the two
194 indirections below, and it can optionally do callouts. These values can be
195 changed by the caller, but are shared between all threads. However, when
196 compiling for Virtual Pascal, things are done differently (see pcre.in). */
197 
198 #ifndef VPCOMPAT
199 void *(*pcre_malloc)(size_t) = malloc;
200 void  (*pcre_free)(void *) = free;
201 int   (*pcre_callout)(pcre_callout_block *) = NULL;
202 #endif

These could potentially get stomped on badly since libchicken would
initialize them and then the user's pcrelib would initialize them again
at a later time. The pcre data in memory now would be passed to alternate
versions and could bomb out of those indirections pointed to functions
which expected different structure formats.

There are a few ways to fix this, but they all sorta suck. :)

1. Rename all of the pcre functions & globally defined symbols that
chicken uses to something else that chicken uses internally. Most
binutils for various architecture provide objcopy, which could perform
this renaming for you.

2. Using objcopy, or possibly ld, depending on architecture, set to
private all of the pcre symbols to provate in libchicken.

3. Don't have an internal pcre library at all, and make configure bomb
out if it isn't available on the host machine. Optionally, distribute
your own pcre as a pure shared library, and force the user application
to link against it.

Even if the above are done, if it is at all possible that data pointers
may be gotten from libchicken's pcre and given to the user's pcre, or vice
versa, that will also be problematic. So, only if you can lock down the
movement of libchicken's internal pcre usage so its data never crosses over
to user applications (and vice versa) will the above two fixes even work.

> What I really wanted, was a way to build .obj files and then reuse them in
> different permutations of dynamic libraries.  I don't want the user to have
> to type -lpcre when using Chicken, it should just be -lchicken.  Autoconf
> supports so-called "convenience libraries" that allow you to turn everything
> into 1 final library.  CMake does not, you have to either fake it or
> recompile lotsa source files.  I chose to fake it, and I wonder if there's
> anything incorrect or hazardous about the fake.

Given what I've seen above, I think the fake is unstable.

Doesn't chicken already have a tool someon can run when linking with
chicken applications? Like csc -libs? Why can't you just add -lpcre there
if applicable? Then it'll just grab whatever the user wanted.

-pete