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 _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
