Georg Lutz writes:
-I./../../afx -I./../../courier/libs -I./../../authlib -MD esmtpclient.d
-MF .deps/esmtpclient.Tpo -MP -MT esmtpclient.o -MQ esmtpclient.o
-DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 esmtpclient.c -quiet -dumpbase
esmtpclient.c -m32 -march=i386 -mtune=generic -auxbase-strip
esmtpclient.o -g -O2 -Wall -Wall -fexceptions -fstack-protector
-fasynchronous-unwind-tables --param ssp-buffer-size=4 -o -
---
Has anyone else encoutered this problem too?
I suppose that its a bug in gcc somewhere. I just can't imagine why I
would need so much memory for just compiling esmtpclient.c .
I do not recognize where the -auxbase-strip and -dumpbase flags come from.
The others I recognize from the default RPM configuration in Fedora.
Check your compile environment to track down where these two options come
from. It might be a false alarm: I do have a very, very dim memory that
occasionally -- not every time but occasionally -- I do notice gcc taking a
few more seconds than usual to compile that file. But my main builds are on
an 2xOpteron with 2GB of RAM.
Since all this code is under the GPL, there's no harm in asking the gcc
devels if they're interested in grabbing the entire tarball, running
configure with your args, then just running 'make esmtpclient.o' and see
what pops out.
2 messages in net.sourceforge.lists.courier-usersRe: [courier-users] compile issues un...
