Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #16212 > unrolled thread

how to configure PHP so extension_dir is null?

Back to article view | Back to comp.lang.php

Contents

  how to configure PHP so extension_dir is null? crankypuss <invalid@invalid.invalid> - 2016-01-12 07:12 -0700
    Re: how to configure PHP so extension_dir is null? Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 16:25 -0500
      Re: how to configure PHP so extension_dir is null? Allodoxaphobia <knock_yourself_out@example.net> - 2016-01-13 02:09 +0000
        Re: how to configure PHP so extension_dir is null? Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 21:11 -0500
      Re: how to configure PHP so extension_dir is null? crankypuss <invalid@invalid.invalid> - 2016-01-13 05:22 -0700
        Re: how to configure PHP so extension_dir is null? Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 08:25 -0500
          Re: how to configure PHP so extension_dir is null? crankypuss <invalid@invalid.invalid> - 2016-01-13 07:00 -0700
            Re: how to configure PHP so extension_dir is null? Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 10:10 -0500

#16212 — how to configure PHP so extension_dir is null?

I'm building PHP from source and want no ini-files, no extensions of any 
kind, except those statically linked in with the resulting PHP 
executable.

The configure line I'm using is:

./configure --disable-all --with-config-file-path=/dev/null --disable-
option-checking --with-libdir=/dev/null --disable-rpath

I'm still seeing this in the results of phpinfo():

extension_dir => /usr/local/lib/php/extensions/no-debug-non-zts-20131226 
=> /usr/local/lib/php/extensions/no-debug-non-zts-20131226

This is intended to be a "standalone" build, I don't want any extensions 
whatsoever except the ones I link in.  When I look up "extension_dir" 
via google I find that the doc tells me what PHP commands I can issue to 
set it, but what configure option do I need to set to disable it?

-- 
http://totally-portable-software.blogspot.com
  [Sun Nov 22: "Total Portability is not binary"]

[toc] | [next] | [standalone]

#16227

On 1/12/2016 9:12 AM, crankypuss wrote:
> I'm building PHP from source and want no ini-files, no extensions of any 
> kind, except those statically linked in with the resulting PHP 
> executable.
> 
> The configure line I'm using is:
> 
> ./configure --disable-all --with-config-file-path=/dev/null --disable-
> option-checking --with-libdir=/dev/null --disable-rpath
> 
> I'm still seeing this in the results of phpinfo():
> 
> extension_dir => /usr/local/lib/php/extensions/no-debug-non-zts-20131226 
> => /usr/local/lib/php/extensions/no-debug-non-zts-20131226
> 
> This is intended to be a "standalone" build, I don't want any extensions 
> whatsoever except the ones I link in.  When I look up "extension_dir" 
> via google I find that the doc tells me what PHP commands I can issue to 
> set it, but what configure option do I need to set to disable it?
> 

I don't think you can change it in the build configuration - at least I
didn't find any means to do so.  Even if you did, it could still be
overridden in a php.ini file.

Is there a problem with just having it point at an empty (or
non-existent) directory?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16232

On Tue, 12 Jan 2016 16:25:56 -0500, Jerry Stuckle wrote:
> On 1/12/2016 9:12 AM, crankypuss wrote:
>> I'm building PHP from source and want no ini-files, no extensions of any 
>> kind, except those statically linked in with the resulting PHP 
>> executable.
>
> I don't think you can change it in the build configuration - at least I
> didn't find any means to do so.  Even if you did, it could still be
> overridden in a php.ini file.
>
> Is there a problem with just having it point at an empty (or
> non-existent) directory?

<chuckle>  /dev/null

[toc] | [prev] | [next] | [standalone]

#16233

On 1/12/2016 9:09 PM, Allodoxaphobia wrote:
> On Tue, 12 Jan 2016 16:25:56 -0500, Jerry Stuckle wrote:
>> On 1/12/2016 9:12 AM, crankypuss wrote:
>>> I'm building PHP from source and want no ini-files, no extensions of any 
>>> kind, except those statically linked in with the resulting PHP 
>>> executable.
>>
>> I don't think you can change it in the build configuration - at least I
>> didn't find any means to do so.  Even if you did, it could still be
>> overridden in a php.ini file.
>>
>> Is there a problem with just having it point at an empty (or
>> non-existent) directory?
> 
> <chuckle>  /dev/null
> 

And what is the configure parameter which allows you to set that?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16237

Jerry Stuckle wrote:

> On 1/12/2016 9:12 AM, crankypuss wrote:
>> I'm building PHP from source and want no ini-files, no extensions of
>> any kind, except those statically linked in with the resulting PHP
>> executable.
>> 
>> The configure line I'm using is:
>> 
>> ./configure --disable-all --with-config-file-path=/dev/null
>> --disable- option-checking --with-libdir=/dev/null --disable-rpath
>> 
>> I'm still seeing this in the results of phpinfo():
>> 
>> extension_dir =>
>> /usr/local/lib/php/extensions/no-debug-non-zts-20131226 =>
>> /usr/local/lib/php/extensions/no-debug-non-zts-20131226
>> 
>> This is intended to be a "standalone" build, I don't want any
>> extensions
>> whatsoever except the ones I link in.  When I look up "extension_dir"
>> via google I find that the doc tells me what PHP commands I can issue
>> to set it, but what configure option do I need to set to disable it?
>> 
> 
> I don't think you can change it in the build configuration - at least
> I
> didn't find any means to do so.  Even if you did, it could still be
> overridden in a php.ini file.
> 
> Is there a problem with just having it point at an empty (or
> non-existent) directory?

I've been using /dev/null and it seems to have the desired effect.  The 
config command I'm currently working with is:

./configure \
	--with-config-file-path=/dev/null \
	--with-libdir=/dev/null \
	--disable-rpath \
	--disable-option-checking \
	--disable-libxml \
	--disable-dom \
	--disable-simplexml \
	--disable-xml \
	--disable-xmlreader \
	--disable-ctype \
	--disable-inifile \
	--disable-flatfile \
	--disable-filter \
	--disable-json \
	--disable-mbregex \
	--disable-mbregex-backtrack \
	--disable-pdo \
	--disable-phar \
	--disable-session \
	--disable-tokenizer \
	--disable-xmlwriter \
	--disable-mysqlnd-compression-support \
	--disable-inline-optimization \
	--disable-libtool-lock \
	--without-pear \
	--enable-ncursesw \
	--with-ncurses \

If I haven't muffed the testing, it seems to include ncurses 
functionality, but I suspect it's still using the ncurses shared 
library.  Ideally I'd rather have everything linked in statically, but 
given that I'm aware of no linux distro that doesn't include the ncurses 
library by default, maybe that's no big deal.  I'll probably get around 
to testing it on a "virgin install" later today.

The initial objective here is to run backup/restore utilities written in 
PHP on a system that does not have PHP installed.  Assuming that what I 
have works, the next step is to look for main() and start digging 
around; what I have in mind is concatenating the required PHP source 
onto the end of the (fairly large, at 18mb) PHP executable and executing 
that source instead of some other file, so that the whole thing is one 
lump, PHP engine plus application source.

-- 
http://totally-portable-software.blogspot.com
  [Sun Nov 22: "Total Portability is not binary"]

[toc] | [prev] | [next] | [standalone]

#16240

On 1/13/2016 7:22 AM, crankypuss wrote:
> Jerry Stuckle wrote:
> 
>> On 1/12/2016 9:12 AM, crankypuss wrote:
>>> I'm building PHP from source and want no ini-files, no extensions of
>>> any kind, except those statically linked in with the resulting PHP
>>> executable.
>>>
>>> The configure line I'm using is:
>>>
>>> ./configure --disable-all --with-config-file-path=/dev/null
>>> --disable- option-checking --with-libdir=/dev/null --disable-rpath
>>>
>>> I'm still seeing this in the results of phpinfo():
>>>
>>> extension_dir =>
>>> /usr/local/lib/php/extensions/no-debug-non-zts-20131226 =>
>>> /usr/local/lib/php/extensions/no-debug-non-zts-20131226
>>>
>>> This is intended to be a "standalone" build, I don't want any
>>> extensions
>>> whatsoever except the ones I link in.  When I look up "extension_dir"
>>> via google I find that the doc tells me what PHP commands I can issue
>>> to set it, but what configure option do I need to set to disable it?
>>>
>>
>> I don't think you can change it in the build configuration - at least
>> I
>> didn't find any means to do so.  Even if you did, it could still be
>> overridden in a php.ini file.
>>
>> Is there a problem with just having it point at an empty (or
>> non-existent) directory?
> 
> I've been using /dev/null and it seems to have the desired effect.  The 
> config command I'm currently working with is:
> 
> ./configure \
> 	--with-config-file-path=/dev/null \
> 	--with-libdir=/dev/null \
> 	--disable-rpath \
> 	--disable-option-checking \
> 	--disable-libxml \
> 	--disable-dom \
> 	--disable-simplexml \
> 	--disable-xml \
> 	--disable-xmlreader \
> 	--disable-ctype \
> 	--disable-inifile \
> 	--disable-flatfile \
> 	--disable-filter \
> 	--disable-json \
> 	--disable-mbregex \
> 	--disable-mbregex-backtrack \
> 	--disable-pdo \
> 	--disable-phar \
> 	--disable-session \
> 	--disable-tokenizer \
> 	--disable-xmlwriter \
> 	--disable-mysqlnd-compression-support \
> 	--disable-inline-optimization \
> 	--disable-libtool-lock \
> 	--without-pear \
> 	--enable-ncursesw \
> 	--with-ncurses \
> 
> If I haven't muffed the testing, it seems to include ncurses 
> functionality, but I suspect it's still using the ncurses shared 
> library.  Ideally I'd rather have everything linked in statically, but 
> given that I'm aware of no linux distro that doesn't include the ncurses 
> library by default, maybe that's no big deal.  I'll probably get around 
> to testing it on a "virgin install" later today.
> 
> The initial objective here is to run backup/restore utilities written in 
> PHP on a system that does not have PHP installed.  Assuming that what I 
> have works, the next step is to look for main() and start digging 
> around; what I have in mind is concatenating the required PHP source 
> onto the end of the (fairly large, at 18mb) PHP executable and executing 
> that source instead of some other file, so that the whole thing is one 
> lump, PHP engine plus application source.
> 

An interesting idea, but I'm not sure how realistic it is to concatenate
the source onto the PHP executable.

But my question would be - if all you want is backup/restore, are you
sure PHP is the right tool?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16242

Jerry Stuckle wrote:

> On 1/13/2016 7:22 AM, crankypuss wrote:
>> Jerry Stuckle wrote:
>> 
>>> On 1/12/2016 9:12 AM, crankypuss wrote:
>>>> I'm building PHP from source and want no ini-files, no extensions
>>>> of any kind, except those statically linked in with the resulting
>>>> PHP executable.
>>>>
>>>> The configure line I'm using is:
>>>>
>>>> ./configure --disable-all --with-config-file-path=/dev/null
>>>> --disable- option-checking --with-libdir=/dev/null --disable-rpath
>>>>
>>>> I'm still seeing this in the results of phpinfo():
>>>>
>>>> extension_dir =>
>>>> /usr/local/lib/php/extensions/no-debug-non-zts-20131226 =>
>>>> /usr/local/lib/php/extensions/no-debug-non-zts-20131226
>>>>
>>>> This is intended to be a "standalone" build, I don't want any
>>>> extensions
>>>> whatsoever except the ones I link in.  When I look up
>>>> "extension_dir" via google I find that the doc tells me what PHP
>>>> commands I can issue to set it, but what configure option do I need
>>>> to set to disable it?
>>>>
>>>
>>> I don't think you can change it in the build configuration - at
>>> least I
>>> didn't find any means to do so.  Even if you did, it could still be
>>> overridden in a php.ini file.
>>>
>>> Is there a problem with just having it point at an empty (or
>>> non-existent) directory?
>> 
>> I've been using /dev/null and it seems to have the desired effect. 
>> The config command I'm currently working with is:
>> 
>> ./configure \
>> --with-config-file-path=/dev/null \
>> --with-libdir=/dev/null \
>> --disable-rpath \
>> --disable-option-checking \
>> --disable-libxml \
>> --disable-dom \
>> --disable-simplexml \
>> --disable-xml \
>> --disable-xmlreader \
>> --disable-ctype \
>> --disable-inifile \
>> --disable-flatfile \
>> --disable-filter \
>> --disable-json \
>> --disable-mbregex \
>> --disable-mbregex-backtrack \
>> --disable-pdo \
>> --disable-phar \
>> --disable-session \
>> --disable-tokenizer \
>> --disable-xmlwriter \
>> --disable-mysqlnd-compression-support \
>> --disable-inline-optimization \
>> --disable-libtool-lock \
>> --without-pear \
>> --enable-ncursesw \
>> --with-ncurses \
>> 
>> If I haven't muffed the testing, it seems to include ncurses
>> functionality, but I suspect it's still using the ncurses shared
>> library.  Ideally I'd rather have everything linked in statically,
>> but given that I'm aware of no linux distro that doesn't include the
>> ncurses
>> library by default, maybe that's no big deal.  I'll probably get
>> around to testing it on a "virgin install" later today.
>> 
>> The initial objective here is to run backup/restore utilities written
>> in
>> PHP on a system that does not have PHP installed.  Assuming that what
>> I have works, the next step is to look for main() and start digging
>> around; what I have in mind is concatenating the required PHP source
>> onto the end of the (fairly large, at 18mb) PHP executable and
>> executing that source instead of some other file, so that the whole
>> thing is one lump, PHP engine plus application source.
>> 
> 
> An interesting idea, but I'm not sure how realistic it is to
> concatenate the source onto the PHP executable.

I already have the "source code linker" that finds all the required code 
and appends it into a single compressed file that runs with a separate 
executable; the difference is having an extra 18mb of executable, which 
is annoying but at least guarantees that the code can run.  Running it 
on any linux distro, whether or not PHP has been installed, is the near-
term goal.

> But my question would be - if all you want is backup/restore, are you
> sure PHP is the right tool?

Actually I am sure that PHP is not the right tool, but it's the closest 
available at the moment.  It might be more fun to sit down and start 
writing C but I'm looking toward a specific goal.  PHP is an interim 
measure.  Backup/restore is not all I want, it's only that portion of 
what I want that is needed first in order to build the rest. <g>

-- 
http://totally-portable-software.blogspot.com
  [Sun Nov 22: "Total Portability is not binary"]

[toc] | [prev] | [next] | [standalone]

#16245

On 1/13/2016 9:00 AM, crankypuss wrote:
> Jerry Stuckle wrote:
> 
>> On 1/13/2016 7:22 AM, crankypuss wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> On 1/12/2016 9:12 AM, crankypuss wrote:
>>>>> I'm building PHP from source and want no ini-files, no extensions
>>>>> of any kind, except those statically linked in with the resulting
>>>>> PHP executable.
>>>>>
>>>>> The configure line I'm using is:
>>>>>
>>>>> ./configure --disable-all --with-config-file-path=/dev/null
>>>>> --disable- option-checking --with-libdir=/dev/null --disable-rpath
>>>>>
>>>>> I'm still seeing this in the results of phpinfo():
>>>>>
>>>>> extension_dir =>
>>>>> /usr/local/lib/php/extensions/no-debug-non-zts-20131226 =>
>>>>> /usr/local/lib/php/extensions/no-debug-non-zts-20131226
>>>>>
>>>>> This is intended to be a "standalone" build, I don't want any
>>>>> extensions
>>>>> whatsoever except the ones I link in.  When I look up
>>>>> "extension_dir" via google I find that the doc tells me what PHP
>>>>> commands I can issue to set it, but what configure option do I need
>>>>> to set to disable it?
>>>>>
>>>>
>>>> I don't think you can change it in the build configuration - at
>>>> least I
>>>> didn't find any means to do so.  Even if you did, it could still be
>>>> overridden in a php.ini file.
>>>>
>>>> Is there a problem with just having it point at an empty (or
>>>> non-existent) directory?
>>>
>>> I've been using /dev/null and it seems to have the desired effect. 
>>> The config command I'm currently working with is:
>>>
>>> ./configure \
>>> --with-config-file-path=/dev/null \
>>> --with-libdir=/dev/null \
>>> --disable-rpath \
>>> --disable-option-checking \
>>> --disable-libxml \
>>> --disable-dom \
>>> --disable-simplexml \
>>> --disable-xml \
>>> --disable-xmlreader \
>>> --disable-ctype \
>>> --disable-inifile \
>>> --disable-flatfile \
>>> --disable-filter \
>>> --disable-json \
>>> --disable-mbregex \
>>> --disable-mbregex-backtrack \
>>> --disable-pdo \
>>> --disable-phar \
>>> --disable-session \
>>> --disable-tokenizer \
>>> --disable-xmlwriter \
>>> --disable-mysqlnd-compression-support \
>>> --disable-inline-optimization \
>>> --disable-libtool-lock \
>>> --without-pear \
>>> --enable-ncursesw \
>>> --with-ncurses \
>>>
>>> If I haven't muffed the testing, it seems to include ncurses
>>> functionality, but I suspect it's still using the ncurses shared
>>> library.  Ideally I'd rather have everything linked in statically,
>>> but given that I'm aware of no linux distro that doesn't include the
>>> ncurses
>>> library by default, maybe that's no big deal.  I'll probably get
>>> around to testing it on a "virgin install" later today.
>>>
>>> The initial objective here is to run backup/restore utilities written
>>> in
>>> PHP on a system that does not have PHP installed.  Assuming that what
>>> I have works, the next step is to look for main() and start digging
>>> around; what I have in mind is concatenating the required PHP source
>>> onto the end of the (fairly large, at 18mb) PHP executable and
>>> executing that source instead of some other file, so that the whole
>>> thing is one lump, PHP engine plus application source.
>>>
>>
>> An interesting idea, but I'm not sure how realistic it is to
>> concatenate the source onto the PHP executable.
> 
> I already have the "source code linker" that finds all the required code 
> and appends it into a single compressed file that runs with a separate 
> executable; the difference is having an extra 18mb of executable, which 
> is annoying but at least guarantees that the code can run.  Running it 
> on any linux distro, whether or not PHP has been installed, is the near-
> term goal.
> 
>> But my question would be - if all you want is backup/restore, are you
>> sure PHP is the right tool?
> 
> Actually I am sure that PHP is not the right tool, but it's the closest 
> available at the moment.  It might be more fun to sit down and start 
> writing C but I'm looking toward a specific goal.  PHP is an interim 
> measure.  Backup/restore is not all I want, it's only that portion of 
> what I want that is needed first in order to build the rest. <g>
> 

Another possibility could be a bash script.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web