On 28 Mar 2012, at 12:21, HB-GRAL wrote:
I had some problems compiling simgear release/2.6.0 using zlib 1.2.6 on
OSX. Looks like the main problem is here (independent of platform?):
lowlevel.hxx
void sgReadString ( gzFile fd, char **var ) ;
lowlevel.cxx
int c = gzgetc ( fd ) ;
While this seems to work with zlib 1.2.3 and 5, documentation says this
(probably ... sorry for any misinterpretation) doesn’t work anymore for
1.2.6
I tried cmake build with -DZLIB_INCLUDE_DIR etc. to the right version,
but this didnt’t work at all. I’m sure I did something wrong there with
cmake, #include zlib.h linked always against my newest version. So I
changed lowlevel.hxx the hard way to include a /usr/include/zlib.h
(OSX installed version 1.2.3) and now I can compile.
Nomen est omen, so this note here to the devellist is some kind of a
lowlevel report, unfortunately I’m not able to patch cmakelist nore
lowlevel.hxx/cxx to work with zlib 1.2.6.
I changed lowlevel.hxx directly for my purposes, but this IS lowlevel.
Am I the only one with this small zlib issue ?
It happened for me, I fixed it by forcing Macports to use zlib 1.2.5, instead
of 1.2.6 which has introduced the extra issue.
The real issue is that we're finding zlib.h in /opt/local/include, but using
the libz from /usr. (The Apple supplied version)
I tried to find a solution, so that we use one header + library consistently,
but didn't yet figure this out. Since zlib doesn't have a subdir in include,
we're at mercy of the search paths a little. For the library we can force an
explicit absolute path to link against, but Cmake's FindZLIB is finding the one
in /usr (correctly, I would say), the problem is the header search order at
compile time.
James
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel