Re: mailparse extension

Wez Furlong wrote: > I said no, but I am thinking of making a dependency on the new mbstring > extension to utilize the extensive encoding conversion code it provides. > > So, it'll be more of an internal dependency... oops, we are going to have internal extension dependencies beside those to ext/standard? i was just htinking of ways to isolate extensions from each other on the linker level by reducing exported symbols from extensions to the bare minimum (to avoid duplicate symbol troubles like we now have with ext/mnogosearch and ext/standard) i think we should find a standard way to: - define extension interdependencies on the autoconf level (both mandatory and optional) - ensure mandatory dependencies are fullfilled during configure - restrict symbols exported by the extensions intermideate object files (.so for shared extension or .a archive for builtin ones) for shared extensions this is easy as we can use the same libtool mechanism as we already have for --enable-versioning in sapi/apxs for builtin extensions we will most likely have to change the generation of the intermideate libraries that contain the extensions object code a bit i'm especially thinking about using ld partial linking (option '-r') to achieve this, but i'm not deep enough into libtool and the current built system to have a working solution Any comments on this? (Sascha?) -- Hartmut Holzgraefe hartmut@six.de http://www.six.de +49-711-99091-77