I compiled libAPR sources and ran successfully all tests provided by Apache.
However when I link my program to libapr.so the same functionality is not present.
For instance, apr_pollset_add primitive doesn't work. It returns always 1 (when it should return 0) and doesn't work (in the source test works like a charm).
I modified all the code of APRlib related to that primitive so it would just return -1. When I run the Apache tests, they present expected behaviour (return -1), however once again when I call the primitive from .so libs it is always returning 1.
I am almost sure the lib has just a wrapper on that function wich returns always 1.
Any clue on what is happening?
So finally I found the problem.
I had libapr already installed in my system, so whenever I would use -libapr-1, it would link my program to the previously installed version of libapr. That was the reason it was not responding to my code modifications.
Regarding apr_pollset_add primitve, it is working well. The error is returned by the system when apr calls poll_ctl, because I was adding a regular file descriptor which is not accepted.
Related
I have an existing .so library (libgit2), and I would like to use this within a C program (the build system is Scons). I read through the entirety of the Scons documentation for "Chapter 4. Building and Linking with Libraries", but there is no mention of how to use an existing .so library. The only mention of .so in the entirety of chapter 4 is on the first page, and it is only about Scons using a .so file for output. How do I use an existing compiled .so library in Scons?
If you are using an sconscript then you should add a LIBS= arguments and a LIBS_PATH=.
if you want to directly add it to the build line, use -L for lib path and -l to link a lib.
You can find further information here: https://scons.org/doc/0.97/HTML/scons-user/x628.html
With help from the SCons Discord server and other places, I've gotten farther than when I first posted this question. I haven't solved my specific problem of using .so libraries with GDNative, but I think I've figured out the SCons side.
As of me posting this question, the SConstruct file was able to compile working code if I didn't use libgit2 and instead just printed out the text. With only the header included, my test call to git_libgit2_version compiled but didn't run, as Godot said undefined symbol: git_libgit2_version.
First of all, you need to add the named parameter for LIBS to your env.SharedLibrary or env.Program line. The lib prefix and .so suffix seem to be added automatically, I still haven't figured out how to make it point to libgit2.so.1.0.1 (so for now I have the library copied and named as libgit2.so, but I would like to have it point to libgit2.so.1.0.1 eventually instead). Also, the SCons team suggested adding LIBPATH, but this doesn't seem to actually do anything.
library = env.SharedLibrary(target=env["target_path"] + env["target_name"] , source=sources, LIBS=['git2'])
Then, the SConstruct file needs to have this magic line:
env['STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME'] = 1
With the above code, ldd will report not found, and Godot will say Error: libgit2.so.1.0: cannot open shared object file: No such file or directory (I have no idea why it's asking for .so.1.0 instead of the .so or .so.1.0.1 file, and yes I tried copying and naming as libgit2.so.1.0 and that doesn't change anything either).
I also added this, which was suggested by another GDNative user.
env.Append(LINKFLAGS=[
'-Wl,-rpath,addons/git_for_godot/gdnative/linuxbsd'
])
With all of the above code, this seems to allow ldd and Godot to find the library just fine with a relative path (when running ldd you have to be cd'd into the project folder). I can run the project fine without any errors, but the project crashes immediately after opening, with no error messages printed. If I comment out the call to git_libgit2_version but keep the header included, the file does compile and run. Any time I try to call anything from libgit2 it causes Godot to crash without printing any errors. At this point I'm stuck and I don't know what I'm doing wrong.
I did try adding libgit2 to the Dependencies section of the .gdnlib file, but this doesn't seem to affect anything. Another thing I tried which didn't work is this line (+ variants on the extension) which append to the sources list passed as the named source parameter. I'll post it here for completeness, but for the moment I have this line commented out because it doesn't work:
sources.append(File("project/addons/git_for_godot/gdnative/linuxbsd/libgit2.so"))
I have successfully taken bio-metric prints and posted to the node server using the futronic sdk. I want to be able to use this library likewise for matching in the server because that's where the bio-metric prints for all users are stored. I stubbled upon the node-ffi library that helps define equivalent C functions that I have exported and compiled it down to a .dll file.
Now the challenge here is that I have tried to port the ftrAnsiSDK functions but the ftrScanAPI.dll and the ftrAnsiSDK.dll file could not be compiled together. It gives this error:
...collect2.exe [Error] ld returned 5 exit status
When I compile and export the functions that are not dependent on these two libraries, my code works fine and the functions are easily exported and used in the node server. Please can any one give me a hint?
Here is the link to the repo. It consists of the lib and .dll library that is been used.
For the server code here is a snippet of what I am trying to achieve:
var libm = ffi.Library('lib/visystem', {
'HelloWorld': [ 'void', [] ],
'PrintErrorMessage': [ 'void', ['int'] ],
'CaprureImage': [ 'int', ['int','int','int'] ]});
The HelloWord and PrintErrorMessages are methods that I used as a test case to ensure the functions are being exported before I proceeded to the main functions (you can see the function definition in from the code in the repo.. ) that depends on the futronic lin and sdk.
I am currently using a 64-bit operation system and I installed the same program on a 32-bit machine to be sure, but it still did not compile and export the function. The code editor I am using is Dev++C.
Can anyone help or even give me hint on how to achieve this goal?
As a disclaimer, I'm not familiar with the Dev-C++ IDE or MinGW development.
However, after a cursory look at your github repo, according to your libvisystem.def file, it appears that the only functions that are exported by your DLL are:
HelloWorld
PrintErrorMessage
ReadTemplateFile
SaveBmpFile
SaveTemplateFile
This is also confirmed when looking at the libvisystem.a library header:
So you should probably start by manually add the rest of the exported functions in your dll.h to the def file, in a similar manner to the ones that are already there, and see if that changes anything.
NOTE:
I'm not sure whether the __declspec(dllexport) directive is ignored by the Dev-C++ compiler/linker and it uses the def file instead. Perhaps others on SO have an idea.
I'm trying to use the GnuTLS API on a window machine, sadly it will not work. I downloaded the latest precompiled version for Windows gnutls-3.3.9-w32.zip.
Each time I call a GnuTLS function, my program wont work probably. For testing there are only two lines of code:
printf ("hello");
gnutls_global_init();
it will build without errors but it won't print "hello", if I delete the second line it works. So there must be a mistake within the usage of GnuTLS.
I included the libgnutls-28.dll
gcc "-LC:GnuTLS\\gnutls-3.3.9-w32\\bin" -o Test.exe test.o -llibgnutls-28
Do I have to link the libgnutls.dll.a file somehow?
Do I have to link the libgnutls.dll.a file somehow?.
Yes. Linking libraries is required for building. But you said it is building okay... In support of what Marc B was saying, test to see whether your printf is working:
printf ("hello");
getchar(); // to stop execution before calling init
//Check the return of your init function
status = gnutls_global_init();//On success, GNUTLS_E_SUCCESS (zero) is returned,
For testing there are only two lines of code:
Add a few more to check status of your init function:
if(status < 0) //otherwise an error code is returned.
{
//handle error
}
Click gnutls_global_init for man page.
Another thing to check is where you have the .dll located.
Ensure it is visible to the executable at run-time. Put it in either in the .exe. directory, or in the $SYSTEM$ directory, for your system.
One gottcha for people is WoW64. The Windows system directory for 32 bit applications on Windows 7 (or 8) is c:\windows\sysWoW64\ (i.e. not c:\windows\system32). Ironically, the system directory for 64 bit apps is c:\windows\system32\ .
I had some lua code with the following line:
JSON = loadfile("JSON.lua")()
The file JSON.lua is in the same directory as the lua code that line came from. This code worked for me for a while, and then, without my changing either the lua source, or the JSON.lua, or permission of any of the files, or the directory from where I was running the lua code, I started getting a nil error on that line. (I simply recall NO relevant changes that could have any impact on the lua code.)
Adding an assert revealed that the error was caused by the file not being found. Playing with file permissions, restarting my machine didn't resolve the issue, and pulling back code that I had checked in and was working perfectly did not resolve the error.
I resolved the error by changing the line above to provide the absolute path to that JSON.lua file.
Is there anything explaining why the code without the absolute path could have worked for a while and then stopped working?
Note: This behavior of working and then not working happened to me twice over a week. I am puzzled and though I have now found a fix, I am really curious as to the explanation for that intermittent behavior.
Lua uses package.path, whose default value comes from the environment variable LUA_PATH if it is set, as the list of directories to search. You can put . of the front of this list to load files from the current directory, or you can put your files in a path on the list.
A late answer on this, as I found exactly the same problem.
First, contrary to the previous answer, loadfile doesn't use the package.path search path. It only looks in the specified directory. And if you don't specify a directory, it only look in the 'current directory'. I can't explain exactly why it stopped working for you, but probably your Lua code is somehow being run with a different 'current directory' than previous.
There are two possible fixes: One is to specify an absolute path to loadfile.
JSON = loadfile("c:\\my_folder\\JSON.lua")()
The alternative fix depends on the particular library you're using, which I suspect is Jeffrey Friedl's Lua JSON lilbrary. Because this supports the newer Lua module mechanism, you can just load the module with require, which does support the package.path search path.
JSON = require("JSON")
According to the CUDA Programming Guide , Page 122, it is possible to dynamically allocate memory inside a device/global function so long as we're using compute architecture 2.x.
My problem is that when I attempt this I get the command line message:
The command "some command" -gencode=arch=compute_10,code=\"sm_10,compute_10\" -gencode=arch=compute_20,code=\"sm_20,compute_20\" etc...
This is followed by an error saying that you cannot call a host function (malloc) from a device/global function.
The above message is showing that it is attempting to compile under compute 1.x. I am using VS2010 and have "Code Generation" set to "compute_20,sm_20" in the "CUDA C/C++" property page, so I am not sure why it is still trying to compile under compute 1.x. I am definitely using a card that supports 2.x. Any ideas?
You should be able to see the nvcc command line in the output. In fact, I think that bit you pasted with all the -gencode/etc. in it is your command line. Therefore, it is also proof that you are compiling the code for both sm_10 and sm_20, which is why you get the error when you call malloc.
You can confirm by wrapping the calls to malloc with #if __CUDA_ARCH__ >= 200 and see if the error goes away.
I'm guessing that you set the properties to compile for sm_20 in the default properties for .cu files in your project, but after you added the .cu file to the project. When the file was added to the project, the defaults were probably set to sm_10 and sm_20 (which is the default for the .rules file). If you right-click on the file itself you might see that sm_20 is checked. Just a hunch.