I wanted to generate executable from lex.yy so I gave following command :
gcc -lfl lex.yy.c
But it is giving error as :
/tmp/ccAa80My.o:lex.yy.c:(.text+0x325): undefined reference to '_yywrap'
/tmp/ccAa80My.o:lex.yy.c:(.text+0xa7a): undefined reference to '_yywrap'
I can't understand reason for error. Please help me.
PS : I am using cygwin on windows 7.
Try gcc lex.yy.c -lfl instead. (Thought I posted this is answer, turns out it was a comment :P)
Related
Getting this error during "make" in mpich
GEN lib/libmpi.la
libtool: error: only absolute run-paths are allowed
Compiler being used is clang (the code builds fine with gcc). Any idea what this error could be due to?
Here is the configure command:
./configure '--prefix=$PWD/BIN' '--with-device=ch3:nemesis:mxm' '--with-mxm=/home/xyz/software/hpcx-v1.9.5-gcc-inbox-redhat7.3-x86_64/mxm' '--disable-spawn' '--disable-ft-tests' '--enable-g=all' '--enable-nemesis-dbg-localoddeven' '--enable-large-tests' '--disable-perftest' 'CC=clang' 'CXX=clang++' 'FC=gfortran' 'F77=gfortran' --cache-file=/dev/null --disable-fortran
I think the issue is the evaluation of $PWD within the quotes. If you replace
./configure '--prefix=$PWD/BIN' ...
with
./configure --prefix=$PWD/BIN ...
you should be good.
I ran into this error as well when building a different piece of software. The solution for me was to enclose the shell variable in --prefix= with {}:
./configure --prefix=${PWD}/BIN
I have been using clang-3.5 to happily build bitcode versions of musl libc and
use the result to produce nice stand alone executables.
Recent attempts with clang-3.8 have not been so happy. It seems that
the bitcode clang-3.8 generates uses functions defined in
compiler-rt/lib/builtins
Typical examples of functions I find polluting the bitcode are mulxc3, mulsc3, and muldc3. I can solve this by linking against libgcc, or even the llvm alternative if I had any clear idea of what that was. Though I would rather prevent the problem from happening in the first place.
I have seen mention of flags like rtlib=compiler-rt etc, but have found precious little documentation on the subject.
So here are some simple questions.
Is it possible to prevent clang from using the compiler-rt/lib/builtins
in the emitted bitcode? Or if not
Does llvm produce a version of libgcc that I could use. Actually I would
probably build a bitcode version of it, but that is besides the point.
Love to hear some guidance on this.
Added 12/8/2016: So I will illustrate my issues with a particular workflow that
people can reproduce if they wish, or, more likely, just point out where I am being stupid.
So start by checking out:
musllv
and follow the instructions in the README.to compile (here I am using clang-3.8 on ubuntu 14.04)
WLLVM_CONFIGURE_ONLY=1 CC=wllvm ./configure --target=LLVM --build=LLVM
make
cd lib
extract-bc -b libc.a
you will also need the bitcode of a simple executable. I will use nweb.c here.
wllvm nweb.c -o nweb
extract-bc nweb
Now we can do things like:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
This workflow goes smoothly for clang-3.5 but for clang-3.8 we get:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
/tmp/libc-f734a3.o: In function `cpowl':
libc.a.bc:(.text+0xbb9a): undefined reference to `__mulxc3'
/tmp/libc-f734a3.o: In function `cpowf':
libc.a.bc:(.text+0x38f7d): undefined reference to `__mulsc3'
/tmp/libc-f734a3.o: In function `csqrt':
libc.a.bc:(.text+0x78fc3): undefined reference to `__muldc3'
/tmp/libc-f734a3.o: In function `cpow':
libc.a.bc:(.text+0xafafc): undefined reference to `__muldc3'
clang-3.8: error: linker command failed with exit code 1 (use -v to seeinvocation)
So as #paul-brannan points out we could try
clang -static -nostdlib --rtlib=compiler-rt nweb.bc libc.a.bc crt1.o libc.a -o nweb
But this is where I am probably being stupid, because I get:
clang-3.8: warning: argument unused during compilation: '--rtlib=compiler-rt'
irregardless of whether I use it as a linking or compiling flag.
OK so I finally managed to make headway on this. I built llvm-3.8.1 together with the compiler-rt project using wllvm and wllvm++.
One of the build products was libclang_rt.builtins-x86_64.a,
and from this archive I was able to extract the bitcode module
libclang_rt.builtins-x86_64.bc
using the command:
extract-bc -b libclang_rt.builtins-x86_64.a
This bitcode module has definitions for those pesky instrinsics like
__mulxc3, __mulsc3, and __muldc3.
Hallelujah!
I'm working with Tmote-sky nodes. I have installed instant-contiki as a virtual machine using VMware player. Now I can't compile any .c file on the nodes. I have always this error message:
make: msp430-gcc: Command not found
CC ../../core/net/rime/rimeaddr.c
make: msp430-gcc: Command not found
make: *** [obj_sky/rimeaddr.o] Error 127
I thought that it was because of msp430-gcc toolchain. I've installed this toolchain which normally exists with instant-contiki but I still have this problem.
Can some one help me please?
You have to install gcc-msp430 with the following command:
sudo apt-get install gcc-msp430
Try this :
the problem causes with little switch. remove it you're good to go.
open this file in note pad and goto line 132
contiki/cpu/msp40/Makefile.msp430
remove -g switch from the following line:
CFLAGSNO = -Wall -mmcu=$(CC_MCU) -g $(CFLAGSWERROR)
the line will be:
CFLAGSNO = -Wall -mmcu=$(CC_MCU) $(CFLAGSWERROR)
just clean up and recompile.
it should work.... :)
I am trying to compile oserl-3.2.3 but I am getting this error
:~/oserl/oserl$ make
erlc -Wall -I include -I .. -o ebin src/gen_esme_session.erl
src/gen_esme_session.erl:751: function concat_binary/1 undefined
src/gen_esme_session.erl:765: function concat_binary/1 undefined
make: *** [gen_esme_session.beam] Error 1
I have Erlang/OTP 17 [erts-6.0] installed on Ubuntu 12.04LTS. To me concat_binary/1 is an in built erlang function but why does make complain that it is an defined.
Function erlang:concat_binary/1 has been removed since Erlang R15 (late 2011).
You can either fix oserl yourself (concat_binary/1 could be replaced with list_to_binary/1) or try a newer fork such as iamaleksey/oserl on Github.
I want to use Mecab in Lua,but I really can't figure out the procedure of bindings,i am work no windows 7,is bingdings meaning that to create a shared library? if so? how to?i see some binding files about Java,the files in package org.chasen.mecab shows that it create by swig,it make me confused.so where does it derive from ? or just write by ourself?after bindings,what else should i do if i want to use in Lua,by the way I use mingw.can someone give some simple steps to me that I can keep trying to work on it.
to greatwolf:
i use followings command to do it
swig -lua -c++ MeCab.i
g++ -c MeCab_wrap.cxx -I C:\Lua\5.1\include -I ..\src
g++ -LC:\Lua\5.1\lib -shared MeCab_wrap.o -llua51 -o MeCab.dll
and i got errors below.
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2960): undefined reference to `_imp___ZN5MeCab12createTaggerEPKc'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2981): undefined reference to `_imp___ZN5MeCab12getLastErrorEv'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x29c9): undefined reference to `_imp___ZN5MeCab12createTaggerEPKc'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x29d9): undefined reference to `_imp___ZN5MeCab12getLastErrorEv'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2a8d): undefined reference to `_imp___ZN5MeCab11createModelEPKc'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2aae): undefined reference to `_imp___ZN5MeCab12getLastErrorEv'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2af6): undefined reference to `_imp___ZN5MeCab11createModelEPKc'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2b06): undefined reference to `_imp___ZN5MeCab12getLastErrorEv'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2b6d): undefined reference to `_imp___ZN5MeCab13createLatticeEv'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x11050): undefined reference to `MeCab::Model::version()'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x11457): undefined reference to `MeCab::Model::create(int, char**)'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x11732): undefined reference to `MeCab::Model::create(char const*)'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x122bf): undefined reference to `MeCab::Tagger::parse(MeCab::Model const&, MeCab::Lattice*)'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x17737): undefined reference to `MeCab::Tagger::create(int, char**)'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x17a12): undefined reference to `MeCab::Tagger::create(char const*)'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x17d83): undefined reference to `MeCab::Tagger::version()'
collect2: ld returned 1 exit status
it seems that these function declared in mecab.h，but i don't know how to handle it.
It looks like mecab provides a swig file for automatically generated bindings. As luck would have it, lua is one of swig's supported targets.
A reasonable starting point would be to check out the corresponding makefile to see how bindings get created for other languages. From mecab's swig makefile:
SWIG = swig
PREFIX = MeCab
all: perl ruby python java csharp
# ...
perl:
$(SWIG) -perl -shadow -c++ $(PREFIX).i
mv -f $(PREFIX)_wrap.cxx ../perl
mv -f $(PREFIX).pm ../perl
ruby:
$(SWIG) -ruby -c++ $(PREFIX).i
mv -f $(PREFIX)_wrap.cxx ../ruby/$(PREFIX)_wrap.cpp
python:
$(SWIG) -python -shadow -c++ $(PREFIX).i
mv -f $(PREFIX)_wrap.cxx ../python
mv -f $(PREFIX).py ../python
# ...
Extrapolating from the above, you can try generating swig bindings something like the following:
swig -lua -shadow -c++ MeCab.i
This will substantially reduce the effort you would otherwise need from manually creating the bindings yourself.
I don't know of any Lua bindings for mecab. Try googling for them first.
To create the bindings yourself you must be proficient both with Lua C API and C (or C++). A deep understanding of Lua itself (the language, I mean) is advisable.
Search the Lua WIKI for some more pointers. In particular BindingCodeToLua page.
I recently needed this and since I didn't find anything I wrote a module so you can use Mecab with Lua.
It works like this:
mecab = require "mecab"
parser = mecab:new("") -- you can pass mecab config options here, like "-Owakati"
print(parser:parse("吾輩は猫である"))
You can also install it via LuaRocks as mecab.
It just provides access to the parse method of the Tagger class, but when working with Mecab that's all I've ever needed. If you'd like support for other Mecab features please feel free to file an issue on Github.