I have (load "foo.import.scm") and when i compile everything works, as long as i execute the program from the same directory. Otherwise it complains about not being able to find "foo.import.scm"
Error: (open-input-file) cannot open file - No such file or directory: "foo.import.scm"
if i do
csc -s foo.scm -emit-import-library foo
and then
(import foo)
it compiles fine but then complains about
Error: (require) cannot load extension: foo
when run from a different directory
if i do
(use foo)
then it complains about
Error: (require) cannot load extension: foo
when I run it from a different directory.
What is the correct way to load this module into my program such that it will be included in the executable? Should be passing a different flag to csc ? The docs are not making the solution clear to me.
load is by definition a runtime thing. It's basically (eval (cons 'begin (read-all))) (with the caveat that CHICKEN can also load binary .so files). load will always load from the current directory, unless you use an absolute path.
If you want to use the module in a compiled program, don't load the import library; the compiler will do that automatically when you (use) the corresponding module.
Maybe you can explain a little bit more about your project structure? The question isn't exactly clear on what goes where.
Related
I am trying to build a kernel module while compiling the kernel image, by changing the config symbol value to `'m'. But I do not see any module file generated. Please let me know if I need to take some extra steps to generated a module. If I change the flag to 'y' the code works fine.
Also, in online tutorials I have seen both of the following
>insmod temp.ko
also,
>insmod temp.o
Which one is correct type for a dynamically loadable module?
For compiling loadable kernel modules in Linux tree apply the following command
make modules
.ko is the proper kernel module extension. If .o is tried with insmod, then Invalid module format error will be displayed.
if your module has dependencies to other modules, then:
make modules to build modules
make modules_install to install them
modprobe temp.ko to load temp module and it's dependencies
if your module is simple and has no dependencies, then:
make modules to build modules
cd /path/to/module
insmod temp.ko
Wasn't using modules target in make.
First, run make menuconfig, search the module you want to build using /. Next choose 'm' or 'y' depending on when you want to compile it as a part of the kernel or build it as a module.
(If you don't want to build the entire kernel and just a single module):
Next, in the linux directory (assuming you are using vanilla kernel) run the following commands which will generate the scripts and required configuration files based on your .config
make prepare
make scripts
Now simply build the module using:
make M=<path/to/module/dir>
Finally you should have a kernel object/module (.ko) in the directory if you have selected m
hope this helps.
My .la file has full pathnames in both the dependency_libs= section and the libdir= section which makes it difficult to copy my libraries to a different machine (same arch but different path structure). What is the solution to this, besides having some script to hack the .la file to adjust for the paths on the new machine?
==Details==
When I ./configure; make; make install my libfoo, depending on how I use the --prefix, --exec-prefix, and DESTDIR= flags, I'll get an entry in the libfoo.la file that reads libdir=/dir1/lib and I'll have the actual .so files in the same dir as libfoo.la. All is well (in terms of linking something with libfoo as it is) until I package these up and put them on another machine.
Let's say I have libbar on my second machine which depends on libfoo. When I use my -L/dir2/lib flag to look for -lfoo, the libbar compilation/linking fails because of the libfoo.la file is expecting foo to be installed in /dir1/lib (from the first machine) when it's actually in /dir2/lib. I then need to replace all of the dir1's with the correct path, both of which can be long and complicated.
The dependency_libs= line also comes into play in a similar manner.
How do I avoid this problem?
I'm trying to make an executable from a couple ruby files on Windows, so I installed Ocra. I thought I understood the process of how Ocra works, but can't seem to get the executable working correctly. The problem I am having arises with "requiring" other ruby files.
The ruby program by itself compiles correctly and functions how I want it to, and Ocra seems to create a working executable, however, when I attempt to run the executable, I get the following error:
*/custom_require.rb:36:in 'require': cannot load such file -- MainMenuDialog.rb (LoadError)*
My main program is called 'JobManager.rb' and it is creating a new MainMenuDialog object, therefore I include MainMenuDialog.rb in the top of the file as such:
$: << File.expand_path(File.dirname(__FILE__) + "/../lib")
# Other requires here
require("MainMenuDialog.rb")
Again, the program compiles and runs perfectly fine by itself (including the require statements), and when I run the command ocra JobManager.rb it successfully runs the programs, checks for dependencies, and creates the executable. I just can't run the executable because of the "LoadError" described above.
Any thoughts on what I'm doing wrong? Thanks in advance!!!
With ruby >= 1.9 you may try require_relative.
Explanation: ocra stores all files in its own subdirectories.
If you manipulate the load pathes ($:) you can't be sure, what ocra uses during execution.
This question is old and answered, but I wanted to include this little nugget I found in Ocra documentation, because the correct answer here did not resolve my issue:
OCRA does not set up the include path. Use $:.unshift
File.dirname($0) at the start of your script if you need to 'require'
additional source files from the same directory as your main script.
I put some functions in a file. Where on my PC should I save this file so that I can easily load my functions?
I am using the Haskell Platform on a Windows 64-bit computer.
I usually put my modules in the same directory tree, and start up ghci at the root directory of the tree. Then modules can import each other, and I can easily :load modules into ghci interactively.
$ ghci
.... loading ....
Prelude> :load directory/subdirectory/mymodule.hs
If you want your modules to be accessible from a few different projects, I'd recommend to create a cabal package for them and install it using cabal install. Publishing to hackage is not required - cabal install without arguments looks for .cabal file in the current directory and installs the corresponding package.
If you want your modules to be accessible from a single project - the usual practice of organizing your sources in a hierarchical folder tree applies to Haskell as well. Let me show an example:
Hello/World.hs
Foo/Bar.hs
Quux.hs
Hello.hs
Hello/World.hs should have module Hello.World where in the header. The main module should have module Main, but actual file name can be anything (e.g. Quux.hs). In Foo/Bar.hs you can use import Hello.World. When you load Foo/Bar.hs in ghci, the current directory should be the root of your tree, or else it will not find Hello.World. You can pass module names instead of file names to ghci: e.g. ghci Hello.World will work.
Here are the documentation:
http://haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html
http://haskell.org/ghc/docs/latest/html/users_guide/packages.html
When trying to load a Lua module on OSX I receive the following error.
lua: level1.lua:1: module 'libexpand_luaLib' not found:
no field package.preload['libexpand_luaLib']
no file './libexpand_luaLib.lua'
no file '/opt/local/share/lua/5.1/libexpand_luaLib.lua'
no file '/opt/local/share/lua/5.1/libexpand_luaLib/init.lua'
no file '/opt/local/lib/lua/5.1/libexpand_luaLib.lua'
no file '/opt/local/lib/lua/5.1/libexpand_luaLib/init.lua'
no file './libexpand_luaLib.so'
no file '/opt/local/lib/lua/5.1/libexpand_luaLib.so'
no file '/opt/local/lib/lua/5.1/loadall.so'
stack traceback:
[C]: in function 'require'
level1.lua:1: in main chunk
[C]: ?
The lua interpreter is trying to load a .so file and not a .dylib file. I was under the impression that .dylib is the OSX equivalent(with slight changes) of .so. So I'd expect the Lua interpreter to be looking for a .dylib file.
Should I be trying to compile my library into a .so on OSX?(If so how?) Or should I be changing something related to the lua interpreter?
No need to change the interpreter (provided that the .dynlib is loadable (as per Programming in Lua, chapter 26 )).
You can change the package.cpath to look for .dynlibs instead of .so's, before requiring the module.
package.cpath = package.cpath .. ";?.dylib"
print(package.cpath)
rtn = require ("libme")
print(rtn)
Works just fine on osx.