At 20:57 01.09.2002, Brian France wrote: >At 8:47 PM +0200 9/1/02, Marcus Börger wrote: >>At 20:38 01.09.2002, Brian France wrote: >>>At 6:29 PM +0100 9/1/02, James Cox wrote: >>>>Where is your patch? >>> >>>The patch basically renames php_treat_data to php_treat_data_default, >>>creates a function pointer called php_treat_data that is defaulted to >>>php_treat_data_default, removes all mbstrings references in php_main.h >>>and makes mbstring.c change the php_treat_data to mbstr_treat_data in >>>the INIT function and restores its value in SHUTDOWN. >>> >>>This allows us to only load the mbstrings extension on the machines that >>>need it, which is a very small percentage of our over all server count. >>> >>>This patch is based off of the 4.2.2 release and there have been changes >>>in CVS to the exif extension that may need mbstring to be static because >>>it is expecting mbstr_treat_data to be handling the php_treat_data stuff. >> >>exif uses mbstring since 4.3 so 4.2.3 would be no problem > >Which means that my fix would fix it for 4.2.x releases and then it breaks >again in 4.3. Break, I mean mbstring can not be built as a shared extension.
I meant you do not have to care about exif in 4.2.3 and it does not break thinks in 4.3 since availability is checked. The only thing is that there is be a lack in documentation for the case that mbstring is a shared module. >I know there are things the exif needs from mbstring and there is no way >to have exif link against mbstring or require it. But couldn't exif check >to see if mbstring is loaded (or built in) and if not print a warning that >some of its functionality may not work correctly unless mbstring is loaded >(or built in)? I think we could, especially since 4.3 features are not sipulated yet. marcus -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
