Re: [Flightgear-devel] simgear zlib 1.2.6 lowlevel
Hi, I cannot reproduce the problem, since I do not use MacPorts. IMHO we should simply copy from OSG CMakeModules/FindZLIB.cmake to Simgear CMakeModules, in order to force same semantics on OSG and Simgear. Greetings Olaf Hi James Didn’t dive into but noticed OSG has probably a more sophisticated cmake zlib check already. Maybe it’s worth to have a look there? Olaf -- 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
[Flightgear-devel] simgear zlib 1.2.6 lowlevel
Hi all 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 ? Cheers, Yves -- 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
Re: [Flightgear-devel] simgear zlib 1.2.6 lowlevel
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
Re: [Flightgear-devel] simgear zlib 1.2.6 lowlevel
Am 28.03.12 15:08, schrieb James Turner: 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 Hi James Didn’t dive into but noticed OSG has probably a more sophisticated cmake zlib check already. Maybe it’s worth to have a look there? Doesn’t type change of gzFile need a change in lowlevel.cxx anyway, once ? Cheers, Yves -- 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
