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

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

.configure memory_limit building from source

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

Contents

  .configure memory_limit building from source crankypuss <invalid@invalid.invalid> - 2016-01-17 15:59 -0700
    Re: .configure memory_limit building from source "Peter H. Coffin" <hellsop@ninehells.com> - 2016-01-17 21:56 -0600
      Re: .configure memory_limit building from source crankypuss <invalid@invalid.invalid> - 2016-01-18 02:38 -0700
        Re: .configure memory_limit building from source "J.O. Aho" <user@example.net> - 2016-01-18 13:08 +0100
          Re: .configure memory_limit building from source Michael Vilain <vilain@NOspamcop.net> - 2016-01-18 17:48 -0800
            Re: .configure memory_limit building from source "J.O. Aho" <user@example.net> - 2016-01-19 06:56 +0100
              Re: .configure memory_limit building from source crankypuss <invalid@invalid.invalid> - 2016-01-19 02:37 -0700
        Re: .configure memory_limit building from source Arno Welzel <usenet@arnowelzel.de> - 2016-01-18 13:33 +0100
          Re: .configure memory_limit building from source crankypuss <invalid@invalid.invalid> - 2016-01-19 02:39 -0700
            Re: .configure memory_limit building from source crankypuss <invalid@invalid.invalid> - 2016-01-19 03:54 -0700
              Re: .configure memory_limit building from source Arno Welzel <usenet@arnowelzel.de> - 2016-01-19 18:27 +0100
                Re: .configure memory_limit building from source crankypuss <invalid@invalid.invalid> - 2016-01-19 14:38 -0700
                  Re: .configure memory_limit building from source Arno Welzel <usenet@arnowelzel.de> - 2016-01-20 06:11 +0100
            Re: .configure memory_limit building from source Arno Welzel <usenet@arnowelzel.de> - 2016-01-19 18:22 +0100
              Re: .configure memory_limit building from source crankypuss <invalid@invalid.invalid> - 2016-01-19 15:25 -0700
                Re: .configure memory_limit building from source Arno Welzel <usenet@arnowelzel.de> - 2016-01-20 06:20 +0100
                  Re: .configure memory_limit building from source crankypuss <invalid@invalid.invalid> - 2016-01-20 03:02 -0700
                  Re: .configure memory_limit building from source Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-21 01:43 +0100
    Re: .configure memory_limit building from source Arno Welzel <usenet@arnowelzel.de> - 2016-01-18 09:07 +0100
      Re: .configure memory_limit building from source crankypuss <invalid@invalid.invalid> - 2016-01-18 02:39 -0700
        Re: .configure memory_limit building from source Matthew Carter <m@ahungry.com> - 2016-01-18 21:21 -0500

Page 1 of 2  [1] 2  Next page →

#16300 — .configure memory_limit building from source

It appears that the default memory_limit value is 128M which is way too 
small for my purposes.  How can I configure this to a larger value?  I'm 
currently using:

./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 \
	--without-sqlite3 \
	--enable-ncursesw \
	--with-ncurses \
	--with-bz2 \
	memory_limit=-1



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

[toc] | [next] | [standalone]

#16301

On Sun, 17 Jan 2016 15:59:44 -0700, crankypuss wrote:
> It appears that the default memory_limit value is 128M which is way too 
> small for my purposes.  How can I configure this to a larger value?  I'm 
> currently using:
>
> 	memory_limit=-1
.       ^^^^^^^^^^^^^^^

goes in your php.ini, not configure.

-- 
Kyle J Cardoza <admin@zetachannel.com> sigged:
>Faith does not, in fact, move mountains;
Mainly because they won't let her loose with a drilling crew and enough 
dynamite.     -- Chris Suslowicz in the Monastery

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

#16303

Peter H. Coffin wrote:

> On Sun, 17 Jan 2016 15:59:44 -0700, crankypuss wrote:
>> It appears that the default memory_limit value is 128M which is way
>> too
>> small for my purposes.  How can I configure this to a larger value? 
>> I'm currently using:
>>
>> memory_limit=-1
> .       ^^^^^^^^^^^^^^^
> 
> goes in your php.ini, not configure.

Yes, so how do I do it from configure?  I do not want to *HAVE* any 
php.ini files for this build, it needs to be fully self-contained.

The configure help says "To assign environment variables (e.g., CC, 
CFLAGS...), specify them as VAR=VALUE.  See below for descriptions of 
some of the useful variables."  Apparently memory_limit is not one of 
those.

If nobody knows, or there is no way to do it, I'll need to modify the 
source, so I would appreciate clues in order to avoid that.

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

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

#16305

On 01/18/2016 10:38 AM, crankypuss wrote:
> Peter H. Coffin wrote:
> 
>> On Sun, 17 Jan 2016 15:59:44 -0700, crankypuss wrote:
>>> It appears that the default memory_limit value is 128M which is way
>>> too
>>> small for my purposes.  How can I configure this to a larger value? 
>>> I'm currently using:
>>>
>>> memory_limit=-1
>> .       ^^^^^^^^^^^^^^^
>>
>> goes in your php.ini, not configure.
> 
> Yes, so how do I do it from configure?  I do not want to *HAVE* any 
> php.ini files for this build, it needs to be fully self-contained.

Then you need to patch the source code, just find the right place and
change.

-- 

 //Aho

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

#16307

In article <dg42tuFb6udU1@mid.individual.net>,
 "J.O. Aho" <user@example.net> wrote:

> On 01/18/2016 10:38 AM, crankypuss wrote:
> > Peter H. Coffin wrote:
> > 
> >> On Sun, 17 Jan 2016 15:59:44 -0700, crankypuss wrote:
> >>> It appears that the default memory_limit value is 128M which is way
> >>> too
> >>> small for my purposes.  How can I configure this to a larger value? 
> >>> I'm currently using:
> >>>
> >>> memory_limit=-1
> >> .       ^^^^^^^^^^^^^^^
> >>
> >> goes in your php.ini, not configure.
> > 
> > Yes, so how do I do it from configure?  I do not want to *HAVE* any 
> > php.ini files for this build, it needs to be fully self-contained.
> 
> Then you need to patch the source code, just find the right place and
> change.

That's what I figured. But if the guy has these sorts of requirements, 
I'm sure he has no problem maintaining his own private fork of php.  It 
took me forever to find all the libraries and what not to build the 
mcrypt.so module which doesn't come with Apple's version.  But I did 
figure it out.

If he's got the time, why not?  It's not like *I* have to maintain his 
mess.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]

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

#16309

On 01/19/2016 02:48 AM, Michael Vilain wrote:
> In article <dg42tuFb6udU1@mid.individual.net>,
>  "J.O. Aho" <user@example.net> wrote:
> 
>> On 01/18/2016 10:38 AM, crankypuss wrote:
>>> Peter H. Coffin wrote:
>>>
>>>> On Sun, 17 Jan 2016 15:59:44 -0700, crankypuss wrote:
>>>>> It appears that the default memory_limit value is 128M which is way
>>>>> too
>>>>> small for my purposes.  How can I configure this to a larger value? 
>>>>> I'm currently using:
>>>>>
>>>>> memory_limit=-1
>>>> .       ^^^^^^^^^^^^^^^
>>>>
>>>> goes in your php.ini, not configure.
>>>
>>> Yes, so how do I do it from configure?  I do not want to *HAVE* any 
>>> php.ini files for this build, it needs to be fully self-contained.
>>
>> Then you need to patch the source code, just find the right place and
>> change.
> 
> That's what I figured. But if the guy has these sorts of requirements, 
> I'm sure he has no problem maintaining his own private fork of php.  It 
> took me forever to find all the libraries and what not to build the 
> mcrypt.so module which doesn't come with Apple's version.  But I did 
> figure it out.
> 
> If he's got the time, why not?  It's not like *I* have to maintain his 
> mess.
> 
No, but you have to see the next thread, and the next one and the next
one, regarding the mess he is creating himself.

-- 

 //Aho

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

#16310

J.O. Aho wrote:

> On 01/19/2016 02:48 AM, Michael Vilain wrote:
>> In article <dg42tuFb6udU1@mid.individual.net>,
>>  "J.O. Aho" <user@example.net> wrote:
>> 
>>> On 01/18/2016 10:38 AM, crankypuss wrote:
>>>> Peter H. Coffin wrote:
>>>>
>>>>> On Sun, 17 Jan 2016 15:59:44 -0700, crankypuss wrote:
>>>>>> It appears that the default memory_limit value is 128M which is
>>>>>> way too
>>>>>> small for my purposes.  How can I configure this to a larger
>>>>>> value? I'm currently using:
>>>>>>
>>>>>> memory_limit=-1
>>>>> .       ^^^^^^^^^^^^^^^
>>>>>
>>>>> goes in your php.ini, not configure.
>>>>
>>>> Yes, so how do I do it from configure?  I do not want to *HAVE* any
>>>> php.ini files for this build, it needs to be fully self-contained.
>>>
>>> Then you need to patch the source code, just find the right place
>>> and change.
>> 
>> That's what I figured. But if the guy has these sorts of
>> requirements,
>> I'm sure he has no problem maintaining his own private fork of php. 
>> It took me forever to find all the libraries and what not to build
>> the
>> mcrypt.so module which doesn't come with Apple's version.  But I did
>> figure it out.
>> 
>> If he's got the time, why not?  It's not like *I* have to maintain
>> his mess.
>> 
> No, but you have to see the next thread, and the next one and the next
> one, regarding the mess he is creating himself.

Now boys, let's play nice together.  It's not as though I'm going to do 
anything with a patched version of PHP other than use it as a tool to 
move forward.  I've already seen too much of the PHP source to consider 
doing much else with it.

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

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

#16306

crankypuss schrieb am 2016-01-18 um 10:38:

> Peter H. Coffin wrote:
> 
>> On Sun, 17 Jan 2016 15:59:44 -0700, crankypuss wrote:
>>> It appears that the default memory_limit value is 128M which is way
>>> too
>>> small for my purposes.  How can I configure this to a larger value? 
>>> I'm currently using:
>>>
>>> memory_limit=-1
>> .       ^^^^^^^^^^^^^^^
>>
>> goes in your php.ini, not configure.
> 
> Yes, so how do I do it from configure?  I do not want to *HAVE* any 
> php.ini files for this build, it needs to be fully self-contained.

This is not possible.

If you need this, you have check the source code of PHP where the
default memory limit is set and modify this.

> The configure help says "To assign environment variables (e.g., CC, 
> CFLAGS...), specify them as VAR=VALUE.  See below for descriptions of 
> some of the useful variables."  Apparently memory_limit is not one of 
> those.

Yes - because this notice about setting *environment* variables applies
to the C compiler and not to PHP.

> If nobody knows, or there is no way to do it, I'll need to modify the 
> source, so I would appreciate clues in order to avoid that.

You can't avoid that. PHP is not designed to be completely self
contained without any configuration at all.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#16311

Arno Welzel wrote:

> crankypuss schrieb am 2016-01-18 um 10:38:
> 
>> Peter H. Coffin wrote:
>> 
>>> On Sun, 17 Jan 2016 15:59:44 -0700, crankypuss wrote:
>>>> It appears that the default memory_limit value is 128M which is way
>>>> too
>>>> small for my purposes.  How can I configure this to a larger value?
>>>> I'm currently using:
>>>>
>>>> memory_limit=-1
>>> .       ^^^^^^^^^^^^^^^
>>>
>>> goes in your php.ini, not configure.
>> 
>> Yes, so how do I do it from configure?  I do not want to *HAVE* any
>> php.ini files for this build, it needs to be fully self-contained.
> 
> This is not possible.

<snort>

> If you need this, you have check the source code of PHP where the
> default memory limit is set and modify this.
> 
>> The configure help says "To assign environment variables (e.g., CC,
>> CFLAGS...), specify them as VAR=VALUE.  See below for descriptions of
>> some of the useful variables."  Apparently memory_limit is not one of
>> those.
> 
> Yes - because this notice about setting *environment* variables
> applies to the C compiler and not to PHP.
> 
>> If nobody knows, or there is no way to do it, I'll need to modify the
>> source, so I would appreciate clues in order to avoid that.
> 
> You can't avoid that. PHP is not designed to be completely self
> contained without any configuration at all.

Then it's not designed at all, it's just an accumulation of hacks.

Geez, I've got to be making all kinds of friends here, huh? <g>

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

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

#16312

crankypuss wrote:

> Arno Welzel wrote:
> 
>> crankypuss schrieb am 2016-01-18 um 10:38:
>> 
>>> Peter H. Coffin wrote:
>>> 
>>>> On Sun, 17 Jan 2016 15:59:44 -0700, crankypuss wrote:
>>>>> It appears that the default memory_limit value is 128M which is
>>>>> way too
>>>>> small for my purposes.  How can I configure this to a larger
>>>>> value? I'm currently using:
>>>>>
>>>>> memory_limit=-1
>>>> .       ^^^^^^^^^^^^^^^
>>>>
>>>> goes in your php.ini, not configure.
>>> 
>>> Yes, so how do I do it from configure?  I do not want to *HAVE* any
>>> php.ini files for this build, it needs to be fully self-contained.
>> 
>> This is not possible.
> 
> <snort>

The patch to update main.c and increase the default memory limit is 
below.  If I cared enough to jump into the .configure cesspool it might 
be easy to set *any* of the initial values through .configure 
parameters.  "not possible" my ass.

I think the bottom line, at least imo, is that PHP is not a language, 
it's a fancy syntax front-ending a kludge of kitchen-sinks that might 
possibly have something to do with generating web pages.

IF it was a language, it would be easy to isolate the actual language 
aspects from the configuration hacks.

>> If you need this, you have check the source code of PHP where the
>> default memory limit is set and modify this.
>> 
>>> The configure help says "To assign environment variables (e.g., CC,
>>> CFLAGS...), specify them as VAR=VALUE.  See below for descriptions
>>> of
>>> some of the useful variables."  Apparently memory_limit is not one
>>> of those.
>> 
>> Yes - because this notice about setting *environment* variables
>> applies to the C compiler and not to PHP.
>> 
>>> If nobody knows, or there is no way to do it, I'll need to modify
>>> the source, so I would appreciate clues in order to avoid that.
>> 
>> You can't avoid that. PHP is not designed to be completely self
>> contained without any configuration at all.
> 
> Then it's not designed at all, it's just an accumulation of hacks.
> 
> Geez, I've got to be making all kinds of friends here, huh? <g>

Here's the patch to increase memory_limit from 128M to 1G:

--- /USERDATA/lnk/appsReleasedStable/frozen-or-
modified/PHP/php-5.6.17.~1~/main/main.c
+++ /USERDATA/lnk/appsReleasedStable/frozen-or-
modified/PHP/php-5.6.17/main/main.c
@@ -620,7 +620,7 @@
 	STD_PHP_INI_BOOLEAN("mail.add_x_header",			
"0",		PHP_INI_SYSTEM|PHP_INI_PERDIR,		
OnUpdateBool,			mail_x_header,			
php_core_globals,	core_globals)
 	STD_PHP_INI_ENTRY("mail.log",					
NULL,		PHP_INI_SYSTEM|PHP_INI_PERDIR,		
OnUpdateMailLog,			mail_log,			
php_core_globals,	core_globals)
 	PHP_INI_ENTRY("browscap",					
NULL,		PHP_INI_SYSTEM,		OnChangeBrowscap)
-	PHP_INI_ENTRY("memory_limit",				
"128M",		PHP_INI_ALL,		OnChangeMemoryLimit)
+	PHP_INI_ENTRY("memory_limit",				
"1G",		PHP_INI_ALL,		OnChangeMemoryLimit)
 	PHP_INI_ENTRY("precision",					
"14",		PHP_INI_ALL,		OnSetPrecision)
 	PHP_INI_ENTRY("sendmail_from",				
NULL,		PHP_INI_ALL,		NULL)
 	PHP_INI_ENTRY("sendmail_path",	DEFAULT_SENDMAIL_PATH,	
PHP_INI_SYSTEM,		NULL)


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

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

#16314

crankypuss schrieb am 2016-01-19 um 11:54:

> crankypuss wrote:
> 
[...]
> The patch to update main.c and increase the default memory limit is 
> below.  If I cared enough to jump into the .configure cesspool it might 
> be easy to set *any* of the initial values through .configure 
> parameters.  "not possible" my ass.
> 
> I think the bottom line, at least imo, is that PHP is not a language, 

It is.

> it's a fancy syntax front-ending a kludge of kitchen-sinks that might 
> possibly have something to do with generating web pages.

Well - some see it this way, yes. Especially when you take into account
all the strange things PHP collected in it's long way from the
collection of a bunch of Pearl scripts called "personal homepage
processor" (PHP/FI) to the latest versions where the "PHP" just does not
mean anything special any longer.

But this would be true even if PHP could be used as totally self
contained binary as the quality of PHP itself would not be better then.

> IF it was a language, it would be easy to isolate the actual language 
> aspects from the configuration hacks.

You mix up "runtime environment" with "programming language".

Even your C compiler does not run without some configuration and the
proper environment. So you call C not a programming language then?


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#16315

Arno Welzel wrote:

> crankypuss schrieb am 2016-01-19 um 11:54:
> 
>> crankypuss wrote:
>> 
> [...]
>> The patch to update main.c and increase the default memory limit is
>> below.  If I cared enough to jump into the .configure cesspool it
>> might be easy to set *any* of the initial values through .configure
>> parameters.  "not possible" my ass.
>> 
>> I think the bottom line, at least imo, is that PHP is not a language,
> 
> It is.
> 
>> it's a fancy syntax front-ending a kludge of kitchen-sinks that might
>> possibly have something to do with generating web pages.
> 
> Well - some see it this way, yes. Especially when you take into
> account all the strange things PHP collected in it's long way from the
> collection of a bunch of Pearl scripts called "personal homepage
> processor" (PHP/FI) to the latest versions where the "PHP" just does
> not mean anything special any longer.
> 
> But this would be true even if PHP could be used as totally self
> contained binary as the quality of PHP itself would not be better
> then.
> 
>> IF it was a language, it would be easy to isolate the actual language
>> aspects from the configuration hacks.
> 
> You mix up "runtime environment" with "programming language".

I simply note that they are mixed together almost-irextricably within 
PHP.

> Even your C compiler does not run without some configuration and the
> proper environment. So you call C not a programming language then?

Anything that supports includes or conditional-compilation is 
unacceptable and valuable primarily as an agent of its own replacement, 
imo.  Besides, have you taken an objective look at C syntax lately?  
Even one of its authors did not much like its syntax, though I forget 
which it was who complained about it years/decades after the fact.

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

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

#16317

crankypuss schrieb am 2016-01-19 um 22:38:

> Arno Welzel wrote:
> 
[...]
>> You mix up "runtime environment" with "programming language".
> 
> I simply note that they are mixed together almost-irextricably within 
> PHP.

Which does not change the fact, that PHP is a programming language.

>> Even your C compiler does not run without some configuration and the
>> proper environment. So you call C not a programming language then?
> 
> Anything that supports includes or conditional-compilation is 
> unacceptable and valuable primarily as an agent of its own replacement, 
> imo.  Besides, have you taken an objective look at C syntax lately?  
> Even one of its authors did not much like its syntax, though I forget 
> which it was who complained about it years/decades after the fact.

Are you sure that you don't talk about C++?

And BTW: If you don't like all this stuff, why do you use it then? And
which language would be acceptable for you? ECMAScript? Java? C#?


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#16313

crankypuss schrieb am 2016-01-19 um 10:39:

> Arno Welzel wrote:
> 
>> crankypuss schrieb am 2016-01-18 um 10:38:
[...]
>>> If nobody knows, or there is no way to do it, I'll need to modify the
>>> source, so I would appreciate clues in order to avoid that.
>>
>> You can't avoid that. PHP is not designed to be completely self
>> contained without any configuration at all.
> 
> Then it's not designed at all, it's just an accumulation of hacks.

Which applies to most runtime environments of this kind since the
"totally self contained" use case is usually never required. What's the
problem of putting a php.ini beside the PHP binary?

You may have a misconception of what PHP was originally created for. PHP
was created to run scripts on a web server - and usually a web server
based on Apache, nginx etc. is also not a single file you just throw
somewhere and you're good to go.

But as the source is available feel free to build your own version which
does whatever you need.

> Geez, I've got to be making all kinds of friends here, huh? <g>

I don't care what you do and if you call PHP "an accumulation of hacks"
just because the runtime requires a configuration file. I did not create
PHP - I just use it where neccessary.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#16316

Arno Welzel wrote:

> crankypuss schrieb am 2016-01-19 um 10:39:
> 
>> Arno Welzel wrote:
>> 
>>> crankypuss schrieb am 2016-01-18 um 10:38:
> [...]
>>>> If nobody knows, or there is no way to do it, I'll need to modify
>>>> the source, so I would appreciate clues in order to avoid that.
>>>
>>> You can't avoid that. PHP is not designed to be completely self
>>> contained without any configuration at all.
>> 
>> Then it's not designed at all, it's just an accumulation of hacks.
> 
> Which applies to most runtime environments of this kind since the
> "totally self contained" use case is usually never required. What's
> the problem of putting a php.ini beside the PHP binary?

I don't see any need for a config file, all that stuff gets read in 
during startup and replaces default values set by the build.

The objective of this little sub-project is to have a one-lump-
application written in PHP, that runs under any linux distro, whether 
PHP is installed or not.  Originally I was thinking of modifying main() 
so that it would determine how large the actual module is, then read the 
remainder of the executable file and use that as it's PHP source.  I 
might still go with that approach, undetermined yet, but if I do I'll 
need to strip some of the extraneous funtionality out.

> You may have a misconception of what PHP was originally created for.
> PHP was created to run scripts on a web server - and usually a web
> server based on Apache, nginx etc. is also not a single file you just
> throw somewhere and you're good to go.
> 
> But as the source is available feel free to build your own version
> which does whatever you need.

Why thank you.  I'm still a bit unclear about how "free" the 
distribution of binaries is, what's actually required, etc.  I'll figure 
it out.

>> Geez, I've got to be making all kinds of friends here, huh? <g>
> 
> I don't care what you do and if you call PHP "an accumulation of
> hacks" just because the runtime requires a configuration file. I did
> not create PHP - I just use it where neccessary.

Then you're a happy camper!  Good deal. <g>

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

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

#16318

crankypuss schrieb am 2016-01-19 um 23:25:

> Arno Welzel wrote:
> 
>> crankypuss schrieb am 2016-01-19 um 10:39:
>>
>>> Arno Welzel wrote:
>>>
>>>> crankypuss schrieb am 2016-01-18 um 10:38:
>> [...]
>>>>> If nobody knows, or there is no way to do it, I'll need to modify
>>>>> the source, so I would appreciate clues in order to avoid that.
>>>>
>>>> You can't avoid that. PHP is not designed to be completely self
>>>> contained without any configuration at all.
>>>
>>> Then it's not designed at all, it's just an accumulation of hacks.
>>
>> Which applies to most runtime environments of this kind since the
>> "totally self contained" use case is usually never required. What's
>> the problem of putting a php.ini beside the PHP binary?
> 
> I don't see any need for a config file, all that stuff gets read in 
> during startup and replaces default values set by the build.
> 
> The objective of this little sub-project is to have a one-lump-
> application written in PHP, that runs under any linux distro, whether 
> PHP is installed or not.  Originally I was thinking of modifying main() 
> so that it would determine how large the actual module is, then read the 
> remainder of the executable file and use that as it's PHP source.  I 
> might still go with that approach, undetermined yet, but if I do I'll 
> need to strip some of the extraneous funtionality out.

Than you also have to link every library statically to the PHP binary
and omit nearly every extension - otherwise the binary may depend on
certain runtime libaries which are not found on the distribution or they
are not provided in the right version.

Well - I think it's easier to use shell scripts then ;-).

[...]
>> But as the source is available feel free to build your own version
>> which does whatever you need.
> 
> Why thank you.  I'm still a bit unclear about how "free" the 
> distribution of binaries is, what's actually required, etc.  I'll figure 
> it out.

See <https://secure.php.net/license/> and
<https://secure.php.net/license/distrib-guidelines-code.php>.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#16319

Arno Welzel wrote:

> crankypuss schrieb am 2016-01-19 um 23:25:
> 
>> Arno Welzel wrote:
>> 
>>> crankypuss schrieb am 2016-01-19 um 10:39:
>>>
>>>> Arno Welzel wrote:
>>>>
>>>>> crankypuss schrieb am 2016-01-18 um 10:38:
>>> [...]
>>>>>> If nobody knows, or there is no way to do it, I'll need to modify
>>>>>> the source, so I would appreciate clues in order to avoid that.
>>>>>
>>>>> You can't avoid that. PHP is not designed to be completely self
>>>>> contained without any configuration at all.
>>>>
>>>> Then it's not designed at all, it's just an accumulation of hacks.
>>>
>>> Which applies to most runtime environments of this kind since the
>>> "totally self contained" use case is usually never required. What's
>>> the problem of putting a php.ini beside the PHP binary?
>> 
>> I don't see any need for a config file, all that stuff gets read in
>> during startup and replaces default values set by the build.
>> 
>> The objective of this little sub-project is to have a one-lump-
>> application written in PHP, that runs under any linux distro, whether
>> PHP is installed or not.  Originally I was thinking of modifying
>> main() so that it would determine how large the actual module is,
>> then read the
>> remainder of the executable file and use that as it's PHP source.  I
>> might still go with that approach, undetermined yet, but if I do I'll
>> need to strip some of the extraneous funtionality out.
> 
> Than you also have to link every library statically to the PHP binary
> and omit nearly every extension - otherwise the binary may depend on
> certain runtime libaries which are not found on the distribution or
> they are not provided in the right version.

Yes, it's a fugly task, probably easier to start with a blank page of C-
code.

> Well - I think it's easier to use shell scripts then ;-).
> 
> [...]
>>> But as the source is available feel free to build your own version
>>> which does whatever you need.
>> 
>> Why thank you.  I'm still a bit unclear about how "free" the
>> distribution of binaries is, what's actually required, etc.  I'll
>> figure it out.
> 
> See <https://secure.php.net/license/> and
> <https://secure.php.net/license/distrib-guidelines-code.php>.

Thanks.

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

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

#16320

Arno Welzel wrote:

> crankypuss schrieb am 2016-01-19 um 23:25:
>> I don't see any need for a config file, all that stuff gets read in
>> during startup and replaces default values set by the build.
>> 
>> The objective of this little sub-project is to have a one-lump-
>> application written in PHP, that runs under any linux distro, whether
>> PHP is installed or not.  Originally I was thinking of modifying main()
>> so that it would determine how large the actual module is, then read the
>> remainder of the executable file and use that as it's PHP source.  I
>> might still go with that approach, undetermined yet, but if I do I'll
>> need to strip some of the extraneous funtionality out.
> 
> Than you also have to link every library statically to the PHP binary

I am not sure about that; it may be possible to set LD_LIBRARY_PATH just for 
the php(1) invocation.

> and omit nearly every extension - otherwise the binary may depend on
> certain runtime libaries which are not found on the distribution or they
> are not provided in the right version.
> 
> Well - I think it's easier to use shell scripts then ;-).

Apropos, there are several ways to run php(1) without the system’s php.ini:

-c  specifies the php.ini file to use; you can write a temporary php.ini to
    ${TMPDIR:-/tmp} (using mktemp(1)) when invoking php(1) in case named
    pipes, with which you can generate a php.ini on the fly (see example
    below), are not supported;

-n  specifies that no php.ini file is used, falling back to the compiled 
    defaults; try e.g. “php -n -r 'phpinfo(INFO_GENERAL);'”

-d  allows to set php.ini directives on the command line, so with “-n”
    you do not need the workaround with “-c”.

Example:

$ ls Application.php
ls: cannot access Application.php: No such file or directory

$ php -c <(echo 'include_path = /LCARS/scripts/php') \
      -r 'require_once "Application.php";'
[no error]

  or

$ php -n -d include_path=/LCARS/scripts/php \
         -r 'require_once "Application.php";'
[no error]

See also: php --help
 
-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#16302

crankypuss schrieb am 2016-01-17 um 23:59:

> It appears that the default memory_limit value is 128M which is way too 
> small for my purposes.  How can I configure this to a larger value?  I'm 
[...]

You can't configure this at compile time - as most of the other options
which are set in php.ini.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#16304

Arno Welzel wrote:

> crankypuss schrieb am 2016-01-17 um 23:59:
> 
>> It appears that the default memory_limit value is 128M which is way
>> too
>> small for my purposes.  How can I configure this to a larger value? 
>> I'm
> [...]
> 
> You can't configure this at compile time - as most of the other
> options which are set in php.ini.

Thank you, I'll just go into the source and set them there since it's 
that kind of POS.

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web