php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65088 Generated configure script is malformed on OpenBSD
Submitted: 2013-06-21 16:22 UTC Modified: 2013-06-23 18:01 UTC
From: stolen dot data dot net at gmail dot com Assigned: aharvey (profile)
Status: Closed Package: Compile Failure
PHP Version: 5.5.0 OS: OpenBSD 5.3 (possibly all BSDs)
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: stolen dot data dot net at gmail dot com
New email:
PHP Version: OS:

 

 [2013-06-21 16:22 UTC] stolen dot data dot net at gmail dot com
Description:
------------
This is a long-standing issue that dates back more than a year. I'm "re-reporting" 
it in hopes that it will finally get attention instead of being overlooked.

During ./configure, the following warnings - which later on cause the 
make/compilation phase to halt with errors - will show up:

./configure[21401]: cd: /usr/opt/php-5.5.0/"ext/date" - No such file or directory

...

./configure[56997]: cd: /usr/opt/php-5.5.0/"ext/mbstring" - No such file or 
directory
./configure[56997]: cd: /usr/opt/php-5.5.0/"ext/mbstring" - No such file or 
directory
./configure[56997]: cd: /usr/opt/php-5.5.0/"ext/mbstring/libmbfl" - No such file 
or directory

Backtracking from those line numbers we quickly find the problem, present at both 
lines 21381 and 56850:

    ep_realdir="`(cd \"$ep_dir\" && pwd)`"

This exact line is present numerous times in the configure script, but for some 
reason it fails on the three extension paths described above. It might be caused 
by the line just before that prepares $ep_dir using SED.

The quick'n'dirty solution is to simply unquote $ep_dir by removing the two \" in 
the subshell statement, but something proper would be preferred.



Also, no biggie, but there are some odd recurrences of inclusion paths showing up 
during compiling. Each line separated:

-I/usr/opt/php-5.5.0/ext/date/lib
"-I/usr/opt/php-5.5.0/ext/date/lib
 -I/usr/opt/php-5.5.0/ext/ereg/regex
 -I/usr/local/include
 -I/usr/opt/php-5.5.0/ext/mbstring/oniguruma
 -I/usr/opt/php-5.5.0/ext/mbstring/oniguruma"
-I/usr/opt/php-5.5.0/ext/mbstring/libmbfl
-I/usr/opt/php-5.5.0/ext/mbstring/libmbfl
"-I/usr/opt/php-5.5.0/ext/mbstring/libmbfl/mbfl
 -I/usr/opt/php-5.5.0/ext/mbstring/libmbfl/mbfl"

Test script:
---------------
./configure
make

Expected result:
----------------
No path failures.

Actual result:
--------------
Described above.

Patches

bug65088 (last revision 2013-06-22 23:54 UTC by aharvey@php.net)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-22 03:23 UTC] rasmus@php.net
-Status: Open +Status: Feedback
 [2013-06-22 03:23 UTC] rasmus@php.net
Seems fine on freebsd. If you re-generate the configure script, does it work?

rm configure && ./buildconf --force
 [2013-06-22 15:39 UTC] stolen dot data dot net at gmail dot com
No, rebuilding configure changed nothing. Already gave it a try.
 [2013-06-22 22:36 UTC] rasmus@php.net
So basically autoconf generates a configure script that doesn't work on OpenBSD? 
That sounds a bit suspicious and I wonder why nobody else has reported it.

Anything special about your environment?

And can you reproduce just with just running the ./configure script with no args 
that comes with the php-5.5.0 tarball?

I just tested it again on FreeBSD 9.0 and it worked flawlessly, so it is not a 
generic BSD issue. It is either OpenBSD-specific or specific to your 
environment.
 [2013-06-22 22:50 UTC] rasmus@php.net
So, a quick test on FreeBSD:

$ /bin/sh
$ cd /usr/"local"
$ pwd
/usr/local

That doesn't work on your machine?

We can't just remove the quotes there because it would break directory names 
with spaces and other shell-special characters in them. cd is a built-in in the 
shell and should support quoted literals. autoconf obviously relies on this 
being the case. Have you done something interesting to your /bin/sh on this box?
 [2013-06-22 22:56 UTC] fa@php.net
Just tried this on:
OpenBSD puffy.lan 4.9 GENERIC#477 amd64

bash-4.1# /bin/sh
# /bin/sh
# cd /root/
# pwd
/root
# cd /usr/"local"
# pwd
/usr/local
 [2013-06-22 23:02 UTC] fa@php.net
Addendum: This is my shell version:

# echo $SH_VERSION
@(#)PD KSH v5.2.14 99/07/13.2
 [2013-06-22 23:53 UTC] aharvey@php.net
Can you try applying the patch I'm about to upload, then rebuilding configure by 
running ./buildconf, please? (You may need to use ./buildconf --force if you're 
using a release tarball; note that you'll require autoconf 2.59 or later.)
 [2013-06-22 23:54 UTC] aharvey@php.net
The following patch has been added/updated:

Patch Name: bug65088
Revision:   1371945248
URL:        https://bugs.php.net/patch-display.php?bug=65088&patch=bug65088&revision=1371945248
 [2013-06-23 16:14 UTC] stolen dot data dot net at gmail dot com
Yes, I understand the quotation has to be reworked rather than removed 
("quick'n'dirty") - aharvey's supplied patch that changed the manner of quotation 
solved the problem, by the way.

No modifications have been done to my sh binary, and same goes for my environment 
with the exception of setting LC_CTYPE to get proper UTF-8 support. The problem is 
identical whether I run the vanilla configure or the rebuilt one, without 
arguments, or with the arguments I use for my PHP build.

I reported this problem already with PHP 5.4.0 on OpenBSD 5.0 - the PHP 5.3 branch 
did not show this problem on OpenBSD 5.0 or any other earlier version that I've 
been running for years, all of which use an unmodified environment.

Quoting portion of a path - cd /some/path/"somewhere" - works just fine straight 
off the shell with sh, ksh and bash, just like expected. I tested this already 
over a year ago when when I found this issue the first time. Why it fails when 
executed inside the configure script confused me already back then.
 [2013-06-23 16:32 UTC] stolen dot data dot net at gmail dot com
Backslash-escaping the quotes seems to be the issue, turning the quotes into 
literals causing broken substitution on both sh, ksh and bash.

sdata@antikythera$ cd /home/"sdata" && pwd 
/home/sdata

sdata@antikythera$ cd /home/\"sdata\" && pwd
ksh: cd: /home/"sdata" - No such file or directory
 [2013-06-23 17:41 UTC] aharvey@php.net
-Status: Feedback +Status: Assigned -Assigned To: +Assigned To: aharvey
 [2013-06-23 17:41 UTC] aharvey@php.net
Terrific; thanks for that. I'll run a couple more tests quickly, and assuming 
they're OK, will push this.
 [2013-06-23 18:01 UTC] aharvey@php.net
-Summary: configure script (and compile) fails, perhaps due to BSD differences in SH +Summary: Generated configure script is malformed on OpenBSD
 [2013-06-23 18:01 UTC] aharvey@php.net
Editing the summary so that the news entry is more obvious.
 [2013-06-23 18:07 UTC] aharvey@php.net
Automatic comment on behalf of aharvey
Revision: http://git.php.net/?p=php-src.git;a=commit;h=2531307be601b95a4aac38dc26dd2d27112b9291
Log: Fix bug #65088 (Generated configure script is malformed on OpenBSD).
 [2013-06-23 18:07 UTC] aharvey@php.net
-Status: Assigned +Status: Closed
 [2013-08-05 21:34 UTC] glen at delfi dot ee
this is actually old bug going back to 2006, fixed in pld, but seems never 
reached php.net

http://git.pld-linux.org/?
p=packages/php.git;a=commitdiff;h=0c510837964981255f8f3bdb0bd9473d404770a1

pld uses (used) pdksh as well at that time
 [2014-10-07 23:18 UTC] stas@php.net
Automatic comment on behalf of aharvey
Revision: http://git.php.net/?p=php-src-security.git;a=commit;h=2531307be601b95a4aac38dc26dd2d27112b9291
Log: Fix bug #65088 (Generated configure script is malformed on OpenBSD).
 [2014-10-07 23:29 UTC] stas@php.net
Automatic comment on behalf of aharvey
Revision: http://git.php.net/?p=php-src-security.git;a=commit;h=2531307be601b95a4aac38dc26dd2d27112b9291
Log: Fix bug #65088 (Generated configure script is malformed on OpenBSD).
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 10:01:29 2024 UTC