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.
Related
I'm a student doing research involving extending the TM capabilities of gcc. My goal is to make changes to gcc source, build gcc from the modified source, and, use the new executable the same way I'd use my distro's vanilla gcc.
I built and installed gcc in a different location (not /usr/bin/gcc), specifically because the modified gcc will be unstable, and because our project goal is to compare transactional programs compiled with the two different versions.
Our changes to gcc source impact both /gcc and /libitm. This means we are making a change to libitm.so, one of the shared libraries that get built.
My expectation:
when compiling myprogram.cpp with /usr/bin/g++, the version of libitm.so that will get linked should be the one that came with my distro;
when compiling it with ~/project/install-dir/bin/g++, the version of libitm.so that will get linked should be the one that just got built when I built my modified gcc.
But in reality it seems both native gcc and mine are using the same libitm, /usr/lib/x86_64-linux-gnu/libitm.so.1.
I only have a rough grasp of gcc internals as they apply to our project, but this is my understanding:
Our changes tell one compiler pass to conditionally insert our own "function builtin" instead of one it would normally use, and this is / becomes a "symbol" which needs to link to libitm.
When I use the new gcc to compile my program, that pass detects those conditions and successfully inserts the symbol, but then at runtime my program gives a "relocation error" indicating the symbol is not defined in the file it is searching in: ./test: relocation error: ./test: symbol _ITM_S1RU4, version LIBITM_1.0 not defined in file libitm.so.1 with link time reference
readelf shows me that /usr/lib/x86_64-linux-gnu/libitm.so.1 does not contain our new symbols while ~/project/install-dir/lib64/libitm.so.1 does; if I re-run my program after simply copying the latter libitm over the former (backing it up first, of course), it does not produce the relocation error anymore. But naturally this is not a permanent solution.
So I want the gcc I built to use the shared libs that were built along with it when linking. And I don't want to have to tell it where they are every time - my feeling is that it should know where to look for them since I deliberately built it somewhere else to behave differently.
This sounds like the kind of problem any amateur gcc developer would have when trying to make a dev environment and still be able to use both versions of gcc, but I had difficulty finding similar questions. I am thinking this is a matter of lacking certain config options when I configure gcc before building it. What is the right configuration to do this?
My small understanding of the instructions for building and installing gcc led me to do the following:
cd ~/project/
mkdir objdir
cd objdir
../source-dir/configure --enable-languages=c,c++ --prefix=/home/myusername/project/install-dir
make -j2
make install
I only have those config options because they seemed like the ones closest related to "only building the parts I need" and "not overwriting native gcc", but I could be wrong. After the initial config step I just re-run make -j2 and make install every time I change the code. All these steps do complete without errors, and they produce the ~/project/install-dir/bin/ folder, containing the gcc and g++ which behave as described.
I use ~/project/install-dir/bin/g++ -fgnu-tm -o myprogram myprogram.cpp to compile a transactional program, possibly with other options for programs with threads.
(I am using Xubuntu 16.04.3 (64 bit), within VirtualBox on Windows. The installed /usr/bin/gcc is version 5.4.0. Our source at ~/project/source-dir/ is a modified version of 5.3.0.)
You’re running into build- versus run-time linking differences. When you build with -fgnu-tm, the compiler knows where the library it needs is found, and it tells the linker where to find it; you can see this by adding -v to your g++ command. However when you run the resulting program, the dynamic linker doesn’t know it should look somewhere special for the ITM library, so it uses the default library in /usr/lib/x86_64-linux-gnu.
Things get even more confusing with ITM on Ubuntu because the library is installed system-wide, but the link script is installed in a GCC-private directory. This doesn’t happen with the default GCC build, so your own GCC build doesn’t do this, and you’ll see libitm.so in ~/project/install-dir/lib64.
To fix this at run-time, you need to tell the dynamic linker where to find the right library. You can do this either by setting LD_LIBRARY_PATH (to /home/.../project/install-dir/lib64), or by storing the path in the binary using -Wl,-rpath=/home/.../project/install-dir/lib64 when you build it.
I want to use frama-c for static C code analysis. It already took me some effort to install it (hopefully) properly. The files are located at C:\CodeAnalysis\frama-c. I want to apply it via Windows console, e.g.:
C:\CodeAnalysis\frama-c\bin\frama-c hello.c
hello.c is just a simple hello-world-program (I am no C programmer btw and a newbie in programming)
#include <stdio.h>
main()
{
printf("Hello World \n");
}
So when running the above command there is the following output:
[kernel] preprocessing with "gcc -C -E -I. hello.c"
C:/Strawberry/c/x86_64-w64-mingw32/include/stdio.h:141:[kernel] user error: syntax error
[kernel] user error: skipping file "hello.c" that has errors.
[kernel] Frama-C aborted: invalid user input
Yes, I have Perl installed but have no idea why Frama uses it. To me it seems that there is somehow something wrong with the stdio.h. Can this be? But I can compile my program successfully.
C:\Strawberry\c\bin\gcc hello.c produces a nicely working exe file.
When removing the include statement from the file, there is the following output:
[kernel] preprocessing with "gcc -C -E I. hello.c"
hello.c:5:[kernel] warning: Calling undeclared function printf. Old style K&R code?
So frama itself does work and this is the kind of output I expected to have.
I also have MinGW installed and tried to make Frama use this for compiling. So I removed the Strawberry entries in my Windows Path. After that calling frama-c produces the same output.
When completely uninstalling Strawberry Perl, frama doesn't work (stating gcc is an unknown command), although C:\MinGW\mingw64\bin is also added to my Windows Path, even as very first entry.
C:\MinGW\mingw64\bin\gcc hello.c works, gcc hello.c doesn't.
When Perl is installed gcc hello.c works, even when I delete the Strawberry parts from the Windows Path variable. Wtf?
How can I make things work properly?
There are several issues here, and we have to isolate them in order to fix things.
Strawberry Perl installs its own gcc (based on MinGW), binutils, C headers, etc., by default on directory C:\Strawberry\c\bin. It adds this directory (among others) to the Windows Path variable. Frama-C expects gcc to be in the path, and it is Windows who decides which gcc to choose, if there are several directories in the path which contain a gcc binary. This is why Frama-C seems to use it.
One common mistake (not Windows-specific, but which happens more often in Windows due to the nature of its graphical applications) is to modify environment variables and forget to restart the processes which still have old copies of them (such as Command Prompt). echo %path% should confirm which directories are present in the path for the current command prompt, if there are any doubts about its value.
In case echo %path% contains the expected value, this is what might have happened (unfortunately I cannot reproduce your configuration to test it thoroughly): during installation of Frama-C, it may use the settings present during installation time to choose which directory contains gcc (in your case, C:\Strawberry\c\bin) and later hardcode this directory in its scripts.
This could explain why, after uninstalling Strawberry Perl, even if another gcc was in the path, it was not considered by Frama-C. Ideally, reinstalling Frama-C with a single gcc in the path could allow it to find the right version this time. Note that this is just a hypothesis, I may be completely wrong here.
In any case, the major problem you're having is not with gcc itself, but with the headers included with Strawberry Perl, as explained in the next item.
Concerning the error message:
C:/Strawberry/c/x86_64-w64-mingw32/include/stdio.h:141:[kernel] user error: syntax error
[kernel] user error: skipping file "hello.c" that has errors.
It is indeed not extremely informative and might change in future versions, but it does point to the source line which causes the error (file stdio.h, line 141):
int __cdecl __mingw_vsscanf (const char * __restrict__ _Str,
const char * __restrict__ Format,va_list argp);
In particular, it seems that __restrict__ is the source of the error here (Frama-C Sodium accepts restrict and __restrict, but not __restrict__; this may change in future versions).
Unfortunately, even fixing this (by adding e.g. #define __restrict__ restrict before #include <stdio.h> in your file) does not guarantee that the rest of the file will be parsed, since it seems to be a Windows-specific, C++-prone header that likely contains other C definitions/extensions that are not in the C99 standard, and possibly not accepted by Frama-C.
The best solution would be to ensure Frama-C uses its own stdio.h header, instead of Strawberry Perl's. It is usually installed in share/frama-c/libc (that is, it could be in C:\CodeAnalysis\frama-c\share\frama-c\libc in your installation), but depending on your configuration the headers might not have been found during execution, and Strawberry Perl's headers were included instead.
A quick hack for this specific case might be replacing:
#include <stdio.h>
with:
#include "C:\CodeAnalysis\frama-c\share\frama-c\libc\stdio.h"
But it is far from ideal and likely to lead to other errors.
If you manage to find out how to prevent Strawberry Perl's headers from being included, and ensure Frama-C's header files are included instead, you should be able to run Frama-C.
Note about Cygwin/MinGW path issues
I've had some issues when using a MinGW compiler and a Cygwin build (which is not necessarily a good idea), so here are some quick instructions on how to build Frama-C Sodium with a MinGW-based OCaml compiler using a Cygwin shell (but not a Cygwin-based OCaml compiler), in case it might help someone:
When running ./configure, you'll need to specify a --prefix using a Windows-based path instead of a Cygwin-based one, such as:
./configure --prefix="C:/CodeAnalysis/build"
If you don't, when running Frama-C (after make/make install) it will fail to find the libc/__fc_builtin_for_normalization.i file because it will try to use the Cygwin-based path, which will not work with the MinGW-based OCaml compiler.
Note that you cannot use backslashes (\) when specifying the prefix path, since they will not be correctly converted later.
I had to use the following command to ensure the makefile worked correctly:
make FRAMAC_TOP_SRCDIR="$(cygpath -a -m $PWD)"
Again, this is due to Cygwin paths not being recognized by the MinGW compiler (in particular, the absolute paths used by the plug-ins).
The previous steps are sufficient to compile and run Frama-C (plus the GUI, if you have lablgtk and other dependencies installed). However, there are still some issues, e.g. absolute Windows filenames are not always handled correctly. This can often be avoided by specifying the file names directly in the command line with relative paths (e.g. frama-c-gui -val hello.c), but in the general case, MinGW+Cygwin is not a very robust combination and other issues may arise.
Overall, mixing Cygwin and MinGW is not a good idea due to path issues, but it is nevertheless possible to compile and run Frama-C in such conditions.
I'm trying to compile the gtk stack (the last gtk2 version, 2.24), and I am getting a bunch of errors that seem related. Namely, the __locale_t can't be found from string.h and time.h, and LC_ALL_MASK can't be found either (should be in locale.h).
I found that all of these problems are related to __USE_XOPEN2K8 not being #defined. What is __USE_XOPEN2K8 for, and how can I set it propertly?
For example, do I have to pass a flag to ./configure for glib, gtk, ... or do I have to change something already while building gcc or glibc̲? I'd rather not just sprinkle #define __USE_XOPEN2K8 in to my sources without knowing what it does. Note I'm using gcc-4.6.3 and glibc-2.16.0 which are installed in a nonstandard prefix, as I'm trying to get the gtk libraries to work on an older CentOS (5.8) that only includes older versions.
Also note the missing __locale_t is mentioned in several places, e.g. this bugreport. I could just add #include <xlocale.h> in some files, but it seems the proper solution would be to get __USE_XOPEN2K8 to be set.
Edit: I've found this thread describing the problem. Apparently, headers of the host system get "fixincluded" into the headers of the new compiler. The linked post suggests to edit features.h. Does anyone know if I have to recompile gcc / glibc afterwards (and how to get it to pick up the new features.h, rather than overwriting it)?
When __USE_GNU is defined, __USE_XOPEN2K8 is always defined as well, unless you
are explicitly defining or undefining these macros, which you must not do.
Use _GNU_SOURCE, _XOPEN_SOURCE {500,600,700,...} etc. macros before including
the first header instead. This is the recommended way to select the GNU feature set in glibc headers, together with defining it on the command line (-D_GNU_SOURCE).
Alternatively, you can try specifying GNU extension usage to gcc through the -std command line switch (gnu89, gnu99, and so forth).
On CentOS7 with gcc 4.6 we had to use -D_XOPEN_SOURCE=700 -D__USE_XOPEN2K8
The glibc __USE_* macros are internal macros used to implement feature selection. The supported way to set them is to define feature test macros such as -D_GNU_SOURCE:
Feature Test Macros
These macros are needed because glibc supports many standards and GNU extensions, and these features are in conflict with each other, mostly due to the lack of namespaces in C. For example, C and POSIX allow you to define a global variable called secure_getenv (because the identifier is not reserved or otherwise used by those standards), but such a program will not work if you compile with _GNUS_SOURCE and include <stdlib.h> because glibc provides a function called secure_getenv.
<xlocale.h> is an internal glibc header (a comment within the header file says so) and will no longer be available in glibc 2.26.
As I know when we use the complier, it's behavior depends on some ENV macros, which saved in feature.h. So you can configure your complier by modifyinfg it.
Fisrt,you need use g++ -E youfile > log, to see which feature.h file your complier use, and then use g++ -E -dM /path/to/feature.h>log, to find the __USE_XOPEN2K8, if you can't find it. Add #define __USE_XOPEN2K8 1 at the end of the file.You know may be you have do some configure wrong when you install you complier.
I'm on freebsd and trying to run uhd from: http://www.ettus.com/download This should normally run under freebsd, but I encounter problems when I try to build it like specified here:
http://www.ettus.com/uhd_docs/manual/html/build.html#build-instructions-unix
I get:
[ 73%] Building CXX object examples/CMakeFiles/benchmark_rx_rate.dir/benchmark_rx_rate.cpp.o
Linking CXX executable benchmark_rx_rate
../lib/libuhd.so.003.000: undefined reference to `uhd::set_thread_priority(float, bool)'
collect2: ld returned 1 exit status
*** Error code 1
Now this seems to be a linker error, but how to get rid of it? I tried setting the path using ldconfig but this hasn't changed a thing. Maybe some of you have an idea where I could continue searching.
If i get it right, libuhd get's built earlier by this CMake script. If it's true, this error indicates bug in their CMakeLists.txt files.
It looks like you are building examples of using libuhd. I doubt you are need them. So, either look for switches in your CMakeCache.txt and regenerate Makefiles or hack CMakeLists.txt to not include examples dir.
Another thing you may try - set CMAKE_EXE_LINKER_FLAGS to -L/usr/local/include.
This is a perfect situation for creating a FreeBSD port. Since FreeBSD has its own consistent filesystem layout, compiler and linker flags often need to be modified (as noted by arrowdodger) slightly.
The ports system is a framework for persistently capturing those configuration changes and making any software package as easy to install as typing the commands:
cd /usr/ports/category/application-name && make install clean
In a perfect world, you would create the UHD port, submit it for review and addition to the tree. If you need help learning how to do that, the FreeBSD Porter's Handbook and the freebsd-ports mailing list are excellent resources.
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