Hi Marco Well it looks like you have two zlib installations, and you're getting the include file from one and the library from the other. You should check that your zlib installations are complete (there should be an include file and a library in each, and note that moses will pick the dynamic (so) library by default.
The best thing to do would be to fix your zlib, either by removing one of the installs, or repairing them. The --prefix argument won't help, as it just controls where moses can be installed to. There's also a --with-zlib argument, but it just adds to INCLUDE and LIB. regards Barry On Thursday 19 August 2010 11:18, marco turchi wrote: > Hi Barry > your are right, I have: > [turc...@hpc01p ~ ]# nm -C /usr/lib/libz.a | grep gzopen > 00000000000014d0 T gzopen > [turc...@hpc01p ~ ]# nm -C /usr/local/lib/libz.a | grep gzopen > 0000000000000510 T gzopen > 0000000000000500 T gzopen64 > > there is a libz.a in /usr/local/lib that includes the gzopen64. > I run the configure adding --prefix=/usr/lib but I have the same problem... > is there another way to force moses to look for the libz.a in /usr/lib > instead of /usr/local/lib ? > > Thanks a lot > Marco > > On Thu, Aug 19, 2010 at 11:12 AM, Barry Haddow <[email protected]> wrote: > > Hi Marco > > > > From scanning through the discussions you linked to, it appears that you > > have > > a rogue libz installation. The included header (which would normally > > be /usr/include/zlib.h) contains gzopen64 but the corresponding library > > (probably /usr/lib/libz.a) doesn't. You can check for the symbol in the > > library by running > > > > [suede]bhaddow: nm -C /usr/lib/libz.a | grep gzopen > > 000014d0 T gzopen > > > > So there could be another libz lying around which is causing the > > confusion (in /usr/local/lib for example). Or maybe there's an update to > > the libz or libz-devel packages which fix the problem. You could install > > and compile your > > own version of libz, then persuade moses to use them. I'm afraid I don't > > have > > access to a centos install to try it out, > > > > regards > > Barry > > > > On Thursday 19 August 2010 08:55, marco turchi wrote: > > > Hi Berry, > > > looking on the Web, I found several posts > > > http://ubuntuforums.org/showthread.php?t=666228 > > > https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/151045 > > > http://code.google.com/p/erokar/issues/detail?id=1 > > > and it seems that there is a bug inside the libxml2 library. It is > > > > called > > > > > by the parameter -lz. > > > > > > I'm installing moses on a 64 bit machine with Linux centOS 5.3. > > > > > > I have this version of gcc: > > > gcc -v > > > Using built-in specs. > > > Target: x86_64-redhat-linux > > > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > > > --infodir=/usr/share/info --enable-shared --enable-threads=posix > > > --enable-checking=release --with-system-zlib --enable-__cxa_atexit > > > --disable-libunwind-exceptions --enable-libgcj-multifile > > > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada > > > --enable-java-awt=gtk --disable-dssi --enable-plugin > > > --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre > > > > --with-cpu=generic > > > > > --host=x86_64-redhat-linux > > > Thread model: posix > > > gcc version 4.1.2 20080704 (Red Hat 4.1.2-46) > > > > > > Thanks a lot > > > Marco > > > > > > On Wed, Aug 18, 2010 at 9:25 PM, Barry Haddow <[email protected]> > > > > wrote: > > > > Hi Marco > > > > > > > > I haven't seen this error before, and I can't find any reference to > > > > gzopen64 in > > > > moses. > > > > > > > > Which platform are you using? Have you tried a clean build? The > > > > reason for the > > > > second question is maybe you built libmoses.a with a different > > > > compiler or on a > > > > different platform, one that has gzopen64(). > > > > > > > > > > > > regards > > > > Barry > > > > > > > > On Wednesday 18 Aug 2010 17:03:30 marco turchi wrote: > > > > > Hi > > > > > I'm trying to compile the last version of moses but I get this > > > > > error: g++ -g -O2 -o moses Main.o mbr.o IOWrapper.o > > > > > TranslationAnalysis.o LatticeMBR.o ThreadPool.o > > > > > -L/nfs/staging/turchmo/mosesdecoder/External_Software/srilm//lib/i6 > > > > >86 > > > > -L/nfs/staging/turchmo/mosesdecoder/External_Software/srilm//flm/obj/i6 > > > > > > >86 ../../moses/src/.libs/libmoses.a > > > > -L/nfs/staging/turchmo/mosesdecoder/External_Software/boost_1_44_0//lib > > > > > > > -lboost_thread -L/nfs/staging/turchmo/mosesdecoder/OnDiskPt/src > > > > > > > > -lOnDiskPt > > > > > > > > > -loolm -ldstruct -lmisc -lflm -lz > > > > > ../../moses/src/.libs/libmoses.a(InputFileStream.o): In function > > > > > `gzfilebuf': > > > > > /nfs/staging/turchmo/mosesdecoder/moses/src/gzfilebuf.h:11: > > > > > undefined reference to `gzopen64' > > > > > /nfs/staging/turchmo/mosesdecoder/moses/src/gzfilebuf.h:11: > > > > > undefined reference to `gzopen64' > > > > > > > > > > do you an idea of what it is? I checked in the old posts of the > > > > > Moses mailing list, but I do not find any information about this > > > > > problem. > > > > > > > > > > Thanks a lot > > > > > Marco > > > > -- > > The University of Edinburgh is a charitable body, registered in > > Scotland, with registration number SC005336. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
