Port-amiga archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Time to fix the memory allocation on port-amiga




> For a while I've written about how a 256 meg Amiga system can't access
> enough memory properly. For the purposes of running a bulk package build,
> I've compiled a kernel for my A1200 which only uses 128 megs. However, now
> it seems that even 128 meg systems are having problems. At various places
> in a build of lang/php53 on a 127 meg Amiga 4000, I'm seeing "virtual
> memory exhausted: Cannot allocate memory" messages.

  I was going to ask what file the compile was failing on, and how much
virtual memory it was using when it failed.  I got my A4000 updated to
5.1, updated my pkgsrc, and started building php53.  I was watching
process virtual memory usage and noted that a couple of compiles were
reaching around 90MB, until it hit ext/fileinfo/libmagic/apprentice.c.
That one took at least 190MB.  Looking at it, I saw that it was including
a data file that appears to be a 1.7MB character array.  Later, I say your
post to tech-pkg, which included the failing command.

  The maximum address space for user processes on the amiga has been
224MB, with 32MB for stack and 6MB for text.  That leaves 186MB for data
and shared libraries - which isn't going to work.

  I have increased the USRSTACK setting to allow 480MB of user address
space (any higher, and 68040 system will crash when trying to allocate
more than that amount of address space).  That will allow php53 to build
on the amiga.

  I was searching for information about php failing on that file and found
this little amusing gem:

 [2009-07-05 17:08 UTC] rasmus%php.net@localhost
 We know that file takes quite a bit of memory to compile on older versions of 
gcc.
 It should be better in newer versions though.  Not much we can do about this.  
We
 aren't going to change perfectly valid code just because some older compilers
 have trouble with it.

 [2009-07-05 17:24 UTC] ibboard at gmail dot com
 "Quite a bit" of memory? That seems like a bit of an understatement when it 
will
 quite happily consume over 350MB of memory on a single file and previous 
versions
 of PHP could be compiled in ~150MB or less (albeit without that extension) :D
 Maybe libmagic needs disabling as a default module if it was in PECL before and
 is known to causes problems with older compilers? How much memory am I expected
 to need to compile it if it fails with 350MB? I've just watched 'top' while the
 compile continued and it maxed out at ~120MB without libmagic, which is far 
more
 reasonable.

 [2009-07-05 19:48 UTC] rasmus%php.net@localhost
 It is probably up in the 600-700M range.  If you are using an older toolchain 
in
 a severely memory-starved environment, you shouldn't expect to be able to 
compile
 everyCthing there.  Why not simply cross-compile from a real dev box somewhere
 and copy the binaries over?  You can install your production OS in a vm slice 
on
 whatever home machine you have and compile there.

 [2009-07-05 20:46 UTC] scottmac%php.net@localhost
 What version of gcc were you using? It would be nice to track this where 
possible.

 [2009-07-05 20:49 UTC] scottmac%php.net@localhost
 What version of gcc were you using? It would be nice to track this where 
possible.

 [2010-06-21 20:32 UTC] mackeul at gmail dot com
 Ran into the same problem with GCC 3.4.5 on a "2.6.9-34.EL #1 Fri Feb 24 
16:44:51
 EST 2006 i686 i686 i386 GNU/Linux" machine with 256MB of memory.

 [2010-11-16 07:52 UTC] info at fedushin dot ru
 Adding --disable-fileinfo to ./configure solves the problem.

Mike


Home | Main Index | Thread Index | Old Index