[mapserver-users] MapServer with RHEL5

[Russell McOrmond]

  I'm replying to an older message in the hope that there is an update,
and possibly more people running RHEL5 at this point.  There has been a
related problem with some machines at work and I'm trying to determine
if there is a pattern, and hopefully a patch to the right component can
be made.


  I'm not in the group that manages our production systems, so don't
have all the details for those systems.   When the systems people
compile everything (mapserver, gdal, iconv, gd, etc, etc) on RHEL4 it
works fine.  That set of binaries and libraries can even be loaded onto
a RHEL5 machine and run.  (LD_LIBRARY_PATH and PATH set to have those
libs and binaries load first).

  If they use the identical versions and build scripts on RHEL5, we get
a core dump doing a number of different things.  This includes a simple
GetMap where there is an expression in the mapfile (comment out the
expression and we don't get a core dump).

  In our environment the systems people are running RHEL5, but I am
using CentOS5 on my desktop.  If I load the binaries compiled by the
systems people I get the same core dump.  If I compile everything myself
on CentOS5, I do not get the core dump.


  There is one observation which might be a red herring, or might be
useful.  I had a problem with GD-2.0.35's configure script not detecting
iconv correctly (see old thread:
http://n2.nabble.com/Confirmation-of-status-of-UTF8-support,-and-where-transcoding-to-Latin-1-may-be-happening.-td1973930.html
 The stubs that caused the problem are at
http://cvs.php.net/viewvc.cgi/gd/libgd/src/gdkanji.c?view=markup#l27 ),
so I am compiling 2.0.36RC1.   If I load that version of GD instead of
the 2.0.35 used by the systems people, and otherwise use their binaries
and libraries, I do not get the core dump.

  Is it possible that there is something in the code for expressions
that would cause a core dump if iconv_open() returned -1, or iconv()
returning 0?  I haven't read through the mapserver code yet to determine
how expressions are implemented, and what the code would do if any of
the strings it was trying to compare were NULL.  I'm also wondering if
it would be worthwhile to have code that in this case would exit
gracefully with an error message rather than core dumping?

  Is there something in RHEL5 vs RHEL4 that might be interacting
strangely in some other way with gd, unrelated to that iconv_open() stub?

Note: The systems people may not be comfortable using a release
candidate of GD even though it has been well tested since 2007-11-28.
I'm wanting to see if anyone else has observed any similar problems, and
may already know the solution.  I suspect they are doing something
different with how they compile GD-2.0.35 given the iconv problem I
observed would have disabled the ability to access Unicode strings in
our ArcSDE managed database.  That said, I don't know for certain
whether Unicode strings were ever tested with the core dumping binaries.


Eichner, Andreas - SID-NLKM wrote:
> Hi guys,
> 
> we're using MapServer 5.2 with RedHat Enterprise Linux 5, Update 3. The
> necessary packages (like gdal) are inserted from Fedora Core 6. That
> works but the packages are somewhat outdated. So I tried to use those
> from the EPEL channel instead but without success. After compiling MS it
> segfaults because of the same problem discussed earlier on the list with
> a conflict between librx headers and libraries (the segfault can be
> avoided adding some bytes to sizeof(regex_t) in ms_regcomp() but with
> the effect of ms_regexec() returning wrong results).
> The servers are fed by a satellite server and have no direct access to a
> separate repo. So does anyone use MS with RHEL5 and has a nice solution
> for that? My personal solution would be to use Debian as on my test
> server (where I never had problems compiling and using MS) but that's
> not an option for the productive systems here :(
>  
> Regards,
> Andreas Eichner

-- 
 Russell McOrmond, Internet Consultant: <http://www.flora.ca/>
 Please help us tell the Canadian Parliament to protect our property
 rights as owners of Information Technology. Sign the petition!
 http://www.digital-copyright.ca/petition/ict/

 "The government, lobbied by legacy copyright holders and hardware
  manufacturers, can pry my camcorder, computer, home theatre, or
  portable media player from my cold dead hands!"