Thank you. I guess I will just use your fix for Jamroot and manually install missing headers for now. Hopefully we'll find a more elegant solution later :)
regards, Sylvain ----- Mail original ----- > De: "Kenneth Heafield" <[email protected]> > À: [email protected] > Envoyé: Vendredi 3 Février 2012 03:56:28 > Objet: Re: [Moses-support] problems compiling and installing lasted version > On 02/02/2012 07:10 PM, [email protected] wrote: > > On Thursday 02 February 2012 18:12:31 Kenneth Heafield wrote: > >> Hi, > >> > >> Interesting. See if my recent push 0270d61 helps. If that doesn't > >> fix > >> it, open up lm/Jamfile and edit: > >> > >> exe query : ngram_query.cc kenlm ; > >> exe build_binary : build_binary.cc kenlm ; > >> > >> changing them to: > >> > >> exe query : ngram_query.cc kenlm ../util//kenutil ; > >> exe build_binary : build_binary.cc kenlm ../util//kenutil ; > >> > >> Curiously, we have the same gcc version, so I'm not sure why mine > >> worked > >> without this. > >> > > > > Your commit fixed it, thank you! What did you do, for my > > information? before I > > sent this email I tried changing the the lines you mentioned to > > > > exe query : ngram_query.cc kenlm kenutil ; > > exe build_binary : build_binary.cc kenlm kenutil ; > > > > with no luck of course > > I changed the kenlm target so that anything depending on it will also > link against kenutil. > > The reason your change did not work is that the target is in a > different > directory, so you need a path to it: ../util//kenutil . > > > > > > >> With regard to headers, we could install them by appending these > >> lines > >> to Jamroot: > >> > >> includedir = [ option.get "includedir" : $(prefix)/include ] ; > >> > >> install prefix-header : > >> [ glob-tree *.h *.hh : jam-files dist ] : > >> <location>$(includedir)<install-source-root>. ; > >> > >> But the issue is that the headers are bad at finding themselves > >> i.e. the > >> moses/src directory expects to find everything relative to that > >> path. I > >> guess we could move them up like so: > >> > >> install prefix-header : > >> [ glob-tree *.h *.hh : jam-files dist ] : > >> <location>$(includedir)<install-source-root>moses/src ; > >> > >> But I don't want to pollute a system's top-level headers with every > >> moses/src header. > > > > I'm not familiar with bjam so I don't really understand what's > > happening > > there... Maybe we could create some sort of "public headers list"? > > Or just put > > every header in $(includedir)/moses so that the system level > > directory is not > > polluted, and one would just have to add -I$(includedir)/moses to > > one's > > compile flags in order to use Moses API? otherwise, what would you > > suggest to > > be able to use moses libraries? -I/path/to/mosesdecoder/moses/src? > > If you take my first suggestion and append it to Jamroot (in the > top-level directory): > > includedir = [ option.get "includedir" : $(prefix)/include ] ; > install prefix-header : > [ glob-tree *.h *.hh : jam-files dist ] : > <location>$(includedir)<install-source-root>moses/src ; > > then run the same bjam command as you did before, it will install all > *.h and *.hh files (except those in dist or jam-files) and preserve > their directory structure. For example, lm/blank.hh will be installed > in /usr/include/lm/blank.hh (assuming --prefix=/usr). This will work > as > expected because the code says: > > #include "lm/blank.hh" > > However, e.g. moses/src/AlignmentInfoCollection.h says: > > #include "AlignmentInfo.h" > > so you will need to add -I/usr/include/moses/src in order to help it > find AlignmentInfo.h. My suggested solution is that we > > git mv moses/src/* moses/ > > and patch up the build process then modify headers to read: > > #include "moses/AlignmentInfo.h" > > But for now you'll need the extra -I argument. > > > > > regards, > > > >> > >> Sorry for the build barf, > >> > >> Kenneth > >> > >> On 02/02/2012 05:36 PM, Sylvain Raybaud wrote: > >>> Good evening all > >>> > >>> I recently pulled the latest version of moses using git. I ran > >>> into > >>> some> > >>> problems during compilation and installation. Using jam, I got > >>> many such > >>> messages (more than a dozen I think): > >>> > >>> gcc.link /home/sylvain/loria/mosesdecoder/lm/query > >>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/b > >>> in/ld: > >>> lm/bin/gcc-4.5.3/release/debug-symbols-on/threading-multi/ngram_query.o > >>> : undefined reference to symbol 'util::scoped_memory::reset(void*, > >>> unsigned long, util::scoped_memory::Alloc)' > >>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/b > >>> in/ld: note: 'util::scoped_memory::reset(void*, unsigned long, > >>> util::scoped_memory::Alloc)' is defined in DSO > >>> /home/sylvain/loria/mosesdecoder/util/bin/gcc-4.5.3/release/debug-symbol > >>> s- on/threading-multi/libkenutil.so so try adding it to the linker > >>> command line > >>> /home/sylvain/loria/mosesdecoder/util/bin/gcc-4.5.3/release/debug-symbo > >>> ls- on/threading-multi/libkenutil.so: could not read symbols: > >>> Invalid > >>> operation collect2: ld returned 1 exit status > >>> > >>> "g++" -Wl,-R -Wl,"/home/sylvain/loria/mosesdecoder/lm" > >>> -Wl,-rpath-link -> > >>> Wl,"/home/sylvain/loria/mosesdecoder/lm/bin/gcc-4.5.3/release/debug-symb > >>> ols- on/threading-multi" -Wl,-rpath-link - > >>> Wl,"/home/sylvain/loria/mosesdecoder/util/bin/gcc-4.5.3/release/debug-sy > >>> mbols- on/threading-multi" -o > >>> "/home/sylvain/loria/mosesdecoder/lm/query" -Wl,-- start-group > >>> "lm/bin/gcc-4.5.3/release/debug-symbols-on/threading- > >>> multi/ngram_query.o" > >>> "lm/bin/gcc-4.5.3/release/debug-symbols-on/threading- > >>> multi/libkenlm.so" -Wl,-Bstatic -Wl,-Bdynamic -lboost_thread-mt > >>> -lrt > >>> -Wl,-- end-group -g -pthread > >>> > >>> If I run the command manually and just add -lkenutil at the ends, > >>> it > >>> links just fine. Am I missing something here? > >>> > >>> I'm running into another problem wich I've been so far unable to > >>> solve: > >>> I'm developping a software which makes use of Moses library. With > >>> previous version, I used to include many headers (for example > >>> Sentence.h) which I could install, as far as I remember, wherever > >>> suited my needs (/usr/local/include in my case). Now, using bjam > >>> --prefix=/usr/local link=shared, I've been able to install DSO > >>> into > >>> /usr/local/lib, but could find a way to install headers. Do I have > >>> to > >>> specify -I/path/to/mosesdecoder/moses/src etc. in my software > >>> CFLAGS? > >>> or is there a proper way to install headers? it seems rather > >>> strange to > >>> me that I can install DSO but not headers as it seems quite > >>> useless... > >>> > >>> best regards, > >> > >> _______________________________________________ > >> Moses-support mailing list > >> [email protected] > >> http://mailman.mit.edu/mailman/listinfo/moses-support > > _______________________________________________ > > Moses-support mailing list > > [email protected] > > http://mailman.mit.edu/mailman/listinfo/moses-support > _______________________________________________ > Moses-support mailing list > [email protected] > http://mailman.mit.edu/mailman/listinfo/moses-support _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
