Comments (35)
Here are a few things I can think of looking at your setup.
- Ignore
Makefile
completely (that's meant for Linux systems). The only file you need to worry about isMakefile.osx
. - You should leave
PYTHON_INC
as it is by default inMakefile.osx
, i.e., to/System/Library/Frameworks/Python.framework/Headers
. Don't change it. - Make sure
PYTHONPATH
is NOT set in the bash profile. - Run
make clean
and thenmake -f Makefile.osx
. - Run
/usr/bin/python
and then typeimport srilm
. - If that still doesn't work, please paste the output of
dyldinfo _srilm.so
here.
You are most welcome. I think this is a good exercise since the module has not been tested at all on OS X so this should help me update the README.
from swig-srilm.
I am a little confused.
Here's the steps you should follow:
- Download the srilm tarball, set $SRILM and run "MAKE_FPIC=yes make" to
compile it. - One it's compiled, make the change to File.h as I mentioned below.
- In the swig-srilm directory, make the changes to Makefile.osx and run
"make -f Makefile.osx "
If at this point you're still getting the error about LBFGS, I think the
problem is with the SRILM compilation in step 1. I believe the SRILM
INSTALL file says something about LBFGS. I'll also take a look when I get a
chance.
On Mon, Apr 18, 2016 at 7:19 PM L Rodés [email protected] wrote:
Just compiled SRILM with `MAKE_PIC=yes make World":
for subdir in misc dstruct lm flm lattice utils zlib; do
(cd $subdir/src; /Applications/Xcode.app/Contents/Developer/usr/bin/make
SRILM=/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm
MACHINE_TYPE=macosx OPTION= MAKE_PIC=yes release-scripts) || exit 1;
done
make[2]: Nothing to be done for release-scripts'.
make[2]: Nothing to be done forrelease-scripts'.
make[2]: Nothing to be done for release-scripts'.
make[2]: Nothing to be done forrelease-scripts'.
make[2]: Nothing to be done for release-scripts'.
make[2]: Nothing to be done forrelease-scripts'.
make[2]: Nothing to be done for `release-scripts'.Once it finished, I executed make -f Makefile.osx and got the same error:
$ make -f Makefile.osx
\rm -fr srilm.o srilm___wrap._ .so srilm.py srilm.pm
g++ -c -fpic srilm.c -I/usr/local/include
-I/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include
-I/Library/Frameworks/Python.framework/Headers
clang: warning: treating 'c' input as 'c++' when in C++ mode, this
behavior is deprecated
swig -python srilm_python.i
g++ -c -fpic srilm_python_wrap.c -I/usr/local/include
-I/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include
-I/Library/Frameworks/Python.framework/Headers
clang: warning: treating 'c' input as 'c++' when in C++ mode, this
behavior is deprecated
g++ -shared srilm.o srilm_python_wrap.o -lpython -lz -liconv -loolm
-ldstruct -lmisc
-L/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/lib/macosx
-o _srilm.so
Undefined symbols for architecture x86_64:
"_lbfgs", referenced from:
hmaxent::model::fit(hmaxent::data_t_) in liboolm.a(hmaxent.o) "lbfgs_free", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
"_lbfgs_malloc", referenced from:
hmaxent::model::fit(hmaxent::data_t_) in liboolm.a(hmaxent.o) "lbfgs_parameter_init", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [_srilm.so] Error 1—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6 (comment)
from swig-srilm.
Yeah, SRILM
is supposed to rename its built-in zopen()
function to my_zopen()
on OS X but looks like it's not doing that for some reason. I am currently debugging this on my Mac but, to be honest, this code hasn't really been tested on OS X extensively. Only on Linux.
from swig-srilm.
I have a possible solution. Can you check out the macosx
branch and try to compile the wrapper using make -f Makefile.osx
? Note that this will only work with the python that comes with OS X (/usr/bin/python
).
from swig-srilm.
I'll have a look at it after new years.
from swig-srilm.
I tried compiling using Makefile.osx . It is giving following error.
rilm-1.7.1/include/zio.h:105:8: error: conflicting types for 'zopen'
FILE * zopen (const char name, const char *mode);
^
/usr/include/stdio.h:463:7: note: previous declaration is here
FILE *zopen(const char *, const char *, int);
^
1 error generated.
make: ** [srilm.o] Error 1
from swig-srilm.
Sounds like you haven't updated the SRILM header location to where yours is
installed.
On Sun, Mar 6, 2016 at 6:49 AM Varun Kumar [email protected] wrote:
I tried compiling using Makefile.osx . It is giving following error.
\rm -fr srilm.o srilm___wrap._ .so srilm.py srilm.pm
g++ -c -fpic srilm.c -I/usr/local/include -I/tmp/srilm/include
-I/System/Library/Frameworks/Python.framework/Headers
clang: warning: treating 'c' input as 'c++' when in C++ mode, this
behavior is deprecated
srilm.c:1:10: fatal error: 'Prob.h' file not found
#include "Prob.h"
^
1 error generated.
make: *** [srilm.o] Error 1—
Reply to this email directly or view it on GitHub
#6 (comment)
.
from swig-srilm.
Hi, I am having the exact same problem. What do you mean with "you haven't updated the SRILM header location to where yours is installed."?
The compilation stops when using SRILM_INC, which is pointint at: /path/to/srilm/include, where all the headers .h are located.
Do you have any idea?
Thanks
from swig-srilm.
Where is SRILM installed on your machine? What path?
On Mon, Apr 18, 2016 at 4:42 PM L Rodés [email protected] wrote:
Hi, I am having the exact same problem. What do you mean with "you haven't
updated the SRILM header location to where yours is installed."?
The compilation stops when using SRILM_INC, which is pointint at:
/path/to/srilm/include, where all the headers .h are located.
Do you have any idea?—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6 (comment)
from swig-srilm.
$ echo $SRILM
/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm
This directory contains all the directories: lib, bin, include etc.
from swig-srilm.
So, just to confirm, you downloaded SRILM from
http://www.speech.sri.com/projects/srilm/ and compiled it and installed it
in that location?
On Mon, Apr 18, 2016 at 4:48 PM L Rodés [email protected] wrote:
$ echo $SRILM
/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6 (comment)
from swig-srilm.
Yes, I just ran again the installation some minutes ago. In fact, he SRILM packet works, I mean all the commands "ngram", "ngram-count" and so are available.
from swig-srilm.
Okay. And you changed all the appropriate paths in Makefile.osx based on
this path? If so, can you please attach the error log. I'll take a look
when I get a chance. Thanks.
On Mon, Apr 18, 2016 at 4:53 PM L Rodés [email protected] wrote:
Yes, I just ran again the installation some minutes ago. The SRILM packet
in fact works, i mean all the commands "ngram", "ngram-count" and so are
available.—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6 (comment)
from swig-srilm.
Where do I find the logs? Are they the outputs from the console?
from swig-srilm.
Yeah when you run "make -f Makefile.osx "
On Mon, Apr 18, 2016 at 5:43 PM L Rodés [email protected] wrote:
Where do I find the logs? Are they the outputs from the console?
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6 (comment)
from swig-srilm.
Really appreciate your patience!
$make -f Makefile.osx
\rm -fr srilm.o srilm___wrap._ .so srilm.py srilm.pm
g++ -c -fpic srilm.c -I/usr/local/include -I/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include -I/Library/Frameworks/Python.framework/Headers
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
In file included from srilm.c:1:
In file included from /Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include/Prob.h:20:
In file included from /Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include/Counts.h:24:
In file included from /Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include/File.h:23:
/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include/zio.h:105:8: error: conflicting types for 'zopen'
FILE * zopen (const char *name, const char *mode);
^
/usr/include/stdio.h:463:7: note: previous declaration is here
FILE *zopen(const char *, const char *, int);
^
1 error generated.
Thanks, cheers
from swig-srilm.
Yeah that looks like the original error so my solution doesn't seem to work, looks like. I'll have to debug it a bit more. Sorry.
from swig-srilm.
Okay, here's something else to try. In the file File.h
under srilm/include
, comment out the line at the top that says #include "zio.h"
and then run make -f Makefile.osx
. Let me know if that works. It seems to work for me.
from swig-srilm.
If I comment that line and recompile SRILM, i.e. $ make World
in $SRILM directory, an error occurs and compilation cannot finish:
NgramLM.cc:1023:23: error: use of undeclared identifier 'stdio_filename_p'
if (!file.name || stdio_filename_p(file.name)) {
^
NgramLM.cc:1038:23: error: use of undeclared identifier 'stdio_filename_p'
if (file.name && !stdio_filename_p(file.name)) {
^
2 errors generated.
make[2]: *** [../obj/macosx/NgramLM.o] Error 1
make[1]: *** [release-libraries] Error 1
make: *** [World] Error 2
If I do not recompile SRILM and directly execute make -f Makefile.osx
in the corresponding directory of swig-srilm-macosx I get a different error:
$ make -f Makefile.osx
\rm -fr srilm.o srilm___wrap._ .so srilm.py srilm.pm
g++ -c -fpic srilm.c -I/usr/local/include -I/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include -I/Library/Frameworks/Python.framework/Headers
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
swig -python srilm_python.i
g++ -c -fpic srilm_python_wrap.c -I/usr/local/include -I/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include -I/Library/Frameworks/Python.framework/Headers
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
g++ -shared srilm.o srilm_python_wrap.o -lpython -lz -liconv -loolm -ldstruct -lmisc -L/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/lib/macosx -o _srilm.so
Undefined symbols for architecture x86_64:
"lbfgs", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
"lbfgs_free", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
"lbfgs_malloc", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
"lbfgs_parameter_init", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [_srilm.so] Error 1
from swig-srilm.
No, you shouldn't need to recompile SRILM. That was just for my wrapper.
I've never seen that error before. Did you compile SRILM using
"MAKE_FPIC=yes make"?
On Mon, Apr 18, 2016 at 7:07 PM L Rodés [email protected] wrote:
If I comment that line and compile SRILM, i.e. $ make World, an error
occurs and compilation cannot finish:NgramLM.cc:1023:23: error: use of undeclared identifier 'stdio_filename_p'
if (!file.name || stdio_filename_p(file.name)) {
^
NgramLM.cc:1038:23: error: use of undeclared identifier 'stdio_filename_p'
if (file.name && !stdio_filename_p(file.name)) {
^
2 errors generated.
make[2]: *** [../obj/macosx/NgramLM.o] Error 1
make[1]: *** [release-libraries] Error 1
make: *** [World] Error 2If I do not recompile SRILM and directly execute make -f Makefile.osx in
the corresponding directory I get a different error:$ make -f Makefile.osx
\rm -fr srilm.o srilm___wrap._ .so srilm.py srilm.pmg++ -c -fpic srilm.c -I/usr/local/include
-I/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include
-I/Library/Frameworks/Python.framework/Headers
clang: warning: treating 'c' input as 'c++' when in C++ mode, this
behavior is deprecatedswig -python srilm_python.i
g++ -c -fpic srilm_python_wrap.c -I/usr/local/include
-I/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include
-I/Library/Frameworks/Python.framework/Headersclang: warning: treating 'c' input as 'c++' when in C++ mode, this
behavior is deprecatedg++ -shared srilm.o srilm_python_wrap.o -lpython -lz -liconv -loolm
-ldstruct -lmisc
-L/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/lib/macosx
-o _srilm.so
Undefined symbols for architecture x86_64:
"_lbfgs", referenced from:
hmaxent::model::fit(hmaxent::data_t_) in liboolm.a(hmaxent.o) "lbfgs_free", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
"_lbfgs_malloc", referenced from:
hmaxent::model::fit(hmaxent::data_t_) in liboolm.a(hmaxent.o) "lbfgs_parameter_init", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [_srilm.so] Error 1—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6 (comment)
from swig-srilm.
Do you mean "MAKE_PIC"? If yes, I did not use that. I just ran "make World" once all paths were set. Should I use that?
Btw, I wonder why this line appears on a mac
Undefined symbols for architecture x86_64:
from swig-srilm.
Just compiled SRILM with `MAKE_PIC=yes make World":
[....]
for subdir in misc dstruct lm flm lattice utils zlib; do
(cd $subdir/src; /Applications/Xcode.app/Contents/Developer/usr/bin/make SRILM=/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm MACHINE_TYPE=macosx OPTION= MAKE_PIC=yes release-scripts) || exit 1;
done
make[2]: Nothing to be done forrelease-scripts'. make[2]: Nothing to be done for
release-scripts'.
make[2]: Nothing to be done forrelease-scripts'. make[2]: Nothing to be done for
release-scripts'.
make[2]: Nothing to be done forrelease-scripts'. make[2]: Nothing to be done for
release-scripts'.
make[2]: Nothing to be done for `release-scripts'.
Once it finished, I executed make -f Makefile.osx
and got the same error:
$ make -f Makefile.osx
\rm -fr srilm.o srilm___wrap._ .so srilm.py srilm.pm
g++ -c -fpic srilm.c -I/usr/local/include -I/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include -I/Library/Frameworks/Python.framework/Headers
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
swig -python srilm_python.i
g++ -c -fpic srilm_python_wrap.c -I/usr/local/include -I/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include -I/Library/Frameworks/Python.framework/Headers
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
g++ -shared srilm.o srilm_python_wrap.o -lpython -lz -liconv -loolm -ldstruct -lmisc -L/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/lib/macosx -o _srilm.so
Undefined symbols for architecture x86_64:
"lbfgs", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
"lbfgs_free", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
"lbfgs_malloc", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
"lbfgs_parameter_init", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [_srilm.so] Error 1
from swig-srilm.
Sorry, yeah MAKE_PIC :)
On Mon, Apr 18, 2016 at 7:34 PM Nitin Madnani [email protected] wrote:
I am a little confused.
Here's the steps you should follow:
- Download the srilm tarball, set $SRILM and run "MAKE_FPIC=yes make" to
compile it.- One it's compiled, make the change to File.h as I mentioned below.
- In the swig-srilm directory, make the changes to Makefile.osx and run
"make -f Makefile.osx "If at this point you're still getting the error about LBFGS, I think the
problem is with the SRILM compilation in step 1. I believe the SRILM
INSTALL file says something about LBFGS. I'll also take a look when I get a
chance.
On Mon, Apr 18, 2016 at 7:19 PM L Rodés [email protected] wrote:Just compiled SRILM with `MAKE_PIC=yes make World":
for subdir in misc dstruct lm flm lattice utils zlib; do
(cd $subdir/src; /Applications/Xcode.app/Contents/Developer/usr/bin/make
SRILM=/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm
MACHINE_TYPE=macosx OPTION= MAKE_PIC=yes release-scripts) || exit 1;
done
make[2]: Nothing to be done for release-scripts'.
make[2]: Nothing to be done forrelease-scripts'.
make[2]: Nothing to be done for release-scripts'.
make[2]: Nothing to be done forrelease-scripts'.
make[2]: Nothing to be done for release-scripts'.
make[2]: Nothing to be done forrelease-scripts'.
make[2]: Nothing to be done for `release-scripts'.Once it finished, I executed make -f Makefile.osx and got the same error:
$ make -f Makefile.osx
\rm -fr srilm.o srilm___wrap._ .so srilm.py srilm.pm
g++ -c -fpic srilm.c -I/usr/local/include
-I/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include
-I/Library/Frameworks/Python.framework/Headers
clang: warning: treating 'c' input as 'c++' when in C++ mode, this
behavior is deprecated
swig -python srilm_python.i
g++ -c -fpic srilm_python_wrap.c -I/usr/local/include
-I/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/include
-I/Library/Frameworks/Python.framework/Headers
clang: warning: treating 'c' input as 'c++' when in C++ mode, this
behavior is deprecated
g++ -shared srilm.o srilm_python_wrap.o -lpython -lz -liconv -loolm
-ldstruct -lmisc
-L/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm/lib/macosx
-o _srilm.so
Undefined symbols for architecture x86_64:
"_lbfgs", referenced from:
hmaxent::model::fit(hmaxent::data_t_) in liboolm.a(hmaxent.o) "lbfgs_free", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
"_lbfgs_malloc", referenced from:
hmaxent::model::fit(hmaxent::data_t_) in liboolm.a(hmaxent.o) "lbfgs_parameter_init", referenced from:
hmaxent::model::fit(hmaxent::data_t) in liboolm.a(hmaxent.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [_srilm.so] Error 1—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6 (comment)
from swig-srilm.
I'll take a look this week, thanks a lot for your time. I'll let you know if something changes.
P.S. Do you think it makes sense to remove all SRILM content and re-download it? That is, uninstalling it? In case it can make a difference, how should it be uninstalled?
from swig-srilm.
You're welcome!
Here's another thing to check, in the SRILM compilation directory, what is the output of the following two commands:
nm lib/macosx/liboolm.a | grep lbfgs
nm lib/macosx/liboolm.a | grep hmaxent
For me, the first command doesn't give me anything but based on the error you are getting, you probably have some lbfgs
symbols. This should only happen if you set one of the LBFGS environment variables (see the INSTALL
file for SRILM) which I don't.
To answer your question, to "uninstall" SRILM, just delete the SRILM directory entirely (but not the tarball you downloaded), untar the tarball again and recompile using MAKE_PIC=yes make
.
from swig-srilm.
Hi,
The output to 1. is nothing, but the output to 2. is the following:
$ nm lib/macosx/liboolm.a | grep lbfgs
$ nm lib/macosx/liboolm.a | grep hmaxent
00000000000045f0 S __ZN7MEModel20createDataFromCountsIdEEPN7hmaxent6data_tER11NgramCountsIT_E
0000000000006a40 S __ZN7MEModel20createDataFromCountsImEEPN7hmaxent6data_tER11NgramCountsIT_E
U __ZN7hmaxent5model10param_sumsEv
U __ZN7hmaxent5model12lognormconstEv
U __ZN7hmaxent5model16log_prob_contextEmm
U __ZN7hmaxent5model3fitEPNS_6data_tE
U __ZN7hmaxent5modelC1EPNS_11structure_tE
U __ZN7hmaxent5modelD1Ev
0000000000005620 S __ZNSt3__16vectorIN7hmaxent15count_context_tENS_9allocatorIS2_EEE21__push_back_slow_pathIKS2_EEvRT_
0000000000008620 S __ZNSt3__16vectorIN7hmaxent17feature_context_tENS_9allocatorIS2_EEE21__push_back_slow_pathIKS2_EEvRT_
0000000000004fe0 S __ZNSt3__16vectorIN7hmaxent17feature_context_tENS_9allocatorIS2_EEEC2Em
lib/macosx/liboolm.a(hmaxent.o):
0000000000001dd0 T __ZN7hmaxent5model10param_sumsEv
0000000000005f30 T __ZN7hmaxent5model10sum_logpmfEv
0000000000005620 T __ZN7hmaxent5model11clear_cacheEv
00000000000027a0 T __ZN7hmaxent5model12expectationsEv
0000000000000a00 T __ZN7hmaxent5model12lognormconstEv
0000000000005630 T __ZN7hmaxent5model15log_pmf_contextEmRNSt3__18valarrayIdEE
0000000000005e60 T __ZN7hmaxent5model16log_prob_contextEmm
0000000000001b20 T __ZN7hmaxent5model17ensure_exp_paramsEv
00000000000055f0 T __ZN7hmaxent5model3fitEPNS_6data_tE
00000000000041d0 T __ZN7hmaxent5model4dualEv
0000000000004b00 T __ZN7hmaxent5model4gradEv
0000000000000760 T __ZN7hmaxent5modelC1EPNS_11structure_tE
0000000000000070 T __ZN7hmaxent5modelC2EPNS_11structure_tE
00000000000009f0 T __ZN7hmaxent5modelD1Ev
0000000000000770 T __ZN7hmaxent5modelD2Ev
Find below the steps I followed. I hope it helps.
- I reinstalled SRILM using
MAKE_PIC=yes make
. Functions are working. - I changed the path variables in both the Makefile and the Makefile.osx of your wrapper to:
SRILM_LIBS=/Users/lucasrodes/Documents/Exercise_2/srilm-1.7.1/lib/macosx
SRILM_INC=/Users/lucasrodes/Documents/Exercise_2/srilm-1.7.1/include
PYTHON_INC=/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/
PERL_INC= /usr/bin/perl
where I am not sure if the python and perl paths are correctly:
- The python path is set as in the bash_profile and the include folder, namely
$PATH/include/python2.7
, where all the headers are located. - The perl path I actually do not know where it is, the used path is not a directory but a file. To find its directory I basically tipped:
$ which -a perl
/Users/lucasrodes/perl5/perlbrew/perls/perl-5.16.0/bin/perl
/usr/bin/per
and chose the second location.
- I commented the line
//#include "zio.h"
in $SRILM/include/File.h, as you previously mentioned. - Once I execute
make -f Makefile.osx
I think I got no error:
$ make -f Makefile.osx
\rm -fr srilm.o srilm_*_wrap.* *.so srilm.py* srilm.pm
g++ -c -fpic srilm.c -I/usr/local/include -I/Users/lucasrodes/Documents/Exercise_2/srilm-1.7.1/include -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
swig -python srilm_python.i
g++ -c -fpic srilm_python_wrap.c -I/usr/local/include -I/Users/lucasrodes/Documents/Exercise_2/srilm-1.7.1/include -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
g++ -shared srilm.o srilm_python_wrap.o -lpython -lz -liconv -loolm -ldstruct -lmisc -L/Users/lucasrodes/Documents/Exercise_2/srilm-1.7.1/lib/macosx -o _srilm.so
- However, when I run
make Makefile.osx python
I get an error:
$ make Makefile.osx python
make: Nothing to be done for `Makefile.osx'.
\rm -fr srilm.o srilm_*_wrap.* *.so srilm.py* srilm.pm
g++ -c -fpic srilm.c -I/usr/local/include/ -I/Users/lucasrodes/Documents/Exercise_2/srilm-1.7.1/include -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
swig -python srilm_python.i
g++ -c -fpic srilm_python_wrap.c -I/usr/local/include/ -I/Users/lucasrodes/Documents/Exercise_2/srilm-1.7.1/include -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
g++ -shared srilm.o srilm_python_wrap.o -loolm -ldstruct -lmisc -lz -lgomp -L/Users/lucasrodes/Documents/Exercise_2/srilm-1.7.1/lib/macosx -o _srilm.so
ld: library not found for -lgomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [_srilm.so] Error 1
Now things have change quite a bit, I think the problem before was with the paths in the Makefile.osx and Makefile files (both need to be set). However make Makefile.osx python
still does not work.
from swig-srilm.
Once you do make -f Makefile.osx
that's it. That compiles the python module by default. You don't need to do another make
command after that. You should be able to run /usr/bin/python test.py
(the test script included with swig-srilm
) after that and it should produce the output as shown in the README.
from swig-srilm.
Hi again,
it seems I might have an issue with my Python installation.
>>> import srilm
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6
Thanks anyway :-)
from swig-srilm.
It looks like the version of Python you used to compile (at link time)
doesn't seem to match the python interpreter that you are using the
compiled module with :)
On Wed, Apr 20, 2016 at 11:33 PM Lucas Rodés [email protected]
wrote:
Hi again,
it seems I might have an issue with my Python installation.import srilm
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6Thanks anyway :-)
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6 (comment)
from swig-srilm.
version of Python you used to compile (at link time)
What does it mean "at link time"? Besides this, where do I have the possibility to change the compiler? In the variable PYTHON_INC
in the Makefile and Makefile.osx? I don't know how to check if the compiler and interpreter do match.
I really appreciate your time and patience. I understand that this last questions are out of the scope of this thread, however if you can give me some tip or reference it would be very helpful.
Regards and thanks again.
from swig-srilm.
Ok, amazing. It works. Two things I was doing wrong regarding your points:
- I had changed the
PYTHON_INC
variable. I have set it back to the path you cited. - When I installed python (by the way, version 2.7.11), a
PATH
variable was automatically defined in the bash profile. - I was running another interpreter. I had installed a newer version of Python:
$ python
Python 2.7.11 |Anaconda 4.0.0 (x86_64)| (default, Dec 6 2015, 18:57:58)
[GCC 4.2.1 (Apple Inc. build 5577)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>> import srilm
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6
I just opened the bash_profile
and set back to the original path (default mac OSX python)
PATH="/usr/bin:${PATH}"
export PATH
And it finally it does work!
$ /usr/bin/python
Python 2.7.10 (default, Oct 23 2015, 18:05:06)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import srilm
>>>
Thanks for your help, I finally can go into language modeling :-). Hope this helps you improving the OS X version/documentation (it is already very good though:-) ).
from swig-srilm.
That's great news! I'll update the readme based on our conversation :)
On Thu, Apr 21, 2016 at 4:46 PM Lucas Rodés [email protected]
wrote:
Ok, amazing. It works. Two things I was doing wrong regarding your points:
- I had changed the PYTHON_INC variable. I have set it to the path
you cited.- When I installed python (by the way, version 2.7.11), a PATH
variable was automatically defined in the bash profile.- I was running another interpreter:
``
$ python
Python 2.7.11 |Anaconda 4.0.0 (x86_64)| (default, Dec 6 2015, 18:57:58)
[GCC 4.2.1 (Apple Inc. build 5577)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.orgimport srilm
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6``
and now:
$ /usr/bin/python
Python 2.7.10 (default, Oct 23 2015, 18:05:06)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.import srilm
I'll try to fix this. Thanks for your help, I finally can go into language
modeling :-). Hope this helps you improving the OS X version (though is
already very good :-) ).—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6 (comment)
from swig-srilm.
PS. However, now I am only to call the import srilm
from the same directory, i.e. /swig-srilm-macosx. It looks like it does not find the functions. I suspect some path has to be added to the bash_profile
?
from swig-srilm.
Yeah. You can either add that directory to your PYTHONPATH variable in your
bash profile or use sys.path.append() in your Python code.
On Thu, Apr 21, 2016 at 5:15 PM Lucas Rodés [email protected]
wrote:
PS. However, now I am only to call the import srilm from the same
directory, i.e. /swig-srilm-macosx. It looks like it does not find the
functions. I suspect some path has to be added to the bash_profile?—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6 (comment)
from swig-srilm.
Awesome! cheers.
from swig-srilm.
Related Issues (5)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from swig-srilm.