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\ .
Related
I am trying to Link R and C in windows while following the instructions on this web page
http://mcglinn.web.unc.edu/blog/linking-c-with-r-in-windows/
I have R, RTOOLS and TurboC4 all in separate folders in C drive. My system is 64bits but I have tried it on both 32 and 64 bit R.
I have written the following code in C
#include <R.h>
void hello(int *n)
{ int i;
for(i=0; i<=*n; i++){
Rprintf("hello, world!this is hell though I'm enjoying it\n");
}
}
and saved with name WORLD.C on separate file the path to which is
C:\TurboC4\TC\BIN
I have also written the following R code
hello2 <- function(n) {
.C("hello", as.integer(n))
}
hello2(5)
and save it with name WORLD.R.
Now I have to prepare my window. I have downloaded RTools33.exe from here https://cran.r-project.org/bin/windows/Rtools/
and set the environment variables manually through this command
PATH=c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\Program Files\R\R-3.2.2\bin\i386;
Then Reinstalled system
Before calling the C code in R I have to compile the C code in cmd. I write the following command to change the directory where WORLD.C is saved
cd C:\Users\TurboC4\TC\BIN
which is successful but when I try to compile
C:\Users\TurboC4\TC\BIN> R CMD SHLIB WORLD.c
I get the following error. " 'R' is not recognized as internal or external command, operable ". I have also tried to compile WORLD.C in C and got these two errors. "Unable to open #include R.h>" and "function Rprintf should have a prototype".
Setting Environment is a Problem
I think this is where I am facing problem. I have checked that Rtools33.exe is compatible with R 3.2.x and later. But I am getting the same error on CMD. I have tried different paths environments and have tried it with Different R versions like R- 3.2.2, R- 3.2.0, 2.15.3, 2.15.0. But when I write
"install.packages("RTools33") in any of these R version, I got the following warning message
Warning in install.packages :package ‘RTools33’ is not available (for R version
2.15.0)"
The reason for using different Rs is when you download RTOOLS folder there is a version file which says "Rtools Collection 3.3.0.1959". So I think maybe it a compatibility issue.
There are some instructions on Github page
https://github.com/stan-dev/rstan/wiki/Install-Rtools-for-Windows
"For installing Rtools, attention needs to be paid in a step where we can edit the system PATH so that the C++ compiler that is included in Rtools can be used by R. As indicated by the following step, we need to check this option (not manually edit the system PATH. Once the option is checked, system PATH would be edited to include important folders of Rtools by the installation process)."
So, I have uninstalled RTools and while reinstalling I have checked this option button as well and then retried but all in vein.
I have checked Sys.getenv('PATH') and got
c:\\\\\\\\Rtools\\\\\\\\gcc-4.6.3\\\\\\\\bin;c:\\\\\\\\RTools\\\\\\\\bin;
I have also tried by setting this path in
control pannel-> useraccountandfamilysafety->Useraccounts->change my
environment variable
and then creating new variable with above PATH.
I am still not able to direct R to C++ compiler. Can anybody please figure out what is my mistake?
This problem is now solved. There was just a minor mistake of defining the environment variable. The correct definition is as follows.
c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\Program Files\R\R-3.2.2\bin\i386;
I'm trying to get a simple command line application to run in the NaCl Development Environment. But I don't understand why it doesn't want to open files:
#include <stdio.h>
#include <ppapi_simple/ps_main.h>
int my_main (int argc, char ** argv) {
FILE * f = fopen ("out.txt","w");
if (f) {
fputs ("output to the file", f);
fclose(f);
} else {
puts("could not open file");
}
}
PPAPI_SIMPLE_REGISTER_MAIN(my_main)
Running:
bash.nmf-4.3$ gcc -I"$NACL_SDK_ROOT/include" test.c -lppapi_simple -lnacl_io -lppapi
bash.nmf-4.3$ ./a.out
could not open file
bash.nmf-4.3$
It's clearly possible for an application to open files in arbitrary locations within the dev environment - I'm using nano to edit the test code! But the naclports version of nano doesn't look like it's been changed in ways that are immediately connected to file manipulation..?
Lua is another app that appears to have only been modified very slightly. It falls somewhere in between, in that it can run test files but only if they're placed in /mnt/html5, and won't load them from the home folder. My test program shows no difference in behaviour if I change it to look in /mnt/html5 though.
NB. my goal here is to build a terminal application I can use within the dev environment alongside Lua and nano and so on, not a browser-based app - I assume that makes some difference to the file handling rules.
Programs run in the NaCl Dev Environment currently need to linked with -lcli_main (which in turn depends on -lnacl_spawn) for an entry point which understands how to communicate with the javascript "kernel" in naclprocess.js. They need this to know what current working directory they were run from, as well as to heard about mounted file systems.
Programs linked against just ppapi_simple can be run, but will not setup all the mount points the dev environment may expect.
There is a linker script in the dev env that simplifies linking a command line program -lmingn. For example the test program from the question can be compiled with:
gcc test.c -o test -lmingn
NOTE: This linker script had a recently resolved issue, a new version with the fix was published to the store on 5/5/2015.
In the near future, we have plans to simplify things further, by allowing main to be the entry point.
Thanks for pointing out the lua port lacks the new entry point!
I've filed an issue and will look into fixing it soon:
https://code.google.com/p/naclports/issues/detail?id=215
I found a solution to this, although I don't fully understand what it's doing. It turns out that the small changes made to nano are important, because they cause some other functions elsewhere in the NaCl libraries to get pulled in that correctly set up the environment for file handling.
If the above file is changed to:
#include <stdio.h>
int nacl_main (int argc, char ** argv) {
FILE * f = fopen ("out.txt","w");
if (f) {
fputs ("output to the file", f);
fclose(f);
} else {
puts("could not open file");
}
}
...and compiled with two more libraries:
gcc -I"$NACL_SDK_ROOT/include" test.c -lppapi_simple -lnacl_io -lppapi -lcli_main -lnacl_spawn
...then it will work as expected and write the file.
Instead of registering our own not-main function with PPAPI_SIMPLE_REGISTER_MAIN, pulling in cli_main causes it to do so with an internal function that sets some things up, presumably including what is needed for file writing to work, and expects to then be able to call nacl_main, which is left to the program to define with external visibility (several layers of fake-main stacking going on). This is why the changes to nano look so minimal.
nacl_spawn needs to be linked because cli_main uses it for ...something.
I am trying to debug my application which use one static builded library.
I want to set break points in my library so i tried to set it using below command :
break TS.cpp:600(FIle name:line no)
but it says
No source file named TS.cpp.
Make breakpoint pending on future shared library load?(y or [n])
so I presses y here (I came to know after browsing internet) but after pressing y gdb is not stopping at my break point and it completed executing program.
Why GDB is not stopped at my break point??
Any input is highly appreciated.
No source file named TS.cpp
This means one of two things:
either the file TS.cpp was not compiled with -g (or equivalently TS.o has been stripped), or
the file TS.o was not linked into the application.
Since you are seeing prints from that source, it's a safe bet that #1 is the actual root cause.
info sources command shows only my application.c and not the files of my library
That is another confirmation that #1 is the root cause.
The problem in your case is with source mapping. It normally happens when application is compiled at some other machine and you are debugging it on some other machine where source location is different.
You can specify source path using directory command of gdb. e.g. if your sources are in /home/taimoor/testApp/src, you can do following:
(gdb) directory /home/taimoor/testApp/src
I have a problem with compiling and running C codes in notepad++.
I am using the nppexec plugin and wrote the following in the script section after pressing F6:
C:\MinGW\bin\gcc.exe -g "$(FULL_CURRENT_PATH)" -o "$(CURRENT_DIRECTORY)\$(NAME_PART).exe"
$(CURRENT_DIRECTORY)\$(NAME_PART).exe
After pressing OK, I get the following on the console:
C:\MinGW\bin\gcc.exe -g "D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.C" -o "D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.exe"
Process started >>>
<<< Process finished. (Exit code 0)
D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.exe
Process started >>>
Here, substitution.c is my program to be run. The problem is that the gcc part is working fine but I am not able to execute the program from here as there is no response.
As you see, it just says process started and after that nothing. No response to a key being pressed, it just accepts everything like a text editor.
If I go to the working directory and execute the program from there (double clicking the exe file) then it seems to run perfectly fine. The problem seems to be in my script or the plugin.
Please, can anyone find out what is wrong with my compiling and running script?
In addition to #paxdiablo 's answer, you may also find useful the following NppExec script for single file projects:
npp_save
cd "$(CURRENT_DIRECTORY)"
cmd /c del "$(NAME_PART)".o "$(NAME_PART)".exe *.o
C:\MinGW\bin\gcc.exe -g3 -std=c89 -pedantic -Wall -Wextra -Wno-nonnull "$(NAME_PART)".c -o "$(NAME_PART)".exe
npp_run "$(NAME_PART)".exe
The 1st line saves the document that is currently active inside notepad++.
The 2nd line ensures your current directory is the one of the active document. This let you refraining from using the "$(CURRENT_DIRECTORY)" variable in the rest of the lines.
The 3rd line removes any executables and object-file leftovers from previous successful compilations. Removing the last executable is a nice idea, because if you don't then the last line will cause your .exe produced by the last compilation to be run anyway, even if your current compilation fails. A failed compilation does not produce an .exe, so normally you don't want NppExec to run the previous .exe. Removing the previously produced object-file is optional, but it does ensure that it will not affect fresh compilations (it makes more sense in multi-file projects, as an alternative to the touch command-line tool).
The 4th line compiles the active document. Feel free to modify gcc's options according to your needs. If you add C:\MinGW\bin into the Windows PATH environment variable, and assuming you are using only one gcc installation on your system, then you can skip the absolute path, and write just gcc instead.
The last line executes the produced executable. The npp_run command tells NppExec to launch a new command-prompt window, and run your program in it (unless it is a WIN32 GUI program). I personally find it more convenient compared to the NppExec console embed in notepad++. It looks more natural and it also avoids some I/O redirection problems of the NppExec console.
However, if your program is a console app that does not interact with the user say via a loop, then this approach will cause the launched command-prompt window to close immediately after your program terminates, not giving you the chance to inspect its output. In that case you should have you program waiting for a key to be pressed by the user just before its termination. A quick-and-dirty way is to put a system("pause"); right before your main() function's return and/or exit() statements (it is much better though to write a simple cross-platform function or macro for this).
You may experiment with the above script by typing it in F6's <temporary script> and save it permanently for general use when you are happy with its behavior.
On a side note, you may also find it useful to have a look at this post, where I'm trying to explain how to setup NppExec so it jumps to the appropriate line in the source code, by double-clicking on any error gcc spits in the NppExec console during compilation.
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.