I am trying to build a certain library under cygwin (OpenEXR), and I get the following error:
b44ExpLogTable.cpp:52:18: error: half.h: No such file or directory
half.h is referenced using #include <half.h>, and is actually a part of another library I successfully run make/make install on previously.
The question is -- when using #include with <>, where the preprocessor expects to find the specified file?
(I have just found it in /usr/local/include/OpenEXR, but I have no idea why preprocessor cannot).
Update: I have also found:
Makefile
ILMBASE_CXXFLAGS = -I/usr/local/include/OpenEXR
Makefile.am
INCLUDES = #ILMBASE_CXXFLAGS# \
-I$(top_builddir) \
-I$(top_srcdir)/config
This actually decreased my understanding of what the problem may be.
Update 2: So, by redefining some variables in makefile I found out that instead of $(CXXCOMPILE) make seems to run $(CXX) $(CXXFLAGS), with CXXFLAGS being just -g -O2. Ok, I have no idea how it manages to run $(CXX) $(CXXFLAGS) if this combination in not used anywhere in the makefile except in $(CXXCOMPILE) which is not run. I can add my -I to CXXFLAGS but I have a feeling that a lot more additions will be required, so I would prefer to find a root cause of the problem.
(I am not sure whether it is a Super User or Stack Overflow question, because my developer skills in C++/Linux are almost non-existent.)
Additional include directories are usually specified in CPPFLAGS. Try running ./configure CPPFLAGS=-I/usr/local/include/OpenEXR and re-running make.
You need to somehow get -I/usr/local/include/OpenEXR added to the compiler command line. That might be a simple matter of doing:
CFLAGS=-I/usr/local/include/OpenEXR make
Related
I am having some trouble to compile GCC. When I try to compile it, this error appears:
Makefile:26: *** missing separator. Stop.
The line 26 refers to the first line of this condition:
#if gcc
ifeq (,$(.VARIABLES)) # The variable .VARIABLES, new with 3.80, is never empty.
$(error GNU make version 3.80 or newer is required.)
endif
#endif gcc
I already tried to insert a TAB between the keywords but it didn't work. The only thing I tried and seems to work is to change the condition to:
ifeq ($(gcc),)
ifeq (,$(.VARIABLES)) # The variable .VARIABLES, new with 3.80, is never empty.
$(error GNU make version 3.80 or newer is required.)
endif
endif
Informations:
Make log: http://pastebin.com/t5eNYJd5
Make log (after changing the condition): http://pastebin.com/HHjQKdDx
My make version is: 4.0.
GCC version I am trying to build: 5.2.0
I am using fedora 22.
I've got a workaround. The problem is that the Makefile contains hundreds of '#if', therefore, I would like to know why is it using '#if' if they do not work ?
Thanks in advance.
I stumbled upon this same problem. This question is a little old and it looks like you found a workaround, but I'll document my findings here as well for the People of the Future.
Background
GCC currently requires you to perform an out-of-source build. Based on the commands shown, some of the documentation and online QA implies that this is valid:
svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc;
gcc/configure <configure options>;
make -j 8 && make install;
This nests the source directory in the build directory, but I would expect that to count as "out-of-source." Running without -j 8 still produced the problem. I did this on a RHEL6 system, using GNU make 4.2. I was attempting to build GCC 8.0.0.
Solution
I found that making the source and build directories adjacent rather than creating builddir/sourcedir resolved the problem.
Additional info
Here's are relevant snippets from the GCC build instructions:
We use srcdir to refer to the toplevel source directory for GCC; we use objdir to refer to the toplevel build/object directory.
...
If you obtained the sources via SVN, srcdir must refer to the top gcc directory, the one where the MAINTAINERS file can be found, and not its gcc subdirectory, otherwise the build will fail.
...
First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn’t get extensive testing; building where objdir is a subdirectory of srcdir is unsupported.
Depending on your definition of "source tree", these instructions may or may not proscribe building the way I first attempted. They should probably be updated to clarify this case.
As to the specific reason that Makefile won't run, that snippet is not valid make syntax - if is not a make keyword, and referenced variables must be enclosed like so: $(varname). # simply prevents the command from being echoed.
Rather, this is supposed to be multiline interpolated bash. This StackOverflow answer shows this being done in a Makefile, but it's done as part of a recipe. I see no evidence that this is valid as a standalone entity.
In the correctly-generated Makefile, the section you posted is absent, and all interpolated bash appears in a recipe.
I am trying to install a secondary glibc on my machine. As its "INSTALL" file says, the following steps must suffice:
mkdir glibc-build
cd glibc-build
../glibc-2.19/configure --prefix=/path/to/glibc-build
make
make install
I actually do not have any problem with the simple installation, however, I do not know how I should add my desired CFLAGS to the whole process. I have tried "make CFLAGS=-da" instead of simple "make", however, it returns me errors. I have tried with other options too. Errors appear again.
Another way was to modify the "config.make" inside the glibc-build. It did not work neither. So, I would appreciate it if you could share your experience in this regard.
P.S.: My desired options are: -da -dv -S
In case you wanna compile glibc with your desired CFLAGS, you need to include -Ox to the set of flags you are passing as the CFLAGS environment variable.
We have a project and shared libraries libprivate.so (private so) which was using old libraries libcurl.so.3. The system was upgraded with new system libraries libcurl.so.4.
For some internal issues, right now we do not want to make use of latest libraries libcurl.so.4, we want to make use of libcurl.so.3.
Hence I copied libcurl.so.3 in local folder and set LD_LIBRARY_PATH according. When I link my entire project it says that there is version conflict between libcurl.so.4 and libcurl.so.3 required libprivate.so (libprivate.so is compiled long time ago with libcurl.3.so).
Should I not worry about this warning and proceed further?
When I correctly specify LD_LIBRARY_PATH which has libcurl.so.3, why it is taking from system directory /usr/lib64/libcurl.so.4? when I do ldd my_binary, it takes from libcurl.so.4. How do I stop it? Specifying -L with specific location also doesn't work. Modiying /etc/ld.conf will do for the entire system. I want to make this when I ran my project.
Specifying explicit path it works like /home/mydir/libcurl.so.3, but I do not want to do it.
I want to have these conditions only when I execute my project. In other cases it can make use of latest libraries.
Thanks for your help
If the command you show in your comment is correct:
gcc test.c -L~/lib/x86_64/ -lcurl -o test
... then you need a space between -L and ~/lib/x86_64/ or the shell won't expand the ~, so the linker is not looking in the right directory.
So you need either:
gcc test.c -L ~/lib/x86_64/ -lcurl -o test
or:
gcc test.c -L$HOME/lib/x86_64/ -lcurl -o test
(You don't need a space here because variables are expanded anywhere in a word, but ~ is only expanded at the start of a word.)
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.
I am trying to build a pass using llvm and I have finished building llvm and its associated components. However, when I run make after following all the steps to build a pass including the makefile, I get the following
relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
After tyring to find a fix by googling the error message, I came to know that this is not specific to llvm. A few solutions suggested that I should use "--enable-shared" while running configure but that didn't help my case. Now I want to re-build llvm using fPIC, as the error says. But how do I do this using the makefile?
Looks like you could add the -fPIC (for position-independent code, something you want for a shared library that could be loaded at any address) by setting shell variables:
export CFLAGS="$CFLAGS -fPIC"
export CXXFLAGS="$CXXFLAGS -fPIC"
Looking at Makefile.rules, these will be picked up and used. Seems strange that it wasn't there to begin with.
EDIT:
Actually, reading more in the makefiles, I found this link to the LLVM Makefile Guide. From Makefile.rules, setting either SHARED_LIBRARY=1 or LOADABLE_MODULE=1 (which implies SHARED_LIBRARY) in Makefile will put -fPIC in the compiler flags.
If you are moderately convinced that you should use '-fPIC' everywhere (or '-m32' or '-m64', which I need more frequently), then you can use the 'trick':
CC="gcc -fPIC" ./configure ...
This assumes a Bourne/Korn/POSIX/Bash shell and sets the environment variable CC to 'gcc -fPIC' before running the configure script. This (usually) ensures that all compilations are done with the specified flags. For setting the correct 'bittiness' of the compilation, this sometimes works better than the various other mechanisms you find - it is hard for a compilation to wriggle around it except by completely ignoring the fact you specified the C compiler to use.
Another option is to pass -fPIC directly to make in the following way:
make CFLAGS='-fPIC' CXXFLAGS='-fPIC'