In the process of trying to build some software AVL I'm getting some X11 library issues. I've done this install a few years ago and remember it being straight forward, but it was on an older version of OS el capitan I think and I'm on a "lite" version of Big Sur. I installed XQuartz and I can see the files it's expecting, but it seems to have trouble with the path to X11 per my understanding of this error
In file included from xwin11/Xwin2.c:74:
/usr/X11/include/X11/Xlib.h:44:10: fatal error: 'X11/X.h' file not found
In order for it to find Xlib.h I modified this (which I'm pretty sure isn't correct)
from
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/cursorfont.h>
to
#include </usr/X11/include/X11/Xlib.h>
#include </usr/X11/include/X11/Xutil.h>
#include </usr/X11/include/X11/cursorfont.h>
Before it would die on finding Xlib.h. It also seems to be ignoring the linking line I gave it in the config.make file
LINKLIB = -I/usr/X11/include -L/usr/X11/lib -lX11
Is there an environment variable or path I'm missing in my profile? Is it ignoring the linking flag. Or did I set this up incorrectly in the config file? What's really odd is that now it's finding Xlib.h but it can't find X.h and they live in the same folder, which really makes me think it just doesn't know where to find the X11 "stuff" .
Thanks!
Here's how to solve it:
determine from the compiler messages what include files the compiler cannot find
find them yourself
tell the compiler where they are
repeat above steps for libraries it cannot link
So, it cannot find Xlib.h. Let's find that:
find / -name Xlib.h 2>/dev/null
and, on my machine, I find:
/opt/X11/include/X11/Xlib.h
So that means I need to tell the compiler where to look for header files like this:
g++ -I /opt/X11/include ...
Then, when it encounters this in your code:
#include <X11/Xlib.h>
that means it will actually be expecting to find:
/opt/X11/include/X11/Xlib.h
Now, let's do the libraries:
find / -name libX11.dylib 2> /dev/null
and, on my machine, I find:
/opt/X11/lib/libX11.dylib
so that means I need:
g++ -I /opt/X11/include -L /opt/X11/lib/ ...
Thanks #MadScientist your comment was the key. I moved the
-I/usr/X11/include
out of the linking flag and into the compile flag and that solved it!
Related
I am new to MacOS, I've always written code on Linux. I was used to compiling C files with gcc, simply like
gcc -o file file.c -lm -lgsl
where here I assumed the code to contain among its includes
#include <math.h>
#include <gsl/gsl_rng.h>
Of course the library gsl is correctly installed on my Mac via homebrew, and so are pkg-config and "Command line tools", but still when I try to compile file.c I get an error message,
fatal error: 'gsl/gsl_rng.h' file not found
#include <gsl/gsl_rng.h>
^~~~~~~~~~~~~~~
The problem is not specific to gsl (I tried for instance with the library fftw3 and got the same result).
I've seen tons of people with the same kind of problems on new M1 Macs; I've read that gcc on Mac is really "clang", and different rules apply. A ton of mocking answers were suggesting to add the correct library paths to the makefile or the like. But actually I've never before felt the need for a makefile on Linux, and surely I don't want to start adding cflags and paths whenever I compile a code (I'm working on several machines with different operating systems, with my code stored on Cloud servers, so I assume I should write a makefile for each of them? Really?).
Has anyone found a proper fix?
I have a 64 bit Cygwin on my 64 bit Win7.
I installed gcc-core and gcc-g++ packages.
I made a simple C program:
#include <stdio.h>
int main() {
exit(0);
}
when I compile with: gcc-c test.c I got:
fatal error: stdio.h: No such file or directory
Doing it with -v flag I see:
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include-fixed
/usr/include
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib/../include/w32api
End of search list.
GNU C (GCC) version 4.8.3 (x86_64-pc-cygwin)
The stdio.h which comes with gcc-core package is present on my pc at this location (which is fine according to Cygwin's package searcher also):
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include/ssp/stdio.h
What it means that ssp directory and why stdio.h is placed there ?
Why gcc cannot find stdio.h present at this location ?
The file you found in the ssp directory is not a version of <stdio.h>. It only contains extra information about some of the functions in <stdio.h> for the stack-smash protector feature in gcc.
The actual <stdio.h> should be in /usr/include.
This line in your -v output is very interesting:
/usr/inlude
How did you get a /usr/inlude with no c?
Oops, the missing c in inlude was deleted in the edit by Keith Thompson.
So your gcc should be finding /usr/include/stdio.h if you have it. Is it there? As far as I can tell from the package file lists, it's supposed to be part of the cygwin base system (i.e. even if you haven't installed the compiler it should be there).
Are you missing any other header files? <stdlib.h> and <string.h> are good test candidates.
Here are some commands to investigate the cygwin package and whether it contains the file:
cygcheck -f /usr/include/stdio.h
cygcheck -c cygwin
cygcheck -l cygwin | grep stdio
UPDATE: so it seems I'm behind the times and there's a cygwin-devel package now. The header files aren't in the base cygwin package any more. To check the correct package on the latest cygwin, you'd use
cygcheck -c cygwin-devel
as has already been done in the comments. And since it's listed as "incomplete" the solution is probably to reinstall it using cygwin's setup program.
I installed some encryption software called libntru.
The header files are installed in /usr/include/libntru and the file I would like to include from this directory is ntru.h. The compiled library is installed to /usr/lib/libntru.so.
In my makefile, I use gcc's -L and -l flags to link to the library as such -L/usr/lib -lntru, however in my project, I get a compiler error at the line #include <ntru.h>.
How can I link to this library? Thanks in advance for any help.
Check on the instructions with the software; there's at least a chance you're supposed to write one of:
#include <libntru/ntru.h>
#include "libntru/ntru.h"
If that's the case, you won't need to specify anything on the command line to find the headers (no -I option). If you're supposed to write just:
#include <ntru.h>
#include "ntru.h"
Then you need to add -I/usr/include/libntru to the command line.
Note that you probably don't need -L/usr/lib on the command line; the compiler will normally look there anyway, but you will need the -lntru option to specify the library itself, of course.
I am trying to install hqp on OS X, but seems the gcc compiler is quite different.
When running make, I first come to an error like malloc.h not found, I wrap the #include header like:
#if !defined(__APPLE__)
#include <malloc.h>
#endif
In this way, the first problem is solved.
But when I continue to run make, I got things like:
g++ -shared -o libhqp.so Hqp_Init.o Hqp.o sprcm.o Meschach.o spBKP.o matBKP.o bdBKP.o Hqp_impl.o Hqp_Program.o Hqp_Solver.o Hqp_Client.o Hqp_IpsFranke.o Hqp_IpsMehrotra.o Hqp_IpMatrix.o Hqp_IpSpBKP.o Hqp_IpRedSpBKP.o Hqp_IpLQDOCP.o t_mesch.o Hqp_IpSpSC.o meschext_hl.o Hqp_SqpSolver.o Hqp_SqpPowell.o Hqp_SqpSchittkowski.o Hqp_HL.o Hqp_HL_Gerschgorin.o Hqp_HL_DScale.o Hqp_HL_BFGS.o Hqp_HL_SparseBFGS.o Hqp_SqpProgram.o Hqp_Docp.o hqp_solve.o \
../meschach/*.o ../iftcl/*.o -L"/sw/lib" -Wl,-rpath,"/sw/lib" -ltclstub8.5
i686-apple-darwin11-llvm-g++-4.2: ../meschach/*.o: No such file or directory
i686-apple-darwin11-llvm-g++-4.2: ../iftcl/*.o: No such file or directory
Does anyone know what component is different this time? I tried reinstall the latest version of tcl, but it seems not to be the problem. Find it really hard to google a solution...
Without actually testing the result, I got this to work using the following steps. I have to say that this set of makefiles does not work as it should, especially with regard to how the dependencies are set up.
First, edit meschach/machine.h and remove the #include <malloc.h>, or make it conditional like you did with the __APPLE__ ifdef. The only reason why malloc.h is included seems to be for malloc() and free() and those get included via stdlib.h anyway.
Then edit makedirs.in and append -I/usr/include/malloc to MES_INCDIR, leaving you with MES_INCDIR = -I.. -I/usr/include/malloc.
With these two steps in place, doing ./configure followed by make should already give you libhqp.so in the lib directory, which might be sufficient for you.
However, there is also an executable called docp in the directory hqp_docp which gets executed during the make process. It does not work because it can not find the shared libary libhqp.so. I resolved that by cd-ing into the lib directory and setting export DYLD_FALLBACK_LIBRARY_PATH=$PWD. I am not sure whether running docp is an essential part of the process though.
Finally, the building of a library called omu breaks because the linker is not passed any reference to the required library libhqp.so. I did not figure out why this would work on other systems, and I do not know whether you need that libomu at all. I just did a quick fix by adding -L../lib -lhqp to the end of the linker-command in omu/Makefile. That is the command starting with $(LD).
I hope I did not forget any of the steps I took, let me know if it still breaks for you somewhere.
On an almost default install of Ubuntu 11.04 I installed clang.
I am trying to compile this:
#include <cstdlib>
int main(){
return 0;
}
g++ can deal with it just fine, but clang++ errors out: fatal error: 'cstdlib' file not found
Can someone explain why this happens? and what needs to be done to make this work?
I expected clang++ to be a drop-on replacement for g++.
Seems like your clang build is not searching the correct platform include paths. Try checking with
clang -v ...
where it is looking for headers (and check that your platform include paths are there). You might have to add additional include directories (e.g. /usr/include/c++/x.y).
You might want to take a look at the source file lib/Frontend/InitHeaderSearch.cpp, The method AddDefaultCPlusPlusIncludePaths does some distribution/gcc-version specific magic (I had to fix it for my own system once).