On 5/14/07, Peter Keller <[EMAIL PROTECTED]> wrote:
Example 1 --------- 1. You statically link the openssl libraries into your application because you can't guarantee that the target platform will have one. So, you move your executable to a machine, start it up, and here is what could happen 2. The program loads the executable, the initializers are run, now some global memory space is initialized for openssl. 3. The program decides to call getpwnam() later, which the administrator happens to have configured to use LDAP with an SSL backend. 4. The lazy load of the ldap resolver, which then brings in the ssl library cause the dynamic ssl library initialization routines to be run again. If the two version of the libraries were the same, then depending when this happens there might be no effect. If they are different versions, either of the two ssl libraries will get confused and probably segfault. 5. This is because the global variable space for both the static version of the library and the dynamic version (probably) resolve to the same symbol names, so they get trashed in the process space.
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. 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. Cheers, Brandon Van Every
_______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
