On Mon, Aug 5, 2013 at 5:24 PM, Ilya Chernykh wrote:

Hi! I have got the following message when building a package in Factory:

cc1plus: out of memory allocating 3355443200 bytes after a total of 757760 bytes

This happens only with 586, but not under x86-64 architecture where the package builds well.

What should I do?

It seems g++ doesn't have enough address space to do the build. It's either a bug somewhere, or, most likely, simply an app that needs more RAM that can be addressed on a 32-bit kernel (which is usually split 3G for userspace, 1G for kernel). Mind you, that number is 3.1G You can: 1. Take it up with upstream, maybe there's something in the source that pushes the limit of the compiler, and the issue could be worked around. 2. Remove optimization options that take up a lot of RAM, for the compilation unit in question. Linking is a stage where this usually happens, and there's an option explicitly for that in GCC. 3. Decree 586 is no longer supported Well, in all fairness, there's a fourth and fifth option, but I don't think those are viable in OBS: 4. Run a customized kernel with more RAM for userspace. I think 2+2 and 3+1 are the only options, which would preclude this, but maybe they're not. 5. Do a cross build, that is, build an 586 binary with an x86-64 kernel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 06 August 2013 02:46:32 you wrote:

...

cc1plus: out of memory allocating 3355443200 bytes after a total of 757760 bytes

This happens only with 586, but not under x86-64 architecture where the package builds well.

What should I do?

It seems g++ doesn't have enough address space to do the build. It's either a bug somewhere, or, most likely, simply an app that needs more RAM that can be addressed on a 32-bit kernel (which is usually split 3G for userspace, 1G for kernel).

Mind you, that number is 3.1G

You can: 1. Take it up with upstream, maybe there's something in the source that pushes the limit of the compiler, and the issue could be worked around. 2. Remove optimization options that take up a lot of RAM, for the compilation unit in question. Linking is a stage where this usually happens, and there's an option explicitly for that in GCC. 3. Decree 586 is no longer supported

Well, in all fairness, there's a fourth and fifth option, but I don't think those are viable in OBS: 4. Run a customized kernel with more RAM for userspace. I think 2+2 and 3+1 are the only options, which would preclude this, but maybe they're not. 5. Do a cross build, that is, build an 586 binary with an x86-64 kernel

Under 12.3 and earlier it is built well: https://build.opensuse.org/package/show/KDE:KDE3/kdenetwork3 How can I use your proposed options in a package included in the distribution? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Aug 5, 2013 at 8:14 PM, Ilya Chernykh wrote:

...

You can: 1. Take it up with upstream, maybe there's something in the source that pushes the limit of the compiler, and the issue could be worked around. 2. Remove optimization options that take up a lot of RAM, for the compilation unit in question. Linking is a stage where this usually happens, and there's an option explicitly for that in GCC. 3. Decree 586 is no longer supported

Well, in all fairness, there's a fourth and fifth option, but I don't think those are viable in OBS: 4. Run a customized kernel with more RAM for userspace. I think 2+2 and 3+1 are the only options, which would preclude this, but maybe they're not. 5. Do a cross build, that is, build an 586 binary with an x86-64 kernel

Under 12.3 and earlier it is built well:

https://build.opensuse.org/package/show/KDE:KDE3/kdenetwork3

How can I use your proposed options in a package included in the distribution?

Well, first of all, branch it, to work on a home project. You can't take it with upstream I see. There's no upstream (ie: KDE3). So, you could try verifying this can be worked around with compiler flags, by changing the -O2 with an -O0. It won't be good for a package (-O0 being significantly slower), but it will rule out the possibility of turning off the specific optimization rather quickly, if that's not the culprit (ie: if it still breaks, you cannot work around with with compiler flags). You can also see what changed between 12.3 and factory. There's obviously something different between the two that makes it suck up more RAM in Factory. I've had the same issue, of builds taking more RAM in Factory, and I'd guess it's GCC 4.8 that's simply more RAM hungry than 4.7, though I never hit the 3G ceiling. In any case, I did hit an ICE, so I guess 4.8.1 is buggier than 4.7.x. You should dig through GCC bug reports to see if anyone else spotted this, and whether they have a workaround for it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 06 August 2013 03:53:11 Claudio Freire wrote:

So, you could try verifying this can be worked around with compiler flags, by changing the -O2 with an -O0. It won't be good for a package (-O0 being significantly slower), but it will rule out the possibility of turning off the specific optimization rather quickly, if that's not the culprit (ie: if it still breaks, you cannot work around with with compiler flags).

With -O0 it also runs out of memory. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2013-08-06 01:53, Claudio Freire wrote:

...

...

You can: 1. Take it up with upstream, maybe there's something in the source that pushes the limit of the compiler, and the issue could be worked around.

Under 12.3 and earlier it is built well: https://build.opensuse.org/package/show/KDE:KDE3/kdenetwork3

You can't take it with upstream I see. There's no upstream (ie: KDE3).

Upstream would be gcc. If the memory error is reproducible and reproduces on the same file every time, take the command and substitute -c by -E such that you get the preprocessor's output instead. The crash should then be repeatable by using the -c line again when fed the .i file instead. Trim the .i file for as long as the issue happens, and submit the (hopefully small) testcase to the gcc bugtracker. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org