Giter Club home page Giter Club logo

Comments (35)

desilinguist avatar desilinguist commented on June 12, 2024 2

Here are a few things I can think of looking at your setup.

  1. Ignore Makefile completely (that's meant for Linux systems). The only file you need to worry about is Makefile.osx.
  2. You should leave PYTHON_INC as it is by default in Makefile.osx, i.e., to /System/Library/Frameworks/Python.framework/Headers. Don't change it.
  3. Make sure PYTHONPATH is NOT set in the bash profile.
  4. Run make clean and then make -f Makefile.osx.
  5. Run /usr/bin/python and then type import srilm.
  6. 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.

desilinguist avatar desilinguist commented on June 12, 2024 1

I am a little confused.

Here's the steps you should follow:

  1. Download the srilm tarball, set $SRILM and run "MAKE_FPIC=yes make" to
    compile it.
  2. One it's compiled, make the change to File.h as I mentioned below.
  3. 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.

desilinguist avatar desilinguist commented on June 12, 2024

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.

desilinguist avatar desilinguist commented on June 12, 2024

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.

zeeraktalat avatar zeeraktalat commented on June 12, 2024

I'll have a look at it after new years.

from swig-srilm.

varunkumar-dev avatar varunkumar-dev commented on June 12, 2024

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.

desilinguist avatar desilinguist commented on June 12, 2024

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.

lucasrodes avatar lucasrodes commented on June 12, 2024

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.

desilinguist avatar desilinguist commented on June 12, 2024

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.

lucasrodes avatar lucasrodes commented on June 12, 2024

$ echo $SRILM
/Volumes/Macintosh/Users/lucasrodes/Documents/Exercise_2/srilm

This directory contains all the directories: lib, bin, include etc.

from swig-srilm.

desilinguist avatar desilinguist commented on June 12, 2024

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.

lucasrodes avatar lucasrodes commented on June 12, 2024

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.

desilinguist avatar desilinguist commented on June 12, 2024

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.

lucasrodes avatar lucasrodes commented on June 12, 2024

Where do I find the logs? Are they the outputs from the console?

from swig-srilm.

desilinguist avatar desilinguist commented on June 12, 2024

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.

lucasrodes avatar lucasrodes commented on June 12, 2024

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.

desilinguist avatar desilinguist commented on June 12, 2024

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.

desilinguist avatar desilinguist commented on June 12, 2024

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.

lucasrodes avatar lucasrodes commented on June 12, 2024

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.

desilinguist avatar desilinguist commented on June 12, 2024

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 2

If 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.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.

lucasrodes avatar lucasrodes commented on June 12, 2024

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.

lucasrodes avatar lucasrodes commented on June 12, 2024

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

from swig-srilm.

desilinguist avatar desilinguist commented on June 12, 2024

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:

  1. Download the srilm tarball, set $SRILM and run "MAKE_FPIC=yes make" to
    compile it.
  2. One it's compiled, make the change to File.h as I mentioned below.
  3. 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.

lucasrodes avatar lucasrodes commented on June 12, 2024

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.

desilinguist avatar desilinguist commented on June 12, 2024

You're welcome!

Here's another thing to check, in the SRILM compilation directory, what is the output of the following two commands:

  1. nm lib/macosx/liboolm.a | grep lbfgs
  2. 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.

lucasrodes avatar lucasrodes commented on June 12, 2024

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.

  1. I reinstalled SRILM using MAKE_PIC=yes make. Functions are working.
  2. 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.

  1. I commented the line //#include "zio.h" in $SRILM/include/File.h, as you previously mentioned.
  2. 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
  1. 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.

desilinguist avatar desilinguist commented on June 12, 2024

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.

lucasrodes avatar lucasrodes commented on June 12, 2024

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.

desilinguist avatar desilinguist commented on June 12, 2024

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: 6

Thanks anyway :-)


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6 (comment)

from swig-srilm.

lucasrodes avatar lucasrodes commented on June 12, 2024

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.

lucasrodes avatar lucasrodes commented on June 12, 2024

Ok, amazing. It works. Two things I was doing wrong regarding your points:

  1. I had changed the PYTHON_INC variable. I have set it back to the path you cited.
  2. When I installed python (by the way, version 2.7.11), a PATH variable was automatically defined in the bash profile.
  3. 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.

desilinguist avatar desilinguist commented on June 12, 2024

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:

  1. I had changed the PYTHON_INC variable. I have set it to the path
    you cited.
  2. When I installed python (by the way, version 2.7.11), a PATH
    variable was automatically defined in the bash profile.
  3. 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.org

import 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.

lucasrodes avatar lucasrodes commented on June 12, 2024

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.

desilinguist avatar desilinguist commented on June 12, 2024

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.

lucasrodes avatar lucasrodes commented on June 12, 2024

Awesome! cheers.

from swig-srilm.

Related Issues (5)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.