apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mo DeJong <mdej...@cygnus.com>
Subject Re: Patch to fix dirs when builddir != srcdir
Date Fri, 15 Dec 2000 23:11:30 GMT
On Fri, 15 Dec 2000, Mo DeJong wrote:

> On Fri, 15 Dec 2000, Sascha Schumann wrote:
> > On Fri, 15 Dec 2000, Mo DeJong wrote:
> > 
> > > Hello.
> > >
> > > Here is a small patch that fixes up a couple of problems that
> > > cause the configure script to break when run in a build
> > > directory that is not the same as the source directory.
> > > It also uses $MKDIR not $MKDIR -p, the -p thing is an
> > > error, it ends up making a directory named -p in the
> > > build dir.
> > 
> >     Applied.  I've also taken the chance to fix some other VPATH
> >     issues, so that APR builds now cleanly in a separate
> >     directory.  Thanks,
> > 
> >     - Sascha

This is a quick followup to my last message. I am now seeing
build problems when srcdir != builddir in the apr/shmem/unix/mm
and apr/shmem/unix dirs.

If I run from the toplevel, the error looks like:

make[1]: Entering directory `/usr/local/project/build/apr/shmem/unix'
gcc -DLINUX=2 -pthread  -D_REENTRANT  -c -I../../include 
-I/home/mo/project/subversion/apr/shmem/unix/../../include -Imm 
rm -f libshmem.a
(cd mm && make libmm.la)
make[2]: Entering directory `/usr/local/project/build/apr/shmem/unix/mm'
make[2]: `/home/mo/project/subversion/apr/shmem/unix/mm/libmm.la' is up 
to date.
make[2]: Leaving directory `/usr/local/project/build/apr/shmem/unix/mm'
cp mm/mm_global.o mm/mm_alloc.o mm/mm_core.o mm/mm_lib.o mm/mm_vers.o .
cp: mm/mm_global.o: No such file or directory
cp: mm/mm_alloc.o: No such file or directory
cp: mm/mm_core.o: No such file or directory
cp: mm/mm_lib.o: No such file or directory
cp: mm/mm_vers.o: No such file or directory
make[1]: *** [libshmem.a] Error 1
make[1]: Leaving directory `/usr/local/project/build/apr/shmem/unix'
make: *** [subdirs] Error 1

If you run in the apr/shmem/unix/mm dir, the error looks like:

mo(~/project/build/apr/shmem/unix/mm)% make
V1=`./shtool version -l c -d short mm_vers.c`; \
V2=`./shtool version -l c -d long mm_vers.c`; \
D=`./shtool version -l c -d long mm_vers.c | sed -e 's;.*(;;' -e 
's;).*;;'`; \
pod2man --section=1 --center="Shared Memory Library" --release="$D" 
--date="MM $V1" mm-config.pod |\
perl -p -e 
's;^(\\\&\s+.+?)([Mm][Mm]_[a-zA-Z0-9_]+)(\(.+?)$;$1\\fB$2\\fR$3;' |\
sed -e "s;MM_VERSION_STR;$V2;" >mm-config.1
can't open mm-config.pod: No such file or directory at /usr/bin/pod2man 
line 403.
./libtool --quiet --mode=compile gcc -c -DLINUX=2 
-I/home/mo/project/subversion/apr/shmem/unix/mm/ -I. 
./libtool --quiet --mode=link gcc -o mm_test mm_test.lo libmm.la
libtool: link: `libmm.la' is not a valid libtool archive
make: *** [mm_test] Error 1

After some poking around, I found that this error was
caused by the fact that I had also configured
and built apr in the src dir. Doing a "make distclean"
in the srcdir fixed things.

But, this raised another question, why on earth is perl
required just to build the package? This seems like a
major mistake. The build process should not require
anything other than sh, sed, and a couple of other utils
like uname. Putting in a dep for Perl, Python, Tcl, or
any other scripting language is a big mistake.

The good news is that I was able to build apr in a
build dir for the first time (Yeah!)

Mo DeJong
Red Hat Inc

View raw message