[Mapserver-users] Compile/library problems

[Daniel Morissette]

Actually, I have compiled MapServer and all support libraries, including
PHP MapScript in a home account a few times before, so it's possible ot
do it.

As JF pointed, first you have to specify --with-prefix to all the
support libraries that you compile in your home account (GD, Freetype,
GDAL/OGR, PHP, etc.).  Assuming that your home account is
/home/myaccount then I would suggest that you install all support libs
under /home/myaccount/local ... so for all support libraries that you
compile you would configure them using --prefix=/home/myaccount/local
and using 'make install' for each library will install the libs and
header files in the right location in your account.

Then when you configure MapServer, specify the path to each library,
e.g.
 ./configure --with-gd=/home/myaccount/local \
      --with-gdal=/home/myaccount/local/bin/gdal-config  ......

Then compile MapServer normally.

The last issue that was pointed by JF is that by default the system
won't find the libraries in your home directory.  You can first try
using --enable-runpath when you configure MapServer but that may not
work well.  You have a few other options:

- If you manage your own Apache instance then set LD_LIBRARY_PATH in
  your httpd.conf:
     SetEnv  LD_LIBRARY_PATH  /home/myaccount/local/lib

- If your ISP maintains a Apache VirtualHost for your account then the
  above directive can be added by them in the VirtualHost setting

- If none of the above is an option for you then you can create a small
shell script to encapsulate your mapserv CGI:

  ---- mapserv.sh ----
  #! /bin/sh
  export LD_LIBRARY_PATH=/home/myaccount/local/lib
  /home/myaccount/mapserver/mapserv
  ---------------------

And then place that mapserv.sh in your cgi-bin directory.

I hope that helps,

Daniel



Jean-Francois.Doyon at ccrs.nrcan.gc.ca wrote:
> 
> Andrew,
> 
> Hmmmm. When you say installed, you mean you configure with a --prefix, and
> then did a "make install"?
> 
> If so, the problem is probably simply the path you're giving to configure
> ...
> 
> let's say you created ~/lib and ~/include to put your librairies in ... In
> this case, you saying --with-gd=/ might just work (the lib and include
> directories are ofthen "assumed" by configure scripts.  This becomes
> sligghtly clearer if you use a subdirectory for your styff, so ~/mylibs
> inside which you create lib and include, and then feed ~/mylibs to your
> configure ...
> 
> In some cases, you can try pointing to the src directory where the library
> has been built.
> 
> But you're going to have a bigger problem.  The system linker on your ISP's
> server isn't going to find the librairies it wants to dynamically load. To
> get around this, either you get them to update their linker paths
> (ld.so.conf), which is unlikely they would do, or you use your own linker
> ... Or, last resort, statically build your cgi executable ... though I
> couldn't help you with that I'm afraid!
> 
> J.F.
> 
> -----Original Message-----
> From: Andrew Covey [mailto:lornknight at yahoo.com]
> Sent: Monday, January 06, 2003 3:50 PM
> To: mapserver-users at lists.gis.umn.edu
> Subject: [Mapserver-users] Compile/library problems
> 
> Hello,
> 
> I am attempting to install MapServer via an account
> with an ISP, who allowed me to install the necessary
> support libraries (in my home dir).  When I attempt to
> compile map server, I specify where the libs are -
> just as ./configure --help specifies I should.
> ./configure will, under no circumstances, acknowledge
> the presence of the libraries I have compiled.
> 
> I have had this compile problem with other Redhat
> boxes, and Gentoo Linux boxes also.  Slackware seems
> to behave well however.  Sadly, my ISP is using RedHat
> 7.2, and will not change distros just for little'ole
> me.
> 
> Can anyone help me figure out why I can't seem to
> compile in the libs I compiled and installed in my
> home dir?  Need my ISP install the libraries instead
> of myself for some reason?  Any help would be most
> appreciated.
> 
> Thanks,
> 
> Andrew C.