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
