Though this is my first question on the StackOverflow, I consider myself a long time member of the community.
Considering myself as a pre-intermediate programmer, I'll try to be as specific as possible.
I'm writing a Python package that uses a C dll to load image files with ctypes. I'm using Python 3.3.5 32bits version on Windows 8 x64. I had to build the dll from the C code. The dll is stb_image.h which is available in GitHub. I used Code::Blocks version 13.12 with the GCC compiler. The dll seems to have built fine.
By my definition, the dll is must be in the same folder as the py code file that wraps its functions, but when ctypes attempts to load the dll an exception is raised: the [in]famous WindowsError: [Error 126] Module not found.
I've found several similar questions and attempted to glean from their solutions by
adding the dll path via os.environ['PATH']
adding the dll path manually in the Path environment variable
changing the current working directory with os.chdir()
using the file module attribute to locate the library
none of these solved the issue
The stb_image library itself has no dependencies so I don't understand why windows can't find it since the dll is where it should be and the path addresses it's exact location. And, of course, there's a lot of other ways to get the job done: PyGame, pySFML (which also uses stb_image), PIL, PyPng, PySDL, you name it, but I'm doing this mostly for learning purposes.
At the writing of this question, something popped up in my head (which may or may not have any relation with the problem): whenever I compile and link programs with GCC and try to run them, I got a message box telling me that some dll (libgcc.dll or something like that) was not found. Could that be the reason Windows can't load stb_image.dll?
I tried everything my experience allowed me to do to solve it but it was not enough. Would you guys, please, give me a light on this?
PS.: Sorry for any bad english. I'm natural from Brazil.
Related
So I am in a bit of a pickle here and am at my wits end.
Issue:
I have made some lua C module that target another package's C++ shared library. Attempting to require the Lua module fails due to a dependency issue. I can find the module shared library just fine but when the linker attempts to find the library I need to link against, I get an error that looks like:
/usr/bin/lua: error loading module 'mytest' from file '/usr/lib/lua/5.3/mytest.so':
Error loading shared library libmy_test.so: No such file or directory (needed by /usr/lib/lua/5.3/mytest.so)
The directory structure used for linking is
|-usr
|--lib
|---lua
|----5.3
|-----mytest.so
|-mockfs
|--usr
|---lib
|----libmy_test.so
My LUA_CPATH is:
/usr/lib/lua/5.3/?.so;/mockfs/usr/lib/?.so;
My LD_LIBRARY_PATH is:
/mockfs/usr/lib/
What is driving me mad is that when the libmy_test.so is in the same directory as mytest.so, there are no problems. But due to other restrictions I cannot modify the path of libmy_test.so or add a symlink without substantial refactoring and lag time for builds/regressions. I'm unsure of where to even continue here because it is definitely a "searching for the library" problem but I don't know how to get insight into what is going on under the covers to fix the issue.
Adding /mockfs/usr/lib/?.so to LUA_CPATH is not going to help, as it only works for Lua modules loaded with require (which already works in your case for mytest.so) and doesn't work for loading their dependencies (which should be handled using dynamic linking).
It's not clear if LD_LIBRARY_PATH is even used in your case; I'd set LD_DEBUG=all to get LD troubleshooting information, which should tell you what is or is not being loaded and why.
Also, even if you can't put libmy_test.so where mytest.so is located, you can still put mytest.so where libmy_test.so is and configure LUA_CPATH like you have to try making it work that way.
So this will be unrelated to other people's Lua code. This problem description is slightly abstracted from reality as there is a lot of internal tooling from my company in front of it. I followed Paul's answer to try and get more information, LD_DEBUG was working up until I called my Lua script. Then the linker would stop giving me any information even though the require was still failing with the same error.
After a LOT of digging and my personal discovery of strace I managed to identify that the linker being used when calling require was in fact using "LD_PATH" to search for libraries instead of "LD_LIBRARY_PATH". Why this was? I still have no idea other than maybe an intentional design decision to combat some of the limitations of our internal tooling when doing cross compilation.
For anyone who experiences linker issues with Lua, LD_DEBUG and strace are very nice utilities for running down your issues.
I have no experience with C/C++. I do not know how to even open files. I am working with SLN files in Visual Studio 2019 trying to compile a program I took off of GitHub (https://github.com/Marlowe97/Expected-Force).
I get these two errors (LNK2005, 'main already defined in TestExpectedForce.obj, and LNK1169 'one or more multiply defined symbols found') when trying to compile the Expected Force solution. The only changes I've made from the downloaded files are the ones directly stated in the instructions on the GitHub page of the program.
Is there someone who can tell me what to look for in as plain of a way as possible? I know basic Python and R so I understand some terms, but I know nothing about C so no other posted solutions to these errors make any sense to me. I'm already pretty concerned that I'm getting errors after following the step by step instructions from GitHub on what seemed to be a pretty basic task.
It's a strange package...
The functionality is provided as a library, to be compiled into your own project.
There are TWO test source files: TestExpectedForce.cpp and TestExpectedForce.cpp, each of them contains main().
They should be in their own projects (possibly, under the same solution).
To quickly move forward, just remove one of the test files from your solution.
I'm struggling with the Code::Blocks IDE when programming in C.
I use one custom library, named "main.h".
Yesterday, when I begun working on the library, the program compiled without errors. I even put some functions written on the library on my source file and it built and ran fine.
Today, when trying to recompile the whole project after some modifications, appeared the "undefined reference" error.
I searched it over on this site, I tried to follow the steps another user proposed but now, instead of the "undefined reference" error, appears the "cannot find -l[filename]".
I tried to collect information about this error on this site as well but, I understand, it's a OS problem and, apparently, never happened to other Code::Blocks users.
I use Windows 7 64 bit, in case this is the problem.
Can you please help me?
Try to put fullpath to library in build options of your project and be sure to put it in the right build scheme(Debug/Release) or both to be sure.
However it is quite strange name for library - "main.h". Is it "main.h.dll" or what? Maybe it is header file? If it is so and you put implementation of you functions in .h file and not in .c, some errors could occur.
I've been trying to compile balsa the email reader on ubuntu (i'm new to the whole process of compiling an open source project directly from sources.
so i did the whole configure and make but then I ran into this problem:
error: unknown type name 'gpgme_decrypt_result_t
after doing a little research on the error code.. it turns out that it belongs to gpgme a scary looking encryption library..
what do I do in this case? i hope i'm not expected to go in the code and debug stuff am i?
update:
this question is related to this other question here on the ubuntu forum
Unfortunately, you may be required to delve into the code to figure out why something doesn't build!
In this case however the answer is probably quite simple. The main reasons I would expect a symbol from an external library to not have been defined are:
The library header files do not exist on your system
You have the wrong version of the library header files on your system
The headers exist, but the compiler is not looking in the correct place
Clearly the solutions are similar: you will need to install the correct version of gpgme's header files for this software in the right place. Note that having the library itself installed is not the same as having the headers. In Ubuntu this is evident due to the presence of -dev packages which are the package's header files, and if you look through the repose you will find libgpgme11-dev. I suggest you start by installing this, which will eliminate point 1 above. If it still doesn't work, you'll need to start investigating the other two possibilities.
I'm getting crazy while trying to understand how to produce a binary in OCaml that doesn't need anything too specific (eg. having anything as OCaml build tools installed).
I'm using OMake and everything seems enough cool while working on my machine, also linking libs with
OCAMLPACKS[] = str unix batteries
works quite well, but if I try to distribute the executable it gives me the following error:
Fatal error: exception Sys_error("/usr/godi/share/camomile/database/general_category.mar: No such file or directory")
yes I'm using GODI but I don't see any apparent reason for this error, can anyone enlighten me? In addition, if you have any tricks regarding building stand-alone applications please tell me (I'm already arguing with GODI that compiled everylib just in its x64 version and now I'm unable to produce x86 executables)
Thanks in advance
The camomile library requires runtime configuration. See README.txt for informations about how to set it up.
In particular, it requires runtime files (the missing .mar you see) to correctly work.
I don't use OMake, neither batteries, neither GODI nor Camomile. But from what I see the problem seems to come from the fact that you link against Batteries which I guess must use Camomile internally and Camomile relies on data stored in the file system to provide some of its service. It fails to load if that data is not present on the final host.
Note that shipping purely static excutables is something that is fairly simple to do with OCaml. But for that you need to consider which libraries you use (e.g. if you use camomille you will have to ship the support files with).