I'm trying to get the ADC running on beaglebone black. The OS is Debian GNU/Linux 7.7. I'm using C language. When I try to compile the following code:
#include <stdio.h>
#include <unistd.h>
#include "pruio_c_wrapper.h"
#include "pruio_pins.h"
int main(int argc, const char *argv[]) {
PruIo *io = pruio_new(0, 0x98, 0, 1);
if (io->Errr) {
printf("Initialisation failed (%s)\n", io->Errr);
return 1;
}
if(pruio_config(io, 0, 0x1FE, 0, 4, 0)){
printf("Config failed (%s)\n", io->Errr);
return 1;
}
int a = 0;
int i;
while(1){
printf("\r%12o %12o %12o %12o %4X %4X %4X %4X %4X %4X %4X %4X\n", io->Gpio[0].Stat, io->Gpio[1].Stat, io->Gpio[2].Stat, io->Gpio[3].Stat, io->Value[1], io->Value[2], io->Value[3], io->Value[4], io->Value[5], io->Value[6], io->Value[7], io->Value[8]);
fflush(STDIN_FILENO);
usleep(1000);
}
pruio_destroy(io);
return 0;
}
But I get the following error:
undefined reference to 'pruio_new'
undefined reference to 'pruio_config'
I installed everything like FreeBasic compiler and pruss driver kit for freebasic and BBB and libpruio. I also copied all the header files in the same directory as the .c file, including "pruio_c_wrapper.h", "pruio-pins.h", "pruio.h" and all the other files in the src directory of libpruio. But it doesn't work.
Could you please tell me what to do?
Thanks
libfb is the FreeBASIC run-time library. When you want to compile against the old libpruio-0.0.x versions, you'll need an old FreeBASIC installation from
www{dot}freebasic-portal.de/dlfiles/452/bbb_fbc-0.0.2.tar.xz
Which installs /usr/local/lib/freebasic/libfb.so.
See the libpruio-0.0.x C example codes for compiler command line arguments (ie. header section of io_input.c).
But I recommend to use the new version libpruio-0.2 from (the last post links to the documentation of this new version)
http://www.freebasic-portal.de/dlfiles/592/libpruio-0.2.tar.bz2
which doesn't have this pitfalls, gcc compiles without FB installation, and provides new features like pinmuxing, PWM, CAP. There're small bugs in this versions C header, which is now named pruio.h: a missing enum and a copy / paste bug regarding a function name. See this thread for details:
http://www.freebasic.net/forum/viewtopic.php?f=14&t=22501
BR
Ok, I downloaded it, the binaries are in libpruio-0.0.2/libpruio/src/c_wrapper and so are the include files, copy the headers and libpruio.so to the same directory where the test.c file resides, and then
For the includes, you need to to append libpruio's include directory to the compiler command using -I. then you can do
#include <pruio_c_wrapper.h>
#include <pruio_pins.h>
You need to append the library to the linker command, with
-L. -lpruio
your complete compilation command will be then
gcc -o test -I. -L. -lpruio test.c
Related
Trying to use CreateSolidBrush to change a window background color.
I've included wingdi.h, I believe I've linked gdi32.lib ( however I converted gdi32.lib to a gdi32.a by using LIB2A, and I wonder if this may be an issue? ).
I wouldn't mind using another function but I worry this could be come a re-occuring issue if I'm not able to find a solution.
Some relevant code:
#include <stdio.h>
#include <windows.h>
#include <wingdi.h>
#include <main.h>
DWORD CreateMainWindow(void)
{
.............
WNDCLASSEXA WindowClass = { 0 };
WindowClass.hbrBackground = CreateSolidBrush(RGB(200, 200, 200));
.............
}
I use a function to easily compile
int Compile()
{
................
int result = 0;
char *include = "C:\\Users\\Coding\\C\\src\\include";
char *link = "C:\\Users\\Coding\\C\\src\\lib";
char command[256];
if(snprintf(
command,
sizeof(command),
"gcc -o main -I%s -l gdi32 -L%s main.c", include, link) >= sizeof(command))
{
//exception catching and handling
}
else
{
system(command);
}
return result;
}
I have no reason to believe the file isn't being linked as I'm not receiving an error.
Also I'm only using Notepad++, mingw64, and command prompt.
The error is a linker error, because it can't find the shared library symbol CreateSolidBrush.
All that is needed is linker flag -lgdi32, so it links with MinGW's libgdi32.a.
Don't try to generate this file by converting it from some other file you found which is probably built with a totally different compiler. If you already experimented with that make sure to clean up any lingering gdi32 .a or .lib files from your previous attempts.
Well the answer was extremely simple, linkages and includes must come after the file.
C:\User> gcc main.c -lgdi32 -I<include path> -o main
If this was obvious then I apologize, hopefully this helps another confused individual
When I run the following command in the command terminal: gcc practice.c temp.txt
I get the following error:
/usr/local/binutils/2.21/bin/ld:temp.txt: file format not recognized; treating as linker script
/usr/local/binutils/2.21/bin/ld:temp.txt:1: syntax error
collect2: ld returned 1 exit status
Here is my C code:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define MAX_LEN 1024
int main(int argc, char **argv) {
FILE *file;
char line[MAX_LEN];
float value = 0;
file = fopen(argv[1], "r");
while (fgets(line, MAX_LEN, file) != NULL) {
sscanf(line, "%f", &value);
printf("%f\n", value);
}
fclose(file);
return 0;
}
Basically I am trying to read numbers in a file and just print them out. Very simple.
For example, temp.txt will just be something like:
10
26
27
52
242
(these numbers should be in a column)
and so forth.
You may need some explanation about what gcc really is, gcc is used to translate your code into a runnable program, it's a sort of translator for code to executable instruction for your computer.
You do not need to compile the text file, you first need to compile your program :
gcc practise.c -o your_binary_name
then launch it with your file in parameter :
./your_binary_name temp.txt
use gcc to compile the executable, and then run the executable on the input file afterwards. You get an error b/c gcc is trying to compile your test.txt as C source code.
So:
gcc practice.c -o practice
./practice test.txt
C is a compiled not an interpreted language. GCC does not run the code as say Python or other scripting languages can for example. GCC rather translates the C source code to native machine code that when linked to the target runtime to create an executable is then separately and directly loaded and executed by the operating system without support from GCC at all.
I am working on this tutorial on building your own LISP (http://www.buildyourownlisp.com/chapter4_interactive_prompt) and for some reason when I try to compile I get this:
REPL.c:4:10: fatal error: 'editline/readline.h' file not found
#include <editline/history.h>
^
1 error generated.
I have installed the macOS developer tools, and brew is showing readline is installed and it doesn't know what to do when I try brew install editline.
This is my code:
1 #include <stdio.h>
2 #include <stdlib.h>
3 #include <editline/readline.h>
4 #include <editline/history.h>
5
6 int main(int argc, char** argv) {
7
8 /* version/exit info */
9 puts("Edward Version 0.0.1");
10 puts("Press Ctrl+c to Exit\n");
11
12 /* endless loop for main REPL */
13 while (1) {
14 /* output prompt and read line */
15 char* input = readline("lispy> ");
16
17 /* put input in history */
18 add_history(input);
19
20 /* Echo input back */
21 printf("No you're a %s\n", input);
22
23 /* free input */
24 free(input);
25 }
26 return 0;
27 }
It is obviously very basic, but I really want to get this project rolling so I'm hoping I can figure this out. This is what I'm using to compile:
cc -std=c99 -Wall REPL.c -ledit -o REPL
Include only
#include <editline/readline.h>
which should exist if the command line tools are installed. This file contains the
"readline wrapper" for libedit, including the history functions as well.
An include file <editline/history.h> does not exist on OS X.
I tested your code with that modification, and it compiled and ran without problems.
Using OSX Yosemite. I removed #include<editline/history.h>
and then used cc -std=c99 -Wall test.c -ledit -o test
Works fine now
I'm on El Capitan,
Remove #include <editline/history.h>,
and use cc -std=c99 -Wall test.c -ledit -o test works for me.
Add the flag -ledit before the output flad, it's a linking process, allows the compiler to directly embed calls to editline in your program. Or, you'll get the below error message,
Undefined symbols for architecture x86_64:
"_add_history", referenced from:
_main in prompt-086f90.o
"_readline", referenced from:
_main in prompt-086f90.o
ld: symbol(s) not found for architecture x86_64
I'm on Ubuntu 14.04.
try this:
sudo apt-get install libeditline-dev
and include like this:
#include <editline.h>
finally compile like this:
add -leditline in the flag
I hope this can help.
I'm on OSX Mavericks and removing the line worked for me:
#include <editline/history.h>
The solution for those following along on FreeBSD (might work on other Unices as well):
#include <stdio.h>
#include <stdlib.h>
#include <readline/readline.h>
#include <readline/history.h>
...
And run:
$ cc test.c -Wall -std=c99 -lreadline -o test
Without "-lreadline" in the compile step it is not linked in and you will get errors about undefined reference to "readline" function.
I started in on Build your own list and ran into the same problem.
None of the above answers worked for me. After a little research I found out that macOs doesn't have the gnu readline library that provides the readline functions, Different versions of MacOs provide emulation of readline using a library called editline. to begin...
man editline
#include <histedit.h>
Ok, editline gives you some structs for line input and history,
and functions to operate on them. First you have to instantiate these structs. The documentation for editline is not very helpful because it doesn't contain any examples. Apple makes the header file available so that helps a little. http://www.opensource.apple.com/source/libedit/libedit-13/src/histedit.h
I am new to this and it was still pretty confusing to me. there is some version of the source code to libedit available as a debian package. Fortunately someone wiser than I has already dug into it and implemented a command line using lbedit. His code is here: https://www.cs.utah.edu/~bigler/code/libedit.html.
I took Mr Bigler's code, and the code from Build your own list, and put them together to get this.
/* repl-macos.c
* Repl code example from builyourownlisp.com
* Modified by NB aug 2017
* Code example for editline from
* www.cs.utah.edu/~bigler/code/libedit.html
*/
#include <stdio.h>
#include <string.h>
#include <histedit.h>
char* prompt(EditLine *e){
return "lispy> ";
}
int main(int argc, char** argv){
EditLine *el; // Line editor state
History *herstory; // the rest is history
// Temp Variables
int count;
const char *usrin;
int keepreading = 1;
HistEvent ev;
// Initialize the editline state
el = el_init(argv[0], stdin, stdout, stderr);
el_set(el, EL_PROMPT, &prompt);
el_set(el, EL_EDITOR, "emacs");
// Initialize history
herstory = history_init();
if(!herstory){
fprintf(stderr, "Couldn't initialize history\n");
return 1;
}
//set history size
history(herstory, &ev, H_SETSIZE, 800);
// Set up the call back functions for history functionality
el_set(el, EL_HIST, history, herstory);
puts("Begin moLisp interpreter");
puts("Type 'exit' at prompt to exit");
while(keepreading){
usrin = el_gets(el, &count);
// add the command to the history, and echo it back to the user
if(count > 0){
history(herstory, &ev, H_ENTER, usrin);
if(strcmp(usrin, "exit\n"))
printf("No, You're a %s", usrin);
else{
puts("bye");
--keepreading;
}
}
}
// Clean up memory
// by freeing the memory pointed to within the structs that
// libedit has created.
history_end(herstory);
el_end(el);
return 0;
}
Notice: The instantiation of the structs that are used happens outside of
the while loop, and so do the functions that free the memory those structs are using. Because of this, I added the command to exit, otherwise I think there's a memory leak if the only way to exit the while loop is by interrupting the program. To compile:
gcc repl-macos.c -ledit -Wall -o repl-edit
-ledit is needed to link editline
If it has any relevance, I am using macOs 10.4.11
and here's my compiler, output of
gcc --version
powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer, Inc. build 4061)
Now the only problem with this, and the book points this out, is that
c-code is supposed to be portable and this isn't. The next step would be to add preprocessor directives so that it uses readline on linux and editline on macos.
If you are on ubuntu add the editline library
sudo apt-get install libtedit-dev
On Debian Buster 10, I had to install the package with:
sudo apt install libeditline-dev
Instead of:
#include <editline/readline.h>
#include <editline/history.h>
I just included:
#include <editline.h>
ran the program with -leditline flag and worked perfectly.
I have a bunch of C files and header files in the folder. When I compile the C files with MinGW compiler, it shows that there is no such file or directory. But I have all the files in the same folder. How do I get them to compile?
I have attached the code for your reference (file computil.c):
#include <stdio.h>
#include <computil.h>
#include <dataio.h>
int getc_skip_marker_segment(const unsigned short marker, unsigned char **cbufptr, unsigned char *ebufptr)
{
int ret;
unsigned short length;
ret = getc_ushort(&length, cbufptr, ebufptr);
if(ret)return(ret);
length -= 2;
if(((*cbufptr)+length) >= ebufptr)
{
fprintf(stderr, "ERROR : getc_skip_marker_segment : ");
fprintf(stderr, "unexpected end of buffer when parsing ");
fprintf(stderr, "marker %d segment of length %d\n", marker, length);
return(-2); }(*cbufptr) += length; return(0);
}
}
I am compiling it with gcc -c computil.c.
I believe you are going to have to add the current directory to the list of "standard places" that gcc uses. When you use instead of "computil.h", a Unix-style compiler won't look in the current directory.
For a quick fix to that, add -I. to the gcc command line. (dash, capital eye, period):
gcc -I. computil.c
If that's an application include file intended to be found where the source files are found, then you should change the include line to:
#include "computil.h"
That's one of the valuable nuances from Classic C that got lost in the ANSI standardization process. Standard C lets the compiler decide if there's a difference or between <> bracketed and "" quoted headers. It makes a difference in Unix and GNU ("GNU's Not Unix!"), well, pretty much is Unix only better in places.
To put it simple, #include <header.h> means "search in the compiler's own library directories, while #include "header.h means "search in the same directory as the .c file that made the #include".
I don't believe gcc has any library headers named computil.h and dataio.h, so the code won't compile.
I need to create an application to extract one file from zip archive, after which I want to compile it for Android.
I'm using Ubuntu, with libzip-0.10.1 pre-installed.
I created C project in Eclipse, added include path and found simple script for extracting file. Unfortunately I cannot get the following to build and I could use some advice.
// zip.c file
#include <stdio.h>
#include <stdlib.h>
#include <zip.h>
int main(int argc, char **argv) {
struct zip *zip_file;
struct zip_file *file_in_zip;
int err;
int files_total;
int file_number;
int r;
char buffer[10000];
if (argc < 3) {
fprintf(stderr,"usage: %s <zipfile> <fileindex>\n",argv[0]);
return -1;
};
zip_file = zip_open(argv[1], 0, &err);
if (!zip_file) {
fprintf(stderr,"Error: can't open file %s\n",argv[1]);
return -1;
};
file_number = atoi(argv[2]);
files_total = zip_get_num_files(zip_file);
if (file_number > files_total) {
printf("Error: we have only %d files in ZIP\n",files_total);
return -1;
};
file_in_zip = zip_fopen_index(zip_file, file_number, 0);
if (file_in_zip) {
while ( (r = zip_fread(file_in_zip, buffer, sizeof(buffer))) > 0) {
printf("%s",buffer);
};
zip_fclose(file_in_zip);
} else {
fprintf(stderr,"Error: can't open file %d in zip\n",file_number);
};
zip_close(zip_file);
return 0;
};
Also I added few .h files to include directory in my project and few .c files to directory with zip.c file. After that all dependences was good, but I have an error:
‘struct zip’ has no member named ‘default_password’ in file zip_fopen_index.c
The file zip_fopen_index.c is:
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include "zipint.h"
ZIP_EXTERN struct zip_file *
zip_fopen_index(struct zip *za, zip_uint64_t fileno, int flags)
{
return zip_fopen_index_encrypted(za, fileno, flags, za->default_password); // error here
}
First of all allow me some comments:
Your program is not compiled and linked by Eclipse.
Compiling is done by the compiler (gcc using option -c):
make all
Building file: ../zip.c
Invoking: GCC C Compiler
gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"zip.d" -MT"zip.d" -o "zip.o" "../zip.c"
Finished building: ../zip.c
Linking is done by the linker (via the compiler using option -o):
Invoking: GCC C Linker
gcc -o "unzipper" ./zip.o
./main.o: In function `zip':
/home/alk/workspace/unzipper/Debug/../zip.c:20: undefined reference to `zip_open'
/home/alk/workspace/unzipper/Debug/../zip.c:27: undefined reference to `zip_get_num_files'
/home/alk/workspace/unzipper/Debug/../zip.c:33: undefined reference to `zip_fopen_index'
/home/alk/workspace/unzipper/Debug/../zip.c:35: undefined reference to `zip_fread'
/home/alk/workspace/unzipper/Debug/../zip.c:38: undefined reference to `zip_fclose'
/home/alk/workspace/unzipper/Debug/../zip.c:43: undefined reference to `zip_close'
collect2: ld returned 1 exit status
Eclipse provides a framework helping you in managing all sources and their references as also spawing compiler and linker tasks and setting their options.
When the linker told you there where undefined references to the zip_*function during the build of your program, the cause for this was, you were missing to tell the linker (via the compiler, via Eclipse) where those zip_* functions could be found.
Those zip_* functions are located in a library, namely libzip.
So what you as the programmer need to tell the linker (via the compiler, via Eclipse) is to link those functions against what the compiler compiled from your sources.
As the result the linker is able to create a runnable program from your compiled sources together with all libraries needed. Certain libraries are know to Eclipse (and therfore to the linker) by default, for example the one containing the C standard functions, namely libc.
To get things going:
1 Remove the source files you pulled from the libzip librarie's sources from your project. Those sources had been compiled into the library libzip, which you will use in your project.
2 Tell the linker (via Eclipse) to use libzip for your project.
Do so by following the steps below:
open the project's properties
click 'C/C++ General'
click 'Path and Symbols', on the left select the 'Libraries' tab, there click 'Add' and enter zip
finally click 'OK'
3 Then try to build your program:
Building target: unzipper
Invoking: GCC C Linker
gcc -o "unzipper" ./zip.o -lzip
Finished building target: unzipper
(Please note additional option -lzip!)
If the developement version of 'libzip' had been installed properly before, you should be fine.
PS: unzipper was the name I used for the Eclispe project to produce the examples.
PSS: I used Eclipse Juno SR1