> PHP_NEW_EXTENSION(mmsr, mmsr.c "$PHP_MMSR/MMSR/mmsr_bridge.cpp",
> $ext_shared)
PHP_NEW_EXTENSION(mmsr, mmsr.c "$PHP_MMSR/MMSR/mmsr_bridge.cpp",
$ext_shared,,,1)
Ref: aclocal.m4 / EEPHP:Chapter 17
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
On 9/25/06, Stut <[EMAIL PROTECTED]> wrote:
I had expected the PHP_REQUIRE_CXX() macro to trigger a change to the
link command, but it does not seem to have done anything beyond
influencing what is used to compile the extension itself.
Hi,
I think you have to add stdc++ with PHP_ADD_LIBRARY()
On 26.09.2006 01:09, Stut wrote:
Ok, so I've built an extension that uses a C++ library. It compiles fine
but the build system is insisting on linking with gcc no matter what I
tell it. Is there some simple trick I'm missing as far as convincing it
to use g++ goes?
Here is the config.m4 in ca
Ok, so I've built an extension that uses a C++ library. It compiles fine
but the build system is insisting on linking with gcc no matter what I
tell it. Is there some simple trick I'm missing as far as convincing it
to use g++ goes?
Here is the config.m4 in case I've missed something in there.
I posted this to php-general several days ago, and the only response
suggested that perhaps I should forward the question to PHP internals.
If what's below isn't expected behavior, I'd be glad to dedicate a few
days to helping track down the problem.
I've tried what's below on the server clust
Hello,
Before any further comment, I have to say that I'm more than
disappointed to have put so much effort to get a concensus from the
PHP developers here and lost it right away because you, alone, thinks
that *we* made wrong choices. I cannot accept that any longuer, I do
not want to block 5.2
On Sun, 24 Sep 2006, Ron Korving wrote:
> In this case, wouldn't E_NOTICE make more sense? E_STRICT kind of indicates
> that certain behaviour is deprecated, right?
Not really, E_STRICT is for when you're doing something that you
shouldn't. In my opinion that includes using a deprecated function
On Sun, 24 Sep 2006, Zeev Suraski wrote:
> At 11:10 22/09/2006, Derick Rethans wrote:
> >On Thu, 21 Sep 2006, Michael Wallner wrote:
> >
> > > [ ] (+1) please remove that redundant strictness again
> > > [X] (-1) leave as it is, we need strict OO implementation
> > > [ ] ( 0) what the hell are you
On Sat, 23 Sep 2006, Rui Hirokawa wrote:
> What do you think about the specification ?
> Which way do you prefer to support alias/MIME encoding?
> 1. adding new functions
>(mb_list_encodings_alias_names(), mb_list_mime_names())
> 2. adding an option to mb_list_encoding().
I think it should
On Thu, 21 Sep 2006, Pierre wrote:
> Before any further comment, we agreed on the "filter" prefix. We have
> to stick to it. I also think we should respect other developers
> choices.
>
> As you said, filter is more than a simple extension, its design choice
> should not be up to only one or two
Hi,
Noticed this a couple months ago and never sent this simple thing. :-)
ERANGE is being triggered too soon because of the wrong variable, which
causes the following (in Unicode mode, of course) on 32-bit:
(int) '2147483640' // int(2147483647)
'2147483640' + 0) // float(2147483640)
Instead of
Hi Richard,
- Original Message -
From: "Richard Quadling"
Sent: Monday, September 25, 2006
> On 25/09/06, Matt W <[EMAIL PROTECTED]> wrote:
> > [...]
> >
> > I don't know if my regex search found all occurrences, but I fixed up
the
> > files I found. The only changes were removing a tra
On 25/09/06, Matt W <[EMAIL PROTECTED]> wrote:
Hi,
Don't know if someone wants to check this out and apply it before 5.2's
release, or whether you want it at all. ;-) I just noticed how many of the
php_error_docref()'s still have a period (".") at the end of the text,
resulting in "... error me
Hi,
Don't know if someone wants to check this out and apply it before 5.2's
release, or whether you want it at all. ;-) I just noticed how many of the
php_error_docref()'s still have a period (".") at the end of the text,
resulting in "... error message. in on line " Looks
better/consistent wit
PHP 5 Bug Database summary - http://bugs.php.net
Num Status Summary (600 total including feature requests)
===[*Configuration Issues]
37919 Feedback PHP doesn't read the configurations propertly
===
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (634 total including feature requests)
===[*Configuration Issues]
38670 Open Whole 4.4.x branch has problem with open_basedir option nested
from Apache2
Ron Korving wrote:
> In this case, wouldn't E_NOTICE make more sense? E_STRICT kind of
> indicates that certain behaviour is deprecated, right?
We are moving in circles. Using E_STRICT for both the use of deprecated
language features and the "unstrict" use of language features is
confusing.
-
On 24/09/06, Ron Korving <[EMAIL PROTECTED]> wrote:
In this case, wouldn't E_NOTICE make more sense? E_STRICT kind of indicates
that certain behaviour is deprecated, right?
I think that's a whole other issue. E_STRICT seems to be used for both
errors in coding style (calling static methods from
18 matches
Mail list logo
