>> Your point is very interesting. However, if you believe this issue >> merits more extended discussion, I would recommend you open up a new RT >> ticket, perhaps in the [RFC] category (or [RFP] or whatever it's called). >> >> I would like to keep the discussion in *this* RT focused on the issues >> Carl raised with respect to config step auto::pcre.
We need to know what's happening. I see two possibilities: - The pcre library detected by the configure probe is static. Don't know what to do in that case, with static linkage the dynamic symbols needed for NCI may not be available, some static support for the library inside parrot may be required. - The library is dynamic but cannot be located at runtime. This can happen if is located in a place the dynamic linker does not search. In that case, the symbols can be found in the main process (at least in Linux) if the dynamic loading attempt fails. We can check this (in Linux, again), by looking for pcre in the output of: ldd parrot We must know what pcre library files are available, where are located, and if this place is searched by the dynamic linking at runtime (in Linux, listed in ldconfig configuration files). The problem can be just the lack of a libpcre.so symbolic link to libpcre.so.some_version_number Note that in the dynamic case, if the library can be found by the dynamic runtime linker we don't need any configure support at all. You can build --without-pcre and have pcre available anyway. -- Salu2
