i have compiled and installed igraph according to the documentation and no errors occurred, additionally i can use and compile the library just fine (I use CLION). No the code completion does not work for some of the functions, they seem to be quite basic functions. So I checked if my IDE know the header files installed, located in /usr/local/include/igraph (i use CentOS). It knows them, so i used grep to search through them to find e.g. igraph_vector_init, and it is nowhere to be found! No of course I would like the code completion to work and I am at a loss since the appropriate header files do not seem to contain the declarations of often-used functions! Is this a problem with my build? I also checked the online repository, without avail. Additionally I checked that the examples (which use the functions) and the documentation match the version, they do. What could I possibly miss?
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'm trying to build the OpenCL ICD Loader in mingw gcc - no problem to use mingw-w64 instead, it's just that mingw is what I have installed already. I don't use Visual Studio - I don't hate it, I know there's free versions, it's just not what I'm using.
The OpenCL ICD Loader doesn't build in mingw gcc. The main reason is because of lack of DirectX 10 and DirectX 11 support. But all the ICD Loader does is get a dispatch table (presumably from the OpenCL driver/whatever it loads) and provide functions that call through that dispatch table. Some minor changes to the conditional compilation in icd_dispatch.h and icd_dispatch.c can omit the relevant functions and remove the dependency (as already has to happen for Linux builds), and it actually looks like this may have been supported in the past - there's preprocessor symbols cl_khr_d3d10_sharing and cl_khr_d3d11_sharing already defined if relevant headers are included, they're just not being used to conditionally compile the relevant chunks of code.
So there's that and telling the code to omit DirectX10 and DirectX11 functionality in the first place (I just commented out a couple of header-file includes, though that's obviously not a real solution). But then there's one more problem...
The file icd_windows.c uses the Windows API function InitOnceExecuteOnce - MSDN docs here. mingw (and I think mingw-w64) doesn't support this function - the def file for Kernel32.dll lists it but neither the function nor the related identifiers INIT_ONCE, INIT_ONCE_STATIC_INIT and PINIT_ONCE are provided by header files.
The MSDN docs IMO don't explain this very well. It can't be essential (it didn't even exist before Vista) and it has something to do with safe initialization of DLLs, presumably in a multithreading context.
Unfortunately, if I don't really understand what it does, then I can't implement a workaround for its not being there.
Clearly this Windows API isn't specific to OpenCL, so presumably this is an issue that other people have run into for other projects. So is there a standard workaround for this?
Or failing that, can someone explain what is meant particularly by "synchronous one-time initialization"? Sorry if that's a dumb question, I don't have much experience of multithreaded, I'd have thought one-time initialization is just that, irrespective of synchronous vs. asynchronous - so long as a second thread can't re-enter the initialization, you don't want to initialize again, so there's nothing to do synchronously vs. asynchronously anyway.
Or does it mean that if another thread tries to call the initialization, it will wait for the already-running initialization to complete before it fails (or possibly succeeds without re-doing the initialization)?
I wasn't sure the opencl tag was appropriate, decided to include it because of the context, sorry if that was wrong.
I came across the same problem. You have to add following line at beginning of icd_windows.c, before all #includes:
#define _WIN32_WINNT 0x0600
This helps with missing InitOnceExecuteOnce declaration. I also had to modify CMakeLists.txt, replaced SHARED with STATIC in line 22 which is responsible for linking libOpenCL. I did this because linker complained about missing ld lib:
add_library (OpenCL STATIC ${OPENCL_ICD_LOADER_SOURCES})
After doing these two things I got libOpenCL.a in build subdir. Compilation continued and failed with some other error, but I ignored this. I took created lib and successfully used it to build simple OpenCL app which lists all available platforms, devices and their details.
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.
This is for my company, so I'm leery of being too specific, but I'll try.
I am attempting to add support for some existing ANSI C code to our platform. I am using GCC 4.7.2 as well as the GNU linker. We use part of newlib, but also some other C libraries, specifically libc.a. The end goal of this is to get an EXE or ELF image (this is for a PowerPC architecture micro) to put into the micro's RAM. This is being done on Windows XP. I am simply using a batch file, not a build environment or toolchain.
One of my build errors is a multiple definition problem of malloc/free functions. The cmd window spits out the error that there are definitions of these in both malloc.o and mallocr.o. Both of these are within libc.a. I've been told the "r" in mallocr.o is for reentrancy. I've also been told our platform does not support reentrancy.
I'm trying to resolve this error by preventing the linking of mallocr.o from within libc.a. This is the part where I am lost, I don't know how to do this. Google hasn't turned up anything helpful, and I haven't found a question on this site yet that answers my problem. I don't know if this is even possible.
There is really no specific code snippet to include in this question. Below is the error from the cmd window. I've *'d out company specific things I am not comfortable sharing.
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(mallocr.o): In function `free':
mallocr.c:(.text+0x19c): multiple definition of `free'
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(malloc.o):malloc.c:(.text+0x28): first defined here
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(mallocr.o): In function `malloc':
mallocr.c:(.text+0x468): multiple definition of `malloc'
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(malloc.o):malloc.c:(.text+0x0): first defined here
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.