I am making an application where I think I will need to use termios.h But I have windows 10. I installed cygwin64. I type in gcc test.c -o test.exe in the terminal. I still get fatal error: termios.h: No such file or directory #include <termios.h> Is there something I had to do during installation?
The code is just prints hello world but I included termios.h
#include <stdio.h>
#include <termios.h>
int main(){
printf("Hello World!");
return 0;
}
Install the missing development package. To find which is, use cygcheck
$ cygcheck -p usr/include/termios.h
Found 12 matches for usr/include/termios.h
cygwin-devel-3.0.7-1 - cygwin-devel: Core development files
...
cygwin-devel-3.2.0-0.1 - cygwin-devel: Core development files
cygwin-devel-3.2.0-1 - cygwin-devel: Core development files
...
You need cygwin-devel
$ cygcheck -l cygwin-devel |grep termios.h
/usr/include/termios.h
/usr/include/machine/termios.h
/usr/include/sys/termios.h
looking at your example
$ cat prova.c
#include <stdio.h>
#include <termios.h>
int main(){
printf("Hello World!");
return 0;
}
and at the compiler
$ which gcc
/usr/bin/gcc
$ gcc --version
gcc (GCC) 10.2.0
the example builds fine
$ gcc -Wall prova.c -o prova
$ ./prova
Hello World!
Instead of this:
#include <termios.h>
This:
#include <sys/termios.h>
Related
I am trying to compile the following components:
appl - an application which links to a dynamic shared library (libwrapper.so)
libwrapper.so - A library used by appl. This library invokes functions from a libbackend archive.
libbackend.a - A static archive that uses libc functions.
I want to ensure that the libc functions invoked by libbackend always uses a fixed libc implementation. So I am also archiving the needed libc.a in libbackend, in my compilation environment.
I want to achieve that when libbackend invokes any libc function, the archived libc function from the compilation environment should be invoked, not the function from libc.so version in the target environment.
Can this be achieved? Also, can this be achieved without changing the way appl is being compiled; i.e., can be this achieved by changing makefile of only libwrapper and libbackend?
This is what I have tried so far, and does not work:
[dev-env]# ls
appl.c backend.c backend.h Makefile wrapper.c wrapper.h
[dev-env]# cat appl.c
#include <stdio.h>
#include "wrapper.h"
void main()
{
printf("in appl\n");
wrapper();
}
[dev-env]# cat wrapper.h
void wrapper();
[dev-env]# cat wrapper.c
#include <stdio.h>
#include "wrapper.h"
#include "backend.h"
void wrapper()
{
printf("In wrapper\n");
backend();
}
[dev-env]# cat backend.h
void backend();
[dev-env]# cat backend.c
#include <stdio.h>
#include <gnu/libc-version.h>
#include "backend.h"
void backend()
{
printf("in backend\n");
printf("GNU libc version: %s\n", gnu_get_libc_version());
}
[dev-env]# cat Makefile
LIBC=$(shell gcc --print-file-name=libc.a)
all: libbackend.a libwrapper.so appl
libbackend.a: backend.c backend.h
gcc -static -fPIC -c backend.c -o backend.o
ar rcs libbackend.a $(LIBC) backend.o
libwrapper.so: wrapper.c wrapper.h libbackend.a
gcc -c wrapper.c
gcc -shared -o libwrapper.so wrapper.o libbackend.a
appl: appl.c
gcc -o appl appl.c -L . -lwrapper
clean:
rm *.o *.a *.so appl
[dev-env]#
From compilation environment:
[dev-env]# make
gcc -static -fPIC -c backend.c -o backend.o
ar rcs libbackend.a /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libc.a backend.o
gcc -c wrapper.c
gcc -shared -o libwrapper.so wrapper.o libbackend.a
gcc -o appl appl.c -L . -lwrapper
[dev-env]# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
[dev-env]# ./appl
in appl
In wrapper
in backend
GNU libc version: 2.28
In target environment:
[target]# ./appl
in appl
In wrapper
in backend
GNU libc version: 2.30
If what I am intending works, on target I should have seen the version output as "2.28".
Can this be achieved?
No.
This will lead to totally unpredictable behavior on any system with a different version of libc.so.6 installed. It's not something that you should even attempt.
I want to ensure that the libc functions invoked by libbackend always uses a fixed libc implementation.
Why? What problem are you imagining this will solve?
It would not solve anything, but is guaranteed to introduce new problems.
I am trying to build program with multiple files for the first time.
I have never had any problem with compliling program with main.cpp only.
With following commands, this is the result:
$ g++ -c src/CNumber.cpp src/CNumber.h -o src/CNumber.o
$ g++ -c src/CExprPart.cpp src/CExprPart.h -o src/CExprPart.o
$ g++ -c src/CExpr.cpp src/CExpr.h -o src/CExpr.o
$ g++ -c src/main.cpp -o src/main.o
$ g++ src/CNumber.o src/CExprPart.o src/CExpr.o src/main.o -o execprogram
src/CNumber.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
What could cause such error and what should I do with it?
Using Linux Mint with gcc (Ubuntu/Linaro 4.7.2-2ubuntu1).
Thank you
This is wrong:
g++ -c src/CNumber.cpp src/CNumber.h -o src/CNumber.o
You shouldn't "compile" .h files. Doing so will create precompiled header files, which are not used to create an executable.
The above should simply be
g++ -c src/CNumber.cpp -o src/CNumber.o
Similar for compiling the other .cpp files
I ran into this error in building something - it turned out to be due to a previous build failing while compiling a source file to an .o file - that .o file was incomplete or corrupted, so when I tried another build it gave this error on that file.
The solution was to just delete the .o file (or run make clean, if you have a makefile with that target).
Try putting all of the following files in one directory:
example.cpp:
#include<iostream>
#include<string>
#include "my_functions.h"
using namespace std;
int main()
{
cout << getGreeting() << "\n";
return 0;
}
my_functions.cpp:
#include<string>
using namespace std;
string getGreeting()
{
return "Hello world";
}
my_functions.h:
#ifndef _MY_FUNCTIONS_H
#define _MY_FUNCTIONS_H
#include<string>
using namespace std;
string getGreeting();
#endif
Then issue these commands:
$ g++ example.cpp my_functions.cpp -o myprogram
~/c++_programs$ ./myprogram
Hello world
It seems for me that mingw wersion of gcc ignores CFLAGS environment variable. Am i right? How it could be fixed?
I've done following:
create simple test.c file
int main(int argc, char** argv) {
int a;
return 0;
}
and run form mingw bash prompt
$ export CFLAGS="-Wall"
$ gcc test.c <-- no warnings
$ gcc test.c -Wall
$ ... warning: unused variable 'a'
CFLAGS it's not an environment variable required or used by the gcc suite, you can find more about gcc and environment variables here.
Yeah, sorry, it seems makefile option
Here is my sample flex file,
%{
/* need this for the call to getlogin() below */
#include <unistd.h>
%}
%%
username printf("%s\n", getlogin());
%%
main()
{
yylex();
}
I ran the following command,
$ flex sample.fl
I could see the lex.yy.c file now.
I ran the following gcc command
$ gcc lex.yy.c -lfl
and got the following error,
/usr/bin/ld: cannot find -lfl
collect2: ld returned 1 exit status
I already have flex installed in my computer.
Installing the flex-static.i686 package in my fedora box solved the issue.
I have a working setup, where all files are in the same directory (Desktop). The Terminal output is like so:
$ gcc -c mymath.c
$ ar r mymath.a mymath.o
ar: creating archive mymath.a
$ ranlib mymath.a
$ gcc test.c mymath.a -o test
$ ./test
Hello World!
3.14
1.77
10.20
The files:
mymath.c:
float mysqrt(float n) {
return 10.2;
}
test.c:
#include <math.h>
#include <stdio.h>
#include "mymath.h"
main() {
printf("Hello World!\n");
float x = sqrt(M_PI);
printf("%3.2f\n", M_PI);
printf("%3.2f\n", sqrt(M_PI));
printf("%3.2f\n", mysqrt(M_PI));
return 0;
}
Now, I move the archive mymath.a into a subdirectory /temp. I haven't been able to get the linking to work:
$ gcc test.c mymath.a -o test -l/Users/telliott_admin/Desktop/temp/mymath.a
i686-apple-darwin10-gcc-4.2.1: mymath.a: No such file or directory
$ gcc test.c -o test -I/Users/telliott_admin/Desktop/temp -lmymath
ld: library not found for -lmymath
collect2: ld returned 1 exit status
What am I missing? What resources would you recommend?
Update: Thanks for your help. All answers were basically correct. I blogged about it here.
$ gcc test.c /Users/telliott_admin/Desktop/temp/mymath.a -o test
edit: gcc only needs the full path to the library for static libraries. You use -L to give a path where gcc should search in conjunction with -l.
To include the math libraries, use -lm, not -lmath. Also, you need to use -L with the subdirectory to include the library when linking (-I just includes the header for compiling).
You can compile and link with:
gcc test.c -o test -I/Users/telliott_admin/Desktop/temp /Users/telliott_admin/Desktop/temp/mymath.a
or with
gcc test.c -o test -I/Users/telliott_admin/Desktop/temp -L/Users/telliott_admin/Desktop/temp -lmymath
where mymath.a is renamed libmymath.a.
See link text for comments (search for "bad programming") on the practices of using -l:
In order for ld to find a library with -l, it must be named according to the pattern libyourname.a. Then you use -lmymath
So, there is no way to get it to take /temp/mymath.a with -l.
If you named it libmymath.a, then -L/temp -lmymath would find it.