Norman,
So is this actually saying that dist tar balls retrieved by users will
not build unless they install it in to the same place it was originally
built for? (since --prefix is useless unless you have all the dependent
libraries already installed in the default location). This is a worse
situation than we had with the mk build system.
Tim
On Tue, 12 Apr 2005, Norman Gray wrote:
> Steve,
>
> On 2005 Apr 12 , at 15.25, Rankin, SE (Stephen) wrote:
>
> > ./configure --prefix=/stardev2 --with-starlink=/stardev2
> >
> > /stardev2 is the prefix where I am installing and testing the tar.gz
> > files. The build wants to look in the nightly build directory for the
> > SLA library as the original build path is carried over to the configure
> > script and --with-starlink is ignored, I think I have reported similar
> > errors before with other packages:
> >
> > HAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I.
> > -I/home/vmwareshare/rhel30linux_i386/build/build-root/include
> > -I/stardev2/include -fno-second-underscore -g -O2 -c -o opr.o opr.F
> > /bin/sh ./libtool --mode=link g77 -g -O2 -o cocomain dp.o dr2tn.o
> > opw.o prompt.o repra.o repsys.o cocoml.o dqp.o ktest.o par1.o r2dr.o
> > repres.o tran.o cocomain.o opr.o `sla_link`
> > -L/home/vmwareshare/rhel30linux_i386/build/build-root/lib
> > -L/stardev2/lib
> > mkdir .libs
> > g77 -g -O2 -o cocomain dp.o dr2tn.o opw.o prompt.o repra.o repsys.o
> > cocoml.o dqp.o ktest.o par1.o r2dr.o repres.o tran.o cocomain.o opr.o
> > /home/vmwareshare/rhel30linux_i386/build/build-root/lib/libsla.so
> > -L/home/vmwareshare/rhel30linux_i386/build/build-root/lib
> > -L/stardev2/lib -Wl,--rpath
> > -Wl,/home/vmwareshare/rhel30linux_i386/build/build-root/lib -Wl,--rpath
> > -Wl,/home/vmwareshare/rhel30linux_i386/build/build-root/lib
> > /home/vmwareshare/rhel30linux_i386/build/build-root/lib/libsla.so:
> > could
> > not read symbols: Invalid operation
> > collect2: ld returned 1 exit status
> > make: *** [cocomain] Error 1
>
> This is Working, though possibly confusingly, and maybe inadequately.
>
> The --with-starlink is reflected in the -L/starlink2/lib (that doesn't
> come from --prefix).
>
> This directory was bootstrapped with a starconf script (called from
> ./bootstrap) which was configured to make the default prefix
> /home/vmwareshare/rhel30linux_i386/build/build-root.
>
> The --prefix option only controls the _installation_ location, and
> doesn't affect the search path. This is true of standard autoconf-type
> configures also. It's the starconf macros which carefully add this
> prefix to the include and library search paths.
>
> The ways to manipulate this are (1) to './bootstrap --buildsupport' a
> second starconf with /stardev2 as its STARCONF_DEFAULT_PREFIX and
> possibly _STARLINK, or (2) to follow the advice in
> <http://www.astro.gla.ac.uk/users/norman/star/ssn78/ssn78.htx/N-
> a2b2c1.html>. I realise that this says that --prefix `overrides the
> frozen-in value of STARCONF_DEFAULT_PREFIX' -- it does, in the sense
> that --prefix is for specifying an installation location, and it's only
> a starconf feature/extension that it also adjusts these search paths,
> which aren't overridden.
>
> The command `starconf --show --all' shows the defaults that the
> starconf application supplies; `./starconf.status --show --all' shows
> the values that were true the last time starconf was run, for your
> information. If these two are not consistent, then it might be that
> you've changed the path in an odd way at some point; if the latter
> isn't consistent with behaviour of the ./configure script, then I've
> stuffed up (I think).
>
> (2) says that it's possible to change the default installation prefix
> on a per-directory basis, by creating a small acinclude.m4 file just
> before running ./bootstrap or autoreconf. If you're doing this for a
> whole separate tree, however, then perhaps a separately configured
> starconf would be best. Hmm, currently the starconf which is run by
> ./bootstrap is the first one found in the path. I could adjust that so
> that you could override that with a $STARCONF variable, if you wanted.
>
> > Perhaps the default should also be set to something more sensible, such
> > as /star?
>
> Ah, but which default? The starconf business is essentially there to
> default defaults, and the default way that starconf's defaults are set
> up is indeed to have STARCONF_DEFAULT_PREFIX and
> STARCONF_DEFAULT_STARLINK being /star (this default is set in the
> top-level bootstrap script, and it is specifically this that you
> override when you set those variables before running top-level
> ./bootstrap).
>
> I have found this a little confusing, in the past.
>
> Words-of-one-syllable suggestions gratefully received from anyone
> (though the responsibility for thereby making the entire tree implode
> is all yours). I'm very very sure there are useful edits to the SSN/78
> page mentioned above and to the `Installation FAQ' which points to it.
> Please DO send me replacement text that I can drop in (that can't break
> anything).
>
> See you,
>
> Norman
>
>
> --
> ----------------------------------------------------------------------
> Norman Gray : Physics & Astronomy, Glasgow University, UK
> http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk
>
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|
