I'm using lua 5.3beta under Kubuntu 12.04. I wrapped a c-extension using swig used and gcc4.9 for compiling and linking. If I place my mylib.so in the same directory my lua script is in:
require "mylib"
works fine. But if mylib.so is not within the same directory I get the error message
module 'mylib' not found
I added the path to mylib to LD_LIBRARY_PATH and inserted
package.path = package.path .. ';' .. path2mylib .. '/?
in my script. With
package.path = package.path .. ';' .. path2mylib .. '/?.so
the error message is:
mylib.so:1: unexpected symbol near '<\127>
I guess lua tries to load mylib.so assuming it is a lua-script.
It seems that lua looks for shared objects only within certain standard paths including ./ and all paths added to package.path are treated as paths to lua-files.
Is there any way to make lua load my c-extension without placing it into one of the standard library paths?
The path variable that tells Lua where to find libraries written in C is package.cpath.
package.path is for libraries written in Lua.
Related
I have read the manual at https://cppcheck.sourceforge.io/manual.pdf and have found that I can use -i to ignore a directory. However, in my testing it doesn't seem to ignore the whole subdir. Example, I have a library that has a very long directory path (this is simplified) but I want to ignore everything under the top level
Root
> Lib
>> Lib dir 1
>>> file.c
>> Lib dir 2
>>> file.c
The wording
To ignore certain folders you can use -i. This will skip analysis of source files in
the foo folder.
cppcheck --project=compile_commands.json -ifoo
Suggests that it will skip any files in the specified dir, not any subdirs.
Is there a way to skip the dir and all sub dirs?
The way I had to achieve this was generating a compile_commands.json from cmake then write a python script to exclude anything that matched the filter I wanted to exclude, eg /libA/ will exclude anything under libA
erlc -I <abspath-to-include-dir> <module>.erl on the command line correctly compiles <module>
But in the Erlang shell (erl), the following produces errors with "cannot find include file":
c(<module>, [{i, <abspath-to-include-dir>}]).
Why? Shouldn't the behavior of these two ways of compiling files be the same?
Try writing the path as a list of directories, as in {i, [".../here/", ".../there/"]}, even if it's just a single directory.
I'm using Luajit 2.0.4 on Ubuntu 16.04
I have a simple C library.
int five() {
return 5;
}
I compile it like so
gcc -o five.so -shared -fPIC -Wall -Werror five.c
In the same directory I have a lua script
local ffi = require("ffi")
ffi.load("./five.so")
ffi.cdef([[
int five();
]])
print(ffi.C.five())
I've also tried it with an absolute path.
local ffi = require("ffi")
local fh = assert(io.popen("pwd", "r"))
local cwd = assert(fh:read())
print(cwd)
ffi.load(cwd .. "/five.so")
ffi.cdef([[
int five();
]])
print(ffi.C.five())
When I run
luajit five.lua
I get this
luajit: five.lua:6: luajit: undefined symbol: five
stack traceback:
[C]: in function '__index'
five.lua:6: in main chunk
[C]: at 0x004044a0
How do I load a shared object in the current working directory in luajit?
That's correct. The reason is that ffi.C points to a namespace to access the standard C-runtime (plus some additional libraries depending on your OS). From LuaJIT docs:
This is the default C library namespace [...] — note the uppercase
'C'. It binds to the default set of symbols or libraries on the target
system. These are more or less the same as a C compiler would offer by
default, without specifying extra link libraries.
If you want to call a C-function from an external library you need to:
Declare the function to use inside ffi.cdef, so LuaJIT knows how
to call that function.
Import the external library and assign it to
a Lua variable which serves as a namespace for the external
function.
Actually call the function.
Your code can be reworked as:
local ffi = require("ffi")
local lib = ffi.load("five")
ffi.cdef([[
int five();
]])
print(lib.five())
In addition, it's not necessary to add .os suffix. To resolve library names, the package.cpath variable is used. It works like package.path variable. Question marks (?) are replaced by the library name.
$ luajit -e "print(package.cpath)"
./?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so
I have installed Erlang/OTP and Elixir, and compiled the HelloWorld program into a BEAM using the command:
elixirc test.ex
Which produced a file named Elixir.Hello.beam
How do I run this file?
Short answer: no way to know for sure without also knowing the contents of your source file :)
There are a few ways to run Elixir code. This answer will be an overview of various workflows that can be used with Elixir.
When you are just getting started and want to try things out, launching iex and evaluating expressions one at a time is the way to go.
iex(5)> Enum.reverse [1,2,3,4]
[4, 3, 2, 1]
You can also get help on Elixir modules and functions in iex. Most of the functions have examples in their docs.
iex(6)> h Enum.reverse
def reverse(collection)
Reverses the collection.
[...]
When you want to put some code into a file to reuse it later, the recommended (and de facto standard) way is to create a mix project and start adding modules to it. But perhaps, you would like to know what's going on under the covers before relying on mix to perform common tasks like compiling code, starting applications, and so on. Let me explain that.
The simplest way to put some expressions into a file and run it would be to use the elixir command.
x = :math.sqrt(1234)
IO.puts "Your square root is #{x}"
Put the above fragment of code into a file named simple.exs and run it with elixir simple.exs. The .exs extension is just a convention to indicate that the file is meant to be evaluated (and that is what we did).
This works up until the point you want to start building a project. Then you will need to organize your code into modules. Each module is a collection of functions. It is also the minimal compilation unit: each module is compiled into a .beam file. Usually people have one module per source file, but it is also fine to define more than one. Regardless of the number of modules in a single source file, each module will end up in its own .beam file when compiled.
defmodule M do
def hi(name) do
IO.puts "Hello, #{name}"
end
end
We have defined a module with a single function. Save it to a file named mymod.ex. We can use it in multiple ways:
launch iex and evaluate the code in the spawned shell session:
$ iex mymod.ex
iex> M.hi "Alex"
Hello, Alex
:ok
evaluate it before running some other code. For example, to evaluate a single expression on the command line, use elixir -e <expr>. You can "require" (basically, evaluate and load) one or more files before it:
$ elixir -r mymod.ex -e 'M.hi "Alex"'
Hello, Alex
compile it and let the code loading facility of the VM find it
$ elixirc mymod.ex
$ iex
iex> M.hi "Alex"
Hello, Alex
:ok
In that last example we compiled the module which produced a file named Elixir.M.beam in the current directory. When you then run iex in the same directory, the module will be loaded the first time a function from it is called. You could also use other ways to evaluate code, like elixir -e 'M.hi "..."'. As long as the .beam file can be found by the code loader, the module will be loaded and the appropriate function in it will be executed.
However, this was all about trying to play with some code examples. When you are ready to build a project in Elixir, you will need to use mix. The workflow with mix is more or less as follows:
$ mix new myproj
* creating README.md
* creating .gitignore
* creating mix.exs
[...]
$ cd myproj
# 'mix new' has generated a dummy test for you
# see test/myproj_test.exs
$ mix test
Add new modules in the lib/ directory. It is customary to prefix all module names with your project name. So if you take the M module we defined above and put it into the file lib/m.ex, it'll look like this:
defmodule Myproj.M do
def hi(name) do
IO.puts "Hello, #{name}"
end
end
Now you can start a shell with the Mix project loaded in it.
$ iex -S mix
Running the above will compile all your source file and will put them under the _build directory. Mix will also set up the code path for you so that the code loader can locate .beam files in that directory.
Evaluating expressions in the context of a mix project looks like this:
$ mix run -e 'Myproj.M.hi "..."'
Again, no need to compile anything. Most mix tasks will recompile any changed files, so you can safely assume that any modules you have defined are available when you call functions from them.
Run mix help to see all available tasks and mix help <task> to get a detailed description of a particular task.
To specifically address the question:
$ elixirc test.ex
will produce a file named Elixir.Hello.beam, if the file defines a Hello module.
If you run elixir or iex from the directory containing this file, the module will be available. So:
$ elixir -e Hello.some_function
or
$ iex
iex(1)> Hello.some_function
Assume that I write an Elixir program like this:
defmodule PascalTriangle do
defp next_row(m), do: for(x <- (-1..Map.size(m)-1), do: { (x+1), Map.get(m, x, 0) + Map.get(m, x+1, 0) } ) |> Map.new
def draw(1), do: (IO.puts(1); %{ 0 => 1})
def draw(n) do
(new_map = draw(n - 1) |> next_row ) |> Map.values |> Enum.join(" ") |> IO.puts
new_map
end
end
The module PascalTriangle can be used like this: PascalTriangle.draw(8)
When you use elixirc to compile the ex file, it will create a file called Elixir.PascalTriangle.beam.
From command line, you can execute the beam file like this:
elixir -e "PascalTriangle.draw(8)"
You can see the output similar to the photo:
I added
version.target = version.h
version.commands = bash generate-version.sh
QMAKE_EXTRA_TARGETS += version
PRE_TARGETDEPS += version.h
to the project, but it attempts to run "generate-version.sh" in destination directory:
make: Leaving directory `.../qqq-build-desktop'
make: Entering directory `.../qqq-build-desktop'
Makefile:236: warning: overriding commands for target `version.h'
Makefile:233: warning: ignoring old commands for target `version.h'
bash generate-version.sh
bash: generate-version.sh: No such file or directory
make: Leaving directory `.../qqq-build-desktop'
There is $$DESTDIR, but I don't see $$SRCDIR. How to refer to the project directory in qmake (or how to rewrite this)?
My first thought is to try to rewrite
version.commands = bash generate-version.sh
so as not to have to invoke a shell script. Perhaps you can combine all of the statements into one line:
version.commands = echo \'char VERSION[]=\"1.0\";\' > version.h && ls && echo Done
If you are stuck with invoking the script, probably PWD or OUT_PWD are what you are looking for. From the qmake Variable Reference
PWD
This variable contains the full path leading to the directory where the qmake project file (project.pro) is located.
OUT_PWD
This variable contains the full path leading to the directory where qmake places the generated Makefile.
The one caveat that is not mentioned in the documentation is that if you are doing a recursive qmake, PWD refers to where the top level .pro file was read from. Thus if you run qmake -r from {proj-root}, when sub/sub/sub/dir-proj.pro is finally read in, PWD will still point to {proj-root}.
Assuming that generate-version.sh is in the same directory as your top level .pro file, you might try:
version.commands = bash $$PWD/generate-version.sh
I found a better and cleaner solution
version.target = version.h
version.commands = bash ${QMAKE_VAR__PRO_FILE_PWD_}/generate-version.sh
QMAKE_EXTRA_TARGETS += version
The variable _PRO_FILE_PWD_ is documented since qt 4.5 and contains the path to the directory containing the project file in use (Contains the .pro file)
But to access this variable for QMAKE_EXTRA_TARGETS, QMAKE_VAR_ must be appended.
PWD
Specifies the full path leading to the directory containing the
current file being parsed. This can be useful to refer to files within
the source tree when writing project files to support shadow builds.
I use (Linux and g++)
DEFINES += SVN_VERSION=\\\"\""`svnversion $$PWD`\""\\\"
DEFINES += COMPILE_DATE=\\\"\""`date`\""\\\"
DEFINES += SW_VERSION=\\\"\"0.5\"\\\"
which defines the macro SVNVERSON to be the svn version.
To access it from C++:
QString svnVersion = SVN_VERSION;
QString swVersion = SW_VERSION;
Explanation: On the shell I want to see this call:
-DSVN_VERSION=\""`svnversion /path/to/my/source`"\"
As you see some escapes are necessary on shell level. In the .pro-file it then has to be escaped twice.
This works and is easy to understand.
version.commands = ( cd $${PWD}; generate-version.sh )