Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1
ID: 48795
Comment by: pgarvin76 at gmail dot com
Reported by:gwy...@php.net
Summary:Building intl 64-bit fails on OS X
Status: Verified
Type: Bug
Package:Compile Failure
Operating System: OS X 10.5 10.6; Linux
PHP Version:5.3 SVN; 5.4.0RC1
Block user comment: N
Private report: N
New Comment:
This is still and issue on 5.3.18, but 5.4.8 built without error. Interestingly
if you build intl as shared you don't get the compile error (how I am currently
getting around issue). I am on Ubuntu 12.04.
Previous Comments:
[2012-09-11 16:27:47] re...@php.net
Same for me, I can't compile either. hope there is a solution
[2012-05-08 13:11:12] k...@php.net
Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A
generic solution would be nice, indeed.
[2012-03-13 15:46:33] dan at cdchase dot com
It would be helpful if the build system imported any already set CFLAGS. As
I've experienced this issue before, so I've set the appropriate CFLAGS in my
default environment. But, the automated install routine does not honor these. I
have to manually install for them to be honored.
[2011-11-14 16:54:00] weierophin...@php.net
I can confirm Stas's suggestion (s/CC/CXX/ in BUILD_* vars) works with 5.4.0RC1
on linux 64-bit.
[2011-11-11 11:30:21] ahar...@php.net
tl;dr: Debian Testing and Ubuntu 11.10 have the same problem with
./configure --enable-intl --with-curl.
Effectively the same issue (required C++ linkage not occurring) is now
happening on Ubuntu 11.10 (x86-64) and Debian Testing (armv7l) with
PHP 5.3 SVN and PHP 5.4.0RC1 when compiling with both intl and curl
enabled (note that a compile with just --enable-intl succeeds). It's
notable that both these distributions feature the new Debian
multiarch support. Both libcurl and libicu are the normal packaged
versions.
With ./configure --enable-intl --with-curl, the result of
the compile (on the Ubuntu box, although the Debian errors are
effectively the same, just with different architecture-specific paths)
is this:
/usr/bin/ld: ext/intl/msgformat/msgformat_helpers.o: undefined reference to
symbol '__gxx_personality_v0@@CXXABI_1.3'
/usr/bin/ld: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 so try adding it to the linker command
line
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: could not read symbols: Invalid
operation
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1
Diffing the Makefile produced by --enable-intl alone with the
--enable-intl --with-curl combination produces the following
(excluding rules directly related to compiling objects within
ext/curl):
@@ -75,9 +76,9 @@
CXXFLAGS_CLEAN = -g -O2
DEBUG_CFLAGS =
EXTENSION_DIR = /usr/local/lib/php/extensions/no-debug-non-zts-20100525
-EXTRA_LDFLAGS =
-EXTRA_LDFLAGS_PROGRAM =
-EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lxml2
-ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 -lcrypt -lxml2
-lxml2 -lxml2 -lcrypt
+EXTRA_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LDFLAGS_PROGRAM = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lcurl -lrt -lm -ldl -lnsl -lxml2
-lcurl -lxml2 -ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2
-lcrypt -lxml2 -lxml2 -lxml2 -lcrypt
ZEND_EXTRA_LIBS =
INCLUDES = -I/tmp/php-5.4.0RC1/ext/date/lib -I/tmp/php-5.4.0RC1/ext/ereg/regex
-I/usr/include/libxml2 -I/tmp/php-5.4.0RC1/ext/sqlite3/libsqlite
-I$(top_builddir)/TSRM -I$(top_builddir)/Zend
EXTRA_INCLUDES =
@@ -86,13 +87,13 @@
LFLAGS =
LIBTOOL = $(SHELL) $(top_builddir)/libtool --silent --preserve-dup-deps
LN_S = ln -s
-NATIVE_RPATHS =
+NATIVE_RPATHS = -Wl,-rpath,/usr/lib/x86_64-linux-gnu
PEAR_INSTALLDIR = ${exec_prefix}/lib/php
PHP_BUILD_DATE = 2011-11-11
-PHP_LDFLAGS =
+PHP_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
PHP_LIBS =
OVERALL_TARGET =
-PHP_RPATHS =
+PHP_RPATHS = -R /usr/lib/x86_64-linux-gnu
PHP_SAPI = none
PHP_VERSION = 5.4.0RC1
PHP_VERSION_ID = 50400
Stas's suggestion of replacing the $(BUILD_CGI) and $(BUILD_CLI)
instances of $(CC) in the generated Makefile with $(CXX) fixes the
build.
I'm not familiar enough with our build system to know how to fix this,
but we should probably do something if we can for 5.4.0 final: intl
and curl doesn't seem like it would be an unusual combination. Can we
hack the build system to use the C++ compiler preferentially if
ext/intl and ext/curl are enabled, if it can't be fixed
Req #49510 [Com]: boolean validation fails with FILTER_NULL_ON_FAILURE
Edit report at https://bugs.php.net/bug.php?id=49510edit=1
ID: 49510
Comment by: pgarvin76 at gmail dot com
Reported by:m dot kurzyna at crystalpoint dot pl
Summary:boolean validation fails with FILTER_NULL_ON_FAILURE
Status: Assigned
Type: Feature/Change Request
Package:Filter related
Operating System: Linux
PHP Version:5.3.0
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
There was a fix committed in branch 5.4.8
(a26390ef0c22be3637795d9b5ab1c445e1d3f847). But the problem still persists for
me. The test file (bug49510.phpt) fails on my fresh build.
Previous Comments:
[2012-09-12 20:22:38] dernelson at corelogic dot com
The question the developer is asking filter_var() is: is boolean FALSE a valid
boolean, and the answer filter_var() is giving back is nope. Regardless of
the technical details underlying the implementation, there is an obvious
problem here.
Short of changing PHP so that (string)FALSE === '0' (hah), I would suggest an
explicit test case for boolean FALSE values, so that the function can return
boolean FALSE in those cases, instead of NULL.
[2012-07-15 04:57:34] s...@php.net
Filters operate on strings. So any value that is passed to the filter_var()
will
be coerced into string. This means (boolean)false and '' is exactly the same
for
the filter. And that means the callbacks will be receiving strings too.
Now, the docs specifically say '' is a valid value for boolean filter and is
converted to false, so '' should not return NULL with FILTER_NULL_ON_FAILURE I
guess since it's documented not to be failure value.
[2012-06-24 00:34:38] 2072 at teaser dot fr
Knowing this issue I wanted to make a boolean validation filter of my own using
FILTER_CALLBACK but it suffers from the same problem, these filters are not
boolean safe.
It appears that what is to be validated is first converted to a string.
So when given (bool)true my callback actually receives (string)'1' and
(string)'' when given (bool)false.
There is definitely something wrong.
(I'm using PHP 5.3.8)
[2010-09-01 13:55:06] schkovich at gmail dot com
filter_var(false,FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE)
// got NULL, expected false
That does not make sense at all! Further on, I have to agree with m.kurzyna
that since false === (bool)
filter_var(,FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE) should
return FALSE and not NULL.
Basically, as implemented, getting FALSE from
filter_var(false,FILTER_VALIDATE_BOOLEAN) means that validation failed. It
appears to be a design problem since filter_var() as
specified will return FALSE if the filter fails making it impossible to
distinguish if filter failed or valid FALSE value is returned. Therefore,
instead returning FALSE if
filter fails perhaps warning could be issued or even better exception thrown.
On addition when voting I've wrongly selected that I am not using the same
version and the same operating system. Correct ones are:
PHP Version = 5.3.2-1ubuntu4.2
System = Linux schkovich 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:21:58
UTC 2010 x86_64
[2009-09-10 11:24:37] m dot kurzyna at crystalpoint dot pl
As much as i'd like to have empty string be invalid false cast i have to
disagree with you for consistency reasons.
If (boolean)'' == false then filter_var('','boolean') should also return false.
Both in general and in case of FILTER_NULL_ON_FAILURE (just like the
documentation states).
Also, because i can't stress it enough, this is a VALIDATOR not a SANITIZER so
using it as a strict caster is secondary to it's validation purpose and as such
it currently fails both on implied and explicit behavior.
The ideal solution would be to have FILTER_VALIDATE_BOOLEAN roughly equal to
current behavior with FILTER_NULL_ON_FAILURE and a *seperate*
FILTER_SANITIZE_BOOLEAN similar to current behavior w/o the null failure flag.
This however probably is impossible due to BC.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=49510
--
Edit this bug report at https://bugs.php.net/bug.php?id=49510edit=1
Req #49510 [Com]: boolean validation fails with FILTER_NULL_ON_FAILURE
Edit report at https://bugs.php.net/bug.php?id=49510edit=1 ID: 49510 Comment by: pgarvin76 at gmail dot com Reported by:m dot kurzyna at crystalpoint dot pl Summary:boolean validation fails with FILTER_NULL_ON_FAILURE Status: Assigned Type: Feature/Change Request Package:Filter related Operating System: Linux PHP Version:5.3.0 Assigned To:pajoye Block user comment: N Private report: N New Comment: Never mind my last comment. I was using the wrong executable when running the tests. The fix works. However, this patch was not merged into the 5.3 branch. Can we get it merged for 5.3.19? Previous Comments: [2012-10-26 03:32:23] pgarvin76 at gmail dot com There was a fix committed in branch 5.4.8 (a26390ef0c22be3637795d9b5ab1c445e1d3f847). But the problem still persists for me. The test file (bug49510.phpt) fails on my fresh build. [2012-09-12 20:22:38] dernelson at corelogic dot com The question the developer is asking filter_var() is: is boolean FALSE a valid boolean, and the answer filter_var() is giving back is nope. Regardless of the technical details underlying the implementation, there is an obvious problem here. Short of changing PHP so that (string)FALSE === '0' (hah), I would suggest an explicit test case for boolean FALSE values, so that the function can return boolean FALSE in those cases, instead of NULL. [2012-07-15 04:57:34] s...@php.net Filters operate on strings. So any value that is passed to the filter_var() will be coerced into string. This means (boolean)false and '' is exactly the same for the filter. And that means the callbacks will be receiving strings too. Now, the docs specifically say '' is a valid value for boolean filter and is converted to false, so '' should not return NULL with FILTER_NULL_ON_FAILURE I guess since it's documented not to be failure value. [2012-06-24 00:34:38] 2072 at teaser dot fr Knowing this issue I wanted to make a boolean validation filter of my own using FILTER_CALLBACK but it suffers from the same problem, these filters are not boolean safe. It appears that what is to be validated is first converted to a string. So when given (bool)true my callback actually receives (string)'1' and (string)'' when given (bool)false. There is definitely something wrong. (I'm using PHP 5.3.8) [2010-09-01 13:55:06] schkovich at gmail dot com filter_var(false,FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE) // got NULL, expected false That does not make sense at all! Further on, I have to agree with m.kurzyna that since false === (bool) filter_var(,FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE) should return FALSE and not NULL. Basically, as implemented, getting FALSE from filter_var(false,FILTER_VALIDATE_BOOLEAN) means that validation failed. It appears to be a design problem since filter_var() as specified will return FALSE if the filter fails making it impossible to distinguish if filter failed or valid FALSE value is returned. Therefore, instead returning FALSE if filter fails perhaps warning could be issued or even better exception thrown. On addition when voting I've wrongly selected that I am not using the same version and the same operating system. Correct ones are: PHP Version = 5.3.2-1ubuntu4.2 System = Linux schkovich 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:21:58 UTC 2010 x86_64 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=49510 -- Edit this bug report at https://bugs.php.net/bug.php?id=49510edit=1
[PHP-BUG] Bug #53755 [NEW]: FILTER_SANITIZE_STRING truncates string with unmatched
From:
Operating system: Ubuntu/Linux
PHP version: 5.3.5
Package: Filter related
Bug Type: Bug
Bug description:FILTER_SANITIZE_STRING truncates string with unmatched
Description:
If a string containing an unmatched character is run through the
FILTER_SANITIZE_STRING filter the string is truncated at the .
The problem seems to stem from the last parameter in the call to
php_strip_tags_ex(). That parameter tells php_strip_tags_ex() ignore spaces
trailing characters. I checked how php_strip_tags_ex() is called in the
PHP function strip_tags() and it tells php_strip_tags_ex to allow spaced
after a .
See ext/filter/santitizing_filters.c line 203 and ext/standard/string.c
line 4023 in PHP 5.3.5.
Test script:
---
echo filter_var('four is 6', FILTER_SANITIZE_STRING);
Expected result:
four is 6
Actual result:
--
four is
--
Edit bug report at http://bugs.php.net/bug.php?id=53755edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53755r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53755r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53755r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53755r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53755r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53755r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53755r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53755r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53755r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53755r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53755r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53755r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53755r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53755r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53755r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53755r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53755r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53755r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53755r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53755r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53755r=mysqlcfg
Bug #53755 [Com]: FILTER_SANITIZE_STRING truncates string with unmatched
Edit report at http://bugs.php.net/bug.php?id=53755edit=1
ID: 53755
Comment by: pgarvin76 at gmail dot com
Reported by:pgarvin76 at gmail dot com
Summary:FILTER_SANITIZE_STRING truncates string with
unmatched
Status: Open
Type: Bug
Package:Filter related
Operating System: Ubuntu/Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
The bugtracker would let me upload my diff so I created a Gist for it on
Github.
https://gist.github.com/780577
I tested this solves the problem on 5.3.5.
Also here is a PHPT test for the bug.
https://gist.github.com/780574
Previous Comments:
[2011-01-15 01:40:56] pgarvin76 at gmail dot com
Description:
If a string containing an unmatched character is run through the
FILTER_SANITIZE_STRING filter the string is truncated at the .
The problem seems to stem from the last parameter in the call to
php_strip_tags_ex(). That parameter tells php_strip_tags_ex() ignore
spaces trailing characters. I checked how php_strip_tags_ex() is
called in the PHP function strip_tags() and it tells php_strip_tags_ex
to allow spaced after a .
See ext/filter/santitizing_filters.c line 203 and ext/standard/string.c
line 4023 in PHP 5.3.5.
Test script:
---
echo filter_var('four is 6', FILTER_SANITIZE_STRING);
Expected result:
four is 6
Actual result:
--
four is
--
Edit this bug report at http://bugs.php.net/bug.php?id=53755edit=1
