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/i686 > > > -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. _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
