Re: [PHP-DEV] Re: #20755 [Opn->Ver]: exif relocation error)

[Moriyoshi Koizumi]

Hi,

Jani Taskinen <[EMAIL PROTECTED]> wrote:

> On Tue, 3 Dec 2002, Moriyoshi Koizumi wrote:
> 
> >--snip
> >> If you compile mbstring as static module, you can workaround this
> >> error. It's not very good idea to enable it anyway..
> >
> >I'm wondering why you referred to enabling mbstring as no good idea
> >in this report. I believe the problem has been properly avoided, or am I 
> >missing something?
> 
> Maybe I just assumed something, but I think this person really 
> doesn't even need it. :) That's why I also noted about enabling 
> only extensions that he actually needs.
> 
> The biggest concern about mbstring for me is that it changes some core
> functions behaviour. I haven't followed the development of mbstring 
> closely so I might be wrong here..just that one major bug caused by 
> that duplication of code (for post vars parsing) gives me creeps. :)
> 
> As long as it's separate from core PHP, I will never suggest anybody
> to use it.
>

I could understand the reason of your severe glance at the module, but 
please, please stop blaming mbstring for the reported bugs which you might 
suppose don't appear to be fixed in a moment :P  Most of them are totally 
irrelevant.

BTW that most infamous bug was caused by a carelessness rather than the 
duplication of codes.

> >> For the mbstring authors: You should decide whether or not to allow
> >> external usage of these functions (ie. in other extensions) or disable
> >> the building of this extension as shared altogether..
> >
> >What decision? We actually externalise some functions just for that 
> >purpose. Perhaps did you mean integration of mbstring into core part?
> 
> Yes. But mbstring is not the only extension having the same problem
> when compiled as shared. At least iconv, openssl, pcre and gd also 
> have some external parts used outside them. e.g. All the extensions
> and core parts using those externalized functions in mbstring must
> now put these around the parts using those:
> 
> #ifndef COMPILE_DL_MBSTRING
> #endif
> 
> This is done in some places, but not everywhere, like shown by 
> the bug report. 
> 
> The same problem is also with PCRE and GD extensions. 
> One solution would be to make at least PCRE and MBstring always
> static, ie. disallow building them as shared. Or move them
> under ext/standard..
> 
> With openssl and iconv it's a bit different, the same libraries
> are required by other extensions. This problem could be solved by
> linking the core PHP always with those, even when compiling openssl
> or iconv as shared extensions.

I see the issue around the shared extensions too. We definitely need more 
clever dynamic loading mechanism as Yasuo mentioned.
I don't think mbstring needs to be built static as long as it exists as an 
extension.

> >BTW we are now working on a new mbstring API specification so that other 
> >extension authors can use the functions with more convenience and in no 
> >more doubt about their usage. If we should treat it in a special way,
> >please let us know.
> 
> Yeah, keep it simple. :)

Okay, it's not always prone to be complicated :)

Moriyoshi

> --Jani
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: #20755 [Opn->Ver]: exif relocation error)

[Jani Taskinen]

On Tue, 3 Dec 2002, Moriyoshi Koizumi wrote:

>--snip
>> If you compile mbstring as static module, you can workaround this
>> error. It's not very good idea to enable it anyway..
>
>I'm wondering why you referred to enabling mbstring as no good idea
>in this report. I believe the problem has been properly avoided, or am I 
>missing something?

Maybe I just assumed something, but I think this person really 
doesn't even need it. :) That's why I also noted about enabling 
only extensions that he actually needs.

The biggest concern about mbstring for me is that it changes some core
functions behaviour. I haven't followed the development of mbstring 
closely so I might be wrong here..just that one major bug caused by 
that duplication of code (for post vars parsing) gives me creeps. :)

As long as it's separate from core PHP, I will never suggest anybody
to use it.

>> For the mbstring authors: You should decide whether or not to allow
>> external usage of these functions (ie. in other extensions) or disable
>> the building of this extension as shared altogether..
>
>What decision? We actually externalise some functions just for that 
>purpose. Perhaps did you mean integration of mbstring into core part?

Yes. But mbstring is not the only extension having the same problem
when compiled as shared. At least iconv, openssl, pcre and gd also 
have some external parts used outside them. e.g. All the extensions
and core parts using those externalized functions in mbstring must
now put these around the parts using those:

#ifndef COMPILE_DL_MBSTRING
#endif

This is done in some places, but not everywhere, like shown by 
the bug report. 

The same problem is also with PCRE and GD extensions. 
One solution would be to make at least PCRE and MBstring always
static, ie. disallow building them as shared. Or move them
under ext/standard..

With openssl and iconv it's a bit different, the same libraries
are required by other extensions. This problem could be solved by
linking the core PHP always with those, even when compiling openssl
or iconv as shared extensions.

>BTW we are now working on a new mbstring API specification so that other 
>extension authors can use the functions with more convenience and in no 
>more doubt about their usage. If we should treat it in a special way,
>please let us know.

Yeah, keep it simple. :)

--Jani


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: #20755 [Opn->Ver]: exif relocation error

[Moriyoshi Koizumi]

--snip
> If you compile mbstring as static module, you can workaround this
> error. It's not very good idea to enable it anyway..

I'm wondering why you referred to enabling mbstring as no good idea
in this report. I believe the problem has been properly avoided, or am I 
missing something?

> For the mbstring authors: You should decide whether or not to allow
> external usage of these functions (ie. in other extensions) or disable
> the building of this extension as shared altogether..

What decision? We actually externalise some functions just for that 
purpose. Perhaps did you mean integration of mbstring into core part?

BTW we are now working on a new mbstring API specification so that other 
extension authors can use the functions with more convenience and in no 
more doubt about their usage. If we should treat it in a special way,
please let us know.

Moriyoshi


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php