Philip Brown wrote: > On Mon, Jul 06, 2009 at 05:34:51PM +0200, Sebastian Kayser wrote: >> Trussing the acomp shows a myriad of brk()s and the process hogs >> memory like there is no tomorrow. >> >> PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP >> 29072 skayser 684M 670M cpu13 30 0 0:01.23 3.1% acomp/1 > > yes. this is known behaviour of cc. > (although I havent seen it with libiconv specifically) > > certain obscure optimization cases, explode, so to speak, taking extreme > memory usage and disk space for it to "traverse the problem space", if you > will. > > Your choices are: > > a) wait for a long time, and it will eventually complete, if the machine > doesnt run out of resources > > b) reduce the optimization flags to -xO2 or -xO3
Thanks for your feedback Phil. Reducing to -xO2 or -xO3 didn't help though. Now comes the fun part. When i keep the --fast --xnolibmopt flags as they are and run the configure command that GAR would issue manually, it completes just fine :/ There is someone over at the OpenSolaris forums who has observed something similar. cc hanging when invoked from make, but fine on its own [1]. Unfortunately, neither the forum thread nor the referenced bug entry [2] help with a working solution. Sebastian [1] http://opensolaris.org/jive/thread.jspa?messageID=209219 [2] http://bugs.sun.com/view_bug.do?bug_id=6668199 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers
