Hi Barry, thanks a lot, I'll try to solve the problem playing with the two zlib installations.
Cheers Marco On Thu, Aug 19, 2010 at 12:47 PM, Barry Haddow <[email protected]> wrote: > 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
