Problems building python interpreter with custom module - c++

I am trying to build the python-2.6 interpreter on Linux with a custom module embeded into the interpreter. I tried following the instructions on 'Extending Python with C or C++' from the Python documentation but something keeps on going wrong. I keep getting the following error when building :
make: *** No rule to make target `Modules/_custommodule.c', needed by `Modules/_custommodule.o'. Stop.
I've checked the generated Makefile and it does contain references to my _custommodule.c file and has the proper libraries linked for dependencies but is not being made for some reason.

That's usually because you don't have a file called custommodule.c available to make. Check that:
that file exists.
you're in the right directory when you make.
If that doesn't work, Edit your post with a directory listing of that directory.

Related

LNK1181 Error while compiling the core after adding a module

I'm trying to compile my core with some modules but i'm getting the following error when building worldserver:
cannot open input file '..\..\..\modules\RelWithDebInfo\modules.lib' worldserver
This error only happens when compiling with the mod-gain-honor-guard module. I've installed a repack before that came with this module pre-installed, which makes me think that i'm the one missing something.
Any ideas?
Thanks!
I've compiled the core succesfully with only one module, then i've added the one mentioned before and that error came up. CMake didn't show me any error when i regenerated the source for building after adding the module
You always need to regenerate the source in CMake when you add or remove any files to the source.
Did you get the module via git clone? If not, and it's a direct download, you need to remove the -master or any other branch name from the folder name.

How to overwrite LD_FLAGS set by any bbclass in custom yocto recipe?

In my yocto project, I have a application recipe that builds an executable from cpp source files for target arch.
It has also support to generate build for native target(Ubuntu 16.04), for which BBCLASSEXTEND = "native" line is there in the recipe file. the executable is generated for native target just works fine on the same machine.
But the ldd command on the executable shows that the dynamic-loader(ld) used with the executable is not the default(/lib64/ld-linux-x86-64.so.2), it is using custom ld-linux-x86-64.so from build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, However it is linked to the default loader. But if we run the same binary on different machine, this sysroot-uninative path will be unresolved which results the binary to not run on other machine of same architecture. running in different machine shows error "No such file or directory".
After detailed exploration I got to know that the --dynamic-linker (linker-flag)is set by uninative.bbclass in the LD_FLAGS. which is default inheriated in poky/meta-poky/conf/distro/poky.conf.
Removing that line from poky/meta-poky/conf/distro/poky.conf file resolves my issue but i don't know its side effects.
So anyone can suggest me, How we can overwrite the LD_FLAGS value in my recipe.bb file? so that I can remove the --dynamic-linker flags value or overwrite with default loader(/lib64/ld-linux-x86-64.so.2)
Thanks in advance.

"symbol lookup error:" when executing from different directory, otherwise working as intended when executed from build directory

I have a weird problem on Ubuntu Linux 18.04 that appeared after having run pytest a couple of times. The project is mostly c++, but it also generates pybind11 bindings and generates library files via CMake.
My goal is to force a program to output its files into a specific directory within the project folder, i.e. not in the same directory where the executable file is. I used to achieve that by running this command:
user#computer_name:~/Dev/project$ (cd /home/user/Dev/project/unittests/test_output && "/home/user/Dev/project/./executable" -pdbin /home/user/Dev/project/unittests/test_data/3v8x.pdb -mtzin /home/user/Dev/project/unittests/test_data/3v8x_phases.mtz && cd /home/user/Dev/project)
This command used to work as intended, until today, when I ran some instances of pytest. While pytest is able to complete all tests successfully, my aforementioned command does not work anymore and gives me this error:
user#computer_name:~/Dev/project$ /home/user/Dev/project/./executable: symbol lookup error: /home/user/Dev/project/./executable: undefined symbol: _ZN7library7Class11functionEv
However, when I try to execute the executable in the build directory, like this:
user#computer_name:~/Dev/project$ ./executable
There is no error whatsoever and if I try to give the program its input, the program works as intended without any errors. However, it outputs the files in the build directory - the place where I don't want the output to go.
For further confirmation, I tried to execute the program from another directory again without giving it any input:
user#computer_name:~/Dev/project/unittests$ .././executable
to be greeted yet again with this error:
.././project: symbol lookup error: .././project: undefined symbol: _ZN7library7class11functionEv
So far I've tried to rebuild entire project, generate new Makefiles etc.
I also confirmed that there are no issues with the program itself. Any ideas on how to fix this issue or alternative ways to direct output to different folder without having to pass specific output arguments to the program itself?
If you want executable to pick up the libexecutable.so next to it, you have two options:
Configure LD_LIBRARY_PATH to contain /home/user/Dev/project.
This will make the dynamic linker search there before any other configured directories.
Either do this globally or in a wrapper script.
Compile executable with an rpath. This will make library lookups by executable look in the rpath first. If you pass the -Wl,-rpath,'$ORIGIN'/.. flag (note the single quotes around $ORIGIN!), the dynamic linker will always find libexecutable.so next to executable first.

Creating ruby gem out of swig generated cxx wrapper

I have now spent days on this. WHAT am I doing wrong?!
I have a swig generated wrapper for a c++ library I'm interested in using (COIN-OR). So I wrote a c++ struct that has all the methods I need from coin, and I have written a Swig interface file awcbc.i. I then wrapped it with swig, and this generated a awcbc_wrapper.cxx file.
I have an extconf.rb file, which creates a makefile from this. I included the necessary libraries like this:
with_cflags("-x c++") do
abort 'missing cbc' unless find_library("Cbc", nil, "lib")
abort 'missing CbcModel.hpp' unless find_header("CbcModel.hpp", "include/coin")
abort 'missing awcbc.hpp' unless find_header("awcbc.hpp", "include")
end
"lib" is full of dylibs, one of which is Cbc. Similarly, CbcModel.hpp is one of the many headers in include/coin. The point of these is to include those directories, and thus all my dependencies into the search path. awcbc.hpp contains my struct.
When I run
$ ruby extconf.rb; make;
it creates a makefile and compiles it. I can then run irb, require awcbc, and it's all there and working.
However, when I try to put some of this into a rakefile (I've tried Jeweller, following the format set by a very similar library heroku-rglpk, or tried to use rake-compiler, as described in ruby-guides, I get
ERROR: Error installing ./pkg/awcbc-0.0.0.gem:
ERROR: Failed to build gem native extension.
/Users/*...*/.rbenv/versions/2.1.2/bin/ruby extconf.rb
checking for main() in -lCbc... no
missing cbc
*** extconf.rb failed ***
But it didn't fail when I called ruby extconf.rb manually!
This is one out of several nightmares in getting this fairly simple extension built.
What I'm shooting for, is a gem that I can put on ruby-gems which is basically the exact same thing as heroku-rglpk. I want it to check for Coin-Or, install if not there, wrap it, and gemify it. It's so frustrating that I can make the wrapper, and use it, but then I can't gemify it (and incidentally, this means I have NO IDEA how to include it in my rails app).
Bah. Can anyone help?

Installing a cpp library on linux

I'm trying to install a library (libspopc), but, when I run the make command, I get the errors:
strip libspopc.a libspopc.so
strip: 'libspopc.a': No such file
strip: 'libspopc.so': No such file
make: *** [install] Error
Working under the assumption that every version of the library I've tried isn't actually missing two of its files, what could cause this? I am running it as su, as instructed, if it's relevant.
While this question is only remotely related to programming (seems more like something for superuser.com), on linux you should whenever you can use the package manager of your system. In most cases, it let's you fetch the files as binaries (thus avoiding possible compilation frustrations), keeps your system clean and is (most importantly for me) easy to remove again. Oh yeah, and it helps you keep the library up to date.
Try looking in your package manager! If it's a fairly popular library, it's probably in your package manager's repositiories!
At least I know it's in mine!
$ bauerbill --aur -Ss libspopc
AUR/libspopc 0.9-1
A simple pop3 mail client library