#14 Install of 6.4 now causes problems

open
nobody
None
5
2005-09-13
2005-09-13
Amos Gouaux
No

For many years now we have installed apps in
directories other than where the files will reside on
production systems. We then use a tool (depot from CMU
as it happens) to map these files into the production
area. Since the compiled paths are intact and correct
after such linking, everything works as expected. If we
were to set install prefix to be where the files will
be installed into, then that directory location has to
either always be mounted, or the files have to be
installed out into this area on client machines. The
latter could probably be done, but with quite a bit of
effort.

This is the result I got when attempting to install the
latest version. This was never an issue in the past.

/bin/bash ./libtool --mode=install /usr/ucb/install
libpcreposix.la
/usr/soft/that/pcre-6.4/run/default/sparc_sun_solaris2.8/lib/libpcreposix.lalibtool:
install: error: cannot install `libpcreposix.la' to a
directory not ending in /usr/local/lib
gmake: *** [install] Error 1

And I see why this is happening:

# Don't allow the user to place us outside of
our expected
# location b/c this prevents finding
dependent libraries that
# are installed to the same prefix.
# At present, this check doesn't affect
windows .dll's that
# are installed into $libdir/../bin
(currently, that works fine)
# but it's something to keep an eye on.
if test "$inst_prefix_dir" = "$destdir"; then
$echo "$modename: error: cannot install
\`$file' to a directory not ending in $libdir" 1>&2
exit $EXIT_FAILURE
fi

I can understand why this was done, but unfortunately
it breaks what we've been (successfully) doing for many
years now. Any recommendations on how to proceed? If
all GNU software is going to start doing this, man
we're going to have a hell of a time.

Discussion

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks