Compiling and running FSA on a 64bit machine
Hi Stefan, I tried to compile and run FSA on our Suse Linux x86_64 machine (uname: Linux 2.6.4-52-smp #1 SMP Wed Apr 7 01:58:54 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux) with a little succes. I got some warnings in Unicode.cc, namely: Unicode.cc: In member function `OutIterator Core::UnicodeInputConverter::convert(const InIterator&, const InIterator&, OutIterator) [with InIterator = const char*, OutIterator = std::back_insert_iterator<std::vector<char, std::allocator<char> > >]': Unicode.cc:199: instantiated from here Unicode.cc:159: warning: invalid conversion from `const char**' to `char**' Unicode.cc: In member function `OutIterator Core::UnicodeInputConverter::convert(const InIterator&, const InIterator&, OutIterator) [with InIterator = const char*, OutIterator = std::back_insert_iterator<std::string>]': Unicode.cc:204: instantiated from here Unicode.cc:159: warning: invalid conversion from `const char**' to `char**' Unicode.cc: In member function `OutIterator Core::UnicodeOutputConverter::convert(const InIterator&, const InIterator&, OutIterator) [with InIterator = const char*, OutIterator = std::back_insert_iterator<std::vector<char, std::allocator<char> > >]': Unicode.cc:266: instantiated from here Unicode.cc:223: warning: invalid conversion from `const char**' to `char**' Unicode.cc: In member function `OutIterator Core::UnicodeOutputConverter::convert(const InIterator&, const InIterator&, OutIterator) [with InIterator = const char*, OutIterator = std::back_insert_iterator<std::string>]': Unicode.cc:271: instantiated from here Unicode.cc:223: warning: invalid conversion from `const char**' to `char**' Unicode.cc: In member function `OutIterator Core::UnicodeOutputConverter::convert(const InIterator&, const InIterator&, OutIterator) [with InIterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, OutIterator = std::ostream_iterator<char, char, std::char_traits<char> >]': Unicode.cc:276: instantiated from here Unicode.cc:223: warning: invalid conversion from `const char**' to `char**' Unicode.cc: In member function `OutIterator Core::UnicodeOutputConverter::convert(const InIterator&, const InIterator&, OutIterator) [with InIterator = const char*, OutIterator = std::ostream_iterator<char, char, std::char_traits<char> >]': Unicode.cc:281: instantiated from here Unicode.cc:223: warning: invalid conversion from `const char**' to `char**' Unicode.cc: In member function `OutIterator Core::UnicodeOutputConverter::convert(const InIterator&, const InIterator&, OutIterator) [with InIterator = const char*, OutIterator = std::ostreambuf_iterator<char, std::char_traits<char> >]': Unicode.cc:286: instantiated from here Unicode.cc:223: warning: invalid conversion from `const char**' to `char**' Also, I had to explicitly typecast in the call to std::min // u32 bufferSize = std::min(bufferThreshold_ - putBackBufferSize, formatted_.size()); u32 bufferSize = std::min(size_t(bufferThreshold_ - putBackBufferSize), formatted_.size()); Otherwise it complained that it cannot find std::min: TextStream.cc: In member function `virtual int Core::TextInputStream::Buffer::underflow()': TextStream.cc:422: error: no matching function for call to `min(unsigned int, size_t)' Ignoring the warnings and modifying the code a bit got me the executable, which unfortunately I couldn't run, because it gave me a segmentation fault. Running gdb on fsa.linux-x86_64-standard and backtracing printed this output: (gdb) backtrace #0 0x000000000048cb9d in Core::Choice::addChoice () #1 0x000000000048cdda in Core::Choice::Choice () #2 0x000000000049e184 in global constructors keyed to _ZN4Core17AbstractParameterC2ERKS0_ () #3 0x00000000004bccf6 in __do_global_ctors_aux () #4 0x00000000004352e3 in _init () #5 0x00000000004bcc20 in Core::XmlWriter::Buffer::~Buffer () #6 0x00000000004bcc91 in __libc_csu_init () at elf-init.c:60 #7 0x0000002a96264e05 in __libc_start_main () from /lib64/tls/libc.so.6 #8 0x0000000000435f7a in _start () at ../sysdeps/x86_64/elf/start.S:96 #9 0x0000007fbffff0a8 in ?? () #10 0x0000000000000000 in ?? () #11 0x0000000000000001 in ?? () #12 0x0000007fbffff3d0 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000007fbffff40e in ?? () #15 0x0000007fbffff427 in ?? () #16 0x0000007fbffff437 in ?? () #17 0x0000007fbffff45f in ?? () #18 0x0000007fbffff4e1 in ?? () #19 0x0000007fbffff508 in ?? () #20 0x0000007fbffff515 in ?? () #21 0x0000007fbffff520 in ?? () #22 0x0000007fbffff530 in ?? () #23 0x0000007fbffff558 in ?? () #24 0x0000007fbffff590 in ?? () #25 0x0000007fbffff599 in ?? () #26 0x0000007fbffff5ac in ?? () #27 0x0000007fbffff5c0 in ?? () #28 0x0000007fbffff5db in ?? () #29 0x0000007fbffff5e5 in ?? () #30 0x0000007fbffff5f2 in ?? () #31 0x0000007fbffff787 in ?? () #32 0x0000007fbffff79d in ?? () #33 0x0000007fbffff7a8 in ?? () #34 0x0000007fbffff7b6 in ?? () #35 0x0000007fbffff7c3 in ?? () #36 0x0000007fbffff7cb in ?? () #37 0x0000007fbffff7d9 in ?? () #38 0x0000007fbffff7f0 in ?? () #39 0x0000007fbffffa13 in ?? () #40 0x0000007fbffffa1d in ?? () #41 0x0000007fbffffa3f in ?? () #42 0x0000007fbffffa54 in ?? () #43 0x0000007fbffffa7c in ?? () #44 0x0000007fbffffa98 in ?? () #45 0x0000007fbffffaa9 in ?? () ... Everything compiled and ran OK on a 32bit machine. Is there anything that I can do to run FSA on the 64bit machine? Best, Emilian
Hi Emilian! On Wednesday 15 December 2004 20:31, Emilian Stoimenov wrote:
Hi Stefan, I tried to compile and run FSA on our Suse Linux x86_64 machine (uname: Linux 2.6.4-52-smp #1 SMP Wed Apr 7 01:58:54 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux) with a little succes. I got some warnings in Unicode.cc, namely:
You can safely ignore them (see the README file). They are due to missing const in the declaration of iconv.
Also, I had to explicitly typecast in the call to std::min // u32 bufferSize = std::min(bufferThreshold_ - putBackBufferSize, formatted_.size()); u32 bufferSize = std::min(size_t(bufferThreshold_ - putBackBufferSize), formatted_.size()); Otherwise it complained that it cannot find std::min:
TextStream.cc: In member function `virtual int Core::TextInputStream::Buffer::underflow()': TextStream.cc:422: error: no matching function for call to `min(unsigned int, size_t)'
I also fixed that in the mean time. I missed to compile the release on our x86_64 machine and unfortunately someone from our group did some changes to the CVS since my last test.
Ignoring the warnings and modifying the code a bit got me the executable, which unfortunately I couldn't run, because it gave me a segmentation fault. Running gdb on fsa.linux-x86_64-standard and backtracing printed this output:
On our x86_64 machine (dual opteron, 8 gb ram, debian x86_64) my executable also exits with a segmentation fault right after starting it when I use the installed compiler (gcc version 3.3.5 (Debian 1:3.3.5-3)). However, we also have a special unified built environment where we compiled gcc on our own (stock gcc 3.3.2) and using that one everything runs fine. In both cases I used the installed glibc so that shouldn't be the problem. I will look after that problem soon, but I can't promise that it happens till beginning of next week. I will put a maintainance update (0.9.1) on the website when I am finished with that bug. Hopefully, I reach version 1.0 till the end of the year....
Everything compiled and ran OK on a 32bit machine. Is there anything that I can do to run FSA on the 64bit machine?
At least some success. You are the first one reporting successful compilation outside our institute.... Stephan
Hi Stefan! I really appreciate the quick reply. I also tried to run the FSA tools with att input files - nothing special, just some toy examples. But it seems, that they aren't processed correctly: fsa att:toydict.fsm info gives <information component="fsa"> <fsa-info> <type>acceptor</type> <describe>static</describe> <properties>linear storage</properties> <semiring>tropical</semiring> <max-state-id>0</max-state-id> <states>0</states> <arcs>0</arcs> <final-states>0</final-states> <epsilon-arcs>0</epsilon-arcs> </fsa-info> </information> which can't be, this is a nonempty dictionary transducer. The same happens with the text version of this fsm file: fsa att:toydict.txt info gives <information component="fsa"> <fsa-info> <type>acceptor</type> <describe>static</describe> <properties>linear storage</properties> <semiring>tropical</semiring> <max-state-id>0</max-state-id> <states>0</states> <arcs>0</arcs> <final-states>0</final-states> <epsilon-arcs>0</epsilon-arcs> </fsa-info> </information> I'm sending you the both files as attachments to this e-mail. Best, Emilian On Wed, 15 Dec 2004 21:45:18 +0100, Stephan Kanthak <stylon@gmx.de> wrote:
Hi Emilian!
On Wednesday 15 December 2004 20:31, Emilian Stoimenov wrote:
Hi Stefan, I tried to compile and run FSA on our Suse Linux x86_64 machine (uname: Linux 2.6.4-52-smp #1 SMP Wed Apr 7 01:58:54 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux) with a little succes. I got some warnings in Unicode.cc, namely:
You can safely ignore them (see the README file). They are due to missing const in the declaration of iconv.
Also, I had to explicitly typecast in the call to std::min // u32 bufferSize = std::min(bufferThreshold_ - putBackBufferSize, formatted_.size()); u32 bufferSize = std::min(size_t(bufferThreshold_ - putBackBufferSize), formatted_.size()); Otherwise it complained that it cannot find std::min:
TextStream.cc: In member function `virtual int Core::TextInputStream::Buffer::underflow()': TextStream.cc:422: error: no matching function for call to `min(unsigned int, size_t)'
I also fixed that in the mean time. I missed to compile the release on our x86_64 machine and unfortunately someone from our group did some changes to the CVS since my last test.
Ignoring the warnings and modifying the code a bit got me the executable, which unfortunately I couldn't run, because it gave me a segmentation fault. Running gdb on fsa.linux-x86_64-standard and backtracing printed this output:
On our x86_64 machine (dual opteron, 8 gb ram, debian x86_64) my executable also exits with a segmentation fault right after starting it when I use the installed compiler (gcc version 3.3.5 (Debian 1:3.3.5-3)). However, we also have a special unified built environment where we compiled gcc on our own (stock gcc 3.3.2) and using that one everything runs fine. In both cases I used the installed glibc so that shouldn't be the problem. I will look after that problem soon, but I can't promise that it happens till beginning of next week. I will put a maintainance update (0.9.1) on the website when I am finished with that bug. Hopefully, I reach version 1.0 till the end of the year....
Everything compiled and ran OK on a 32bit machine. Is there anything that I can do to run FSA on the 64bit machine?
At least some success. You are the first one reporting successful compilation outside our institute....
Stephan
_______________________________________________ fsa mailing list fsa@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/fsa
Hi Emilian! On Wednesday 15 December 2004 23:36, Emilian Stoimenov wrote:
fsa att:toydict.fsm info
Just to note this somewhere: fsa cannot and surely will never support to read AT&T's binary fsm file format. In only supports AT&T's ascii based format (with either indices or symbols). However, you were right, the files were not processed correctly. I didn't use the reader function for more than a year now and it should be fixed in the current version 0.9.1. Note, that you can do the following if you have a file in AT&T's binary file format only: fsmprint toydict.fsm | fsa att:- info Cheers, Stephan
participants (2)
-
Emilian Stoimenov
-
Stephan Kanthak