Problems with $(unlibsubdir) patch

[Raja R Harinath <harinath at cs dot umn dot edu>]

Hi,

The patch that introduced $(unlibsubdir) doesn't handle symlinks in
$(prefix) and $(exec_prefix).  

For example, my setup is

	$prefix		== /some/path/egcs
	$exec_prefix	== /some/path/egcs/sol2

But `sol2' is a symlink into an altogether different tree.

One of the things introduced in this patch is:

  -DGPLUSPLUS_INCLUDE_DIR=\"$(libsubdir)/$(unlibsubdir)/..`echo $(exec_prefix) | sed -e 's|^$(prefix)||' -e 's|/[^/]*|/..|g'`/include/g++\" \

This basically figures out a ../../.. path from $exec_prefix to $prefix.
Now, when you try to get to $prefix from $exec_prefix with in the above
scenario, the result it totally meaningless.

I don't think a "Me: Doctor, it hurts.  Doctor: Don't do that, then"
approach is acceptable for this.  Reasons are, in my case:

	- /some/path/egcs/sol2 is the canonical $exec_prefix

	- If the partition where my binaries live fills up, I can just
	  `cp -a' to a new partition, redirect the symlink -- and things
	  just work.  I don't have to recompile stuff to use the new
	  paths.

	- Not having the $exec_prefix symlink live inside $prefix is an
	  option, but I would prefer not to have this restriction.

I'm sure other people will have even better reasons.

Another problem introduced with this patch is that it ignores the the
`config.if' stuff (libstdcxx_interface).  So, right now I think C++ is
not working for many people (libstdc++ installs in `include/g++-2' but
the above looks in `include/g++').

Finally, the `cpplib.c' rule hasn't been updated to be similar.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash