unix build does not use correct libmap.a

[woodbri@…]

if a user has done a make install and has a libmap.a installed in /usr/lib or 
/usr/local/lib then it will be linked instead of the newly built libmap.a

This might also be happening with mapserv. At any rate, this is easy to fix by 
changing the Makefile(s) to explictly load ./libmap.a or ../../libmap.a in the 
case of mapscript and NOT rely on the -L search paths to load the wrong one.

This is a serious problem because it is silent failure to do the correct thing 
and behavior varies depending on whether or not the user on any system has done 
a make install. It will solve a lot of potental headaches with we change the 
build enviroment as noted above.

[dmorissette]

I've run into this myself last week (coincidence?) and agree that we have to do 
something about this.  Compiling MapScript with ../../libmap.a would definitely 
fix the issue for PHP MapScript, but may cause side-effects in the Perl 
MapScript Makefiule, etc.  So I'll have to get back to this and make some tests 
before applying that change to the makefile.

[dmorissette]

The make install target has been replaced by a few lines of instructions in both 
3.6 and 4.0.  

Note that this doesn't fix the issue for people who did a 'make install' with 
older versions and still have an old /usr/local/lib/libmap.a on their system, 
but they are quite likely going to get undefined symbols at build time with 4.0 
so I think we can call this fixed.