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