Re: Wierd PETSc build behavior...

[Adam C Powell IV <hazelsct@mit.edu>]

Steve Langasek wrote:

> Hi Adam,
>
> On Tue, 27 Feb 2001, Adam C Powell IV wrote:
>
> > > Have you copied the -L option verbatim?  If so, the error is clear:
> > > there's no $ between the -L and the {.  Otherwise, I have no idea.
>
> > I'm sorry, I was very imprecise.  Here are the details:
>
> > # For mpich: (woody mpich uses /usr/lib/mpich/lib, potato the longer dir)
> > ifeq ($(PETSC_MPI),mpich)
> >   MPI_HOME       = /usr/lib/mpich
> >   MPI_LIB        = -L${MPI_HOME}/lib -L${MPI_HOME}/build/LINUX/ch_p4/lib -lmpich
> > MPIRUN         = /usr/bin/mpirun.mpich -machinefile /etc/mpich/machines.LINUX
> >   MPI_INCLUDE    = -I/usr/lib/mpich/include -I/usr/lib/mpich/build/LINUX/ch_p4/include
> > endif
>
> > And the output from the top-level info: target:
>
> > [snip]
> > Using C linker: gcc -O2 -Wall -Wshadow  -fomit-frame-pointer
> > -L/usr/home/hazelsct/petsc/petsc-2.0.29/lib/libO/linux_ppc
> > Using Fortran linker: g77 -O2
> > -L/usr/home/hazelsct/petsc/petsc-2.0.29/lib/libO/linux_ppc
> > Using libraries: -L/usr/home/hazelsct/petsc/petsc-2.0.29/lib/libO/linux_ppc
> > -lpetscts -lpetscsnes  -lpetscsles -lpetscdm -lpetscmat -lpetscvec
> > -L/usr/home/hazelsct/petsc/petsc-2.0.29/lib/libO/linux_ppc -lpetsc
> > -L{MPI_HOME}/build/LINUX/ch_p4/lib -lmpe
> > -lpmpich                                               -L/usr/X11R6/lib
> > -lX11             -llapack -blas -L/usr/lib/mpich/lib
> > -L/usr/lib/mpich/build/LINUX/ch_p4/lib -lmpich -ldl -lc -lg2c -lm
> > ==========================================
> > [snip]
>
> > Note the -L{MPI_HOME}/build/...
>
> > Okay, what's really odd, is that the installed -dev packages on the alpha with the
> > same bmake files as the source package (just diffed them) work fine, but when I
> > try to build new packages it screws up!  That's really bizarre.  (Yes, I've
> > confirmed that during the package build, PETSC_DIR points to the source directory,
> > not /usr/lib/petsc of the installed package.  That too is printed by the info:
> > target, and shows up in the -L flags above.)
>
> You mention bmake (as opposed to 'make'), and I'm not sure what that is, so my
> comments may not actually apply

bmake is a directory name, nothing more.

> but it looks like what you need to do here
> is reference another makefile variable called MPI_HOME.

Yup.

> The way to this is
> with the syntax $(MPI_HOME) -- note the parens in place of braces.  I believe
> ${MPI_HOME} references a non-existent /environment/ variable.  (Elsewhere the
> braces may indeed be correct, since you mention the use of multiple makefiles,
> but if you need to reference a Makefile variable set in the same file, you
> should normally use parentheses.)

I see.  So something has changed recently in unstable such that braces don't always work
any more?  I usually use parentheses myself, but upstream has braces all over the place-
I assumed they were interchangable (okay, so I'm a "make" newbie :-).

So why do braces work everywhere else in the makefile and all of the included files?  Why
do they fail in exactly the same place on every architecture?  Do I need to do a massive
global search and replace to switch braces to parentheses everywhere??

I can't find anything relevant in the make info page either...

Zeen,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

                   Welcome to the best software in the world today cafe!