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

Re: Handling the new Apache chroot



On Tue, Nov 05, 2002 at 05:32:36PM -0800, Marc Matteo wrote:
> 
> I went for static with sysutils/nut.  It was far simpler that way.
> 
> What kind of problems are you having?  Does the main daemon need to be
> static?  Usually only the CGIs need to be static.

Hi Marc,

	I'm starting to think that perhaps the main daemon
should be running in normal userland, and the CGI's running
statically from the chroot.  The only rub I see with that one
is that there is a named pipe that both processes need to
talk to.  But, I guess the daemon would be able to talk to
it from outside of the chroot.

	As for the problems I'm having compiling the CGI's
statically, they are having problems with undefined symbols
when I try using the '-static' flag in CFLAGS.  Any of the
CGI programs that try to link against the following libs:

libgd
libpng
libm
libjpeg
libz

	.. bomb out with the following types of errors:

pngrtran.o: Undefined symbol `_pow' referenced from text segment
pngrtran.o: Undefined symbol `_pow' referenced from text segment
pngrtran.o: Undefined symbol `_pow' referenced from text segment
pngrtran.o: Undefined symbol `_pow' referenced from text segment
pngrtran.o: Undefined symbol `_pow' referenced from text segment
pngrtran.o: Undefined symbol `_pow' referenced from text segment
pngrtran.o: Undefined symbol `_pow' referenced from text segment
pngrtran.o: Undefined symbol `_pow' referenced from text segment
pngrtran.o: Undefined symbol `_pow' referenced from text segment
pngrtran.o: More undefined symbol _pow refs follow
png.o: Undefined symbol `_crc32' referenced from text segment
png.o: Undefined symbol `_crc32' referenced from text segment
collect2: ld returned 1 exit status

	Looking at the Makefile, the actual line it's dying on is:

statusmap.cgi: statusmap.c $(CGIDEPS) $(EDATADEPS)
        $(CC) $(CFLAGS) $(LDFLAGS) statusmap.c $(CGILIBS) $(GDLIBS) $(EDATALIBS)
 -o $@

	Which is translating to, during build:

gcc -static -O2 -I/usr/local/include -DHAVE_CONFIG_H -DNSCGI -L/usr/local/lib statusmap.c getcgi.o cgiutils.o auth.o popen.o  ../common/objects.c ../xdata/xodtemplate.c ../common/statusdata.c ../xdata/xsddefault.c -lgd -lz -lm -lpng -ljpeg edata.o ../xdata/xedtemplate.c -o statusmap.cgi

	libgd, libpng, and libjpeg were all built from the ports
tree, 3.2-STABLE as of this morning (sorry about line wraps above).
I know that lib order is important (although, I don't know exactly
why yet), so when I move '-lm' to the end of the line, the only
errors that appear are:

png.o: Undefined symbol `_crc32' referenced from text segment
png.o: Undefined symbol `_crc32' referenced from text segment
collect2: ld returned 1 exit status
*** Error code 1

	Which, I assume, is progress.  :)  I've tried juggling the
order of the libs further, but this is the closest to success I've
seen so far.

	Thanks very much for your quick response, and any suggestions
are welcome.  I'm not a developer (I'm a sysadmin), but I'm quite
determined to learn how to do this correctly.  :)

Benny


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There's always time for Cheerios...



Visit your host, monkey.org