Martin Pitt <[EMAIL PROTECTED]> writes: > Maybe I did something wrong with the configure options. That bug is > reproducible with the pristine upstream 8.1.1 tarball and doing:
> =2E/configure --prefix=/usr --mandir="\${prefix}/share/man" \ > --sysconfdir=/etc --libdir="\${prefix}/lib/postgresql/8.1/lib" \ > --libexecdir="\${prefix}/lib/postgresql-8.1/lib" \ > --mandir=\${prefix}/share/postgresql/8.1/man \ > --with-docdir=\${prefix}/share/doc/postgresql-doc-8.1 \ > --datadir=\${prefix}/share/postgresql/8.1 \ > --bindir=\${prefix}/lib/postgresql/8.1/bin \ > --includedir=\${prefix}/include/postgresql/8.1 > However, it does *not* happen when I do not specify any configure > options at all. I'll try to narrow down the problematic change > further, but can you already see what the problem is here? Yeah, the chosen-at-random pathnames ;-). I quote from the comments for make_relative_path(): * This function exists to support relocation of installation trees. * * ret_path is the output area (must be of size MAXPGPATH) * target_path is the compiled-in path to the directory we want to find * bin_path is the compiled-in path to the directory of executables * my_exec_path is the actual location of my executable * * If target_path matches bin_path up to the last directory component of * bin_path, then we build the result as my_exec_path (less the executable * name and last directory) joined to the non-matching part of target_path. * Otherwise, we return target_path as-is. * * For example: * target_path = '/usr/local/share/postgresql' * bin_path = '/usr/local/bin' * my_exec_path = '/opt/pgsql/bin/postmaster' * Given these inputs we would return '/opt/pgsql/share/postgresql' In short, you can set --prefix however you want, but you really can't tack random decoration between --prefix and /bin, /share and friends; else make_relative_path will be unable to figure out how to transform one to the other. We could doubtless improve make_relative_path to some extent, but the mess you have above seems impossible to deal with. How is a mere program supposed to deduce where things were moved to, given only knowledge of the actual location of --bindir? I see little if any pattern that would allow prediction of the corresponding --datadir, let alone --libexecdir or --includedir ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly