My Computer Science teacher gave me a template for an assignment on manipulating arrays. This includes the <stdbool.h> and <float.h> libraries. Both of these seem to not be linking. When using the library I always have to link it by right clicking on the file in the file explorer of eclipse then going to properties> C/C++ Build> Settings> Libraries> and then clicking "add..." and typing "m". All of my type "bool" and symbols "true" and "false" form the <stdbool.h> library cannot be resolved and my symbol "FLT_EPSILON" which is a constant defined in the <float.h> library cannot be resolved. I don't know how to link these libraries or fix this. thank you
EDIT:
I have:
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
/* function sqrt() is defined in <math.h> */
#include <stdbool.h>
#include <float.h>
at the top of my program
At the top of the source file in which you want to use the bool type and FLT_EPSILON constant add these lines:
#include <stdbool.h>
#include <float.h>
and you should be ok. This works for my using Eclipse Kepler SR1, no need to add any external libraries.
Edit: These includes can fail to resolve if the compiler used with the selected toolchain doesn't support them. For instance they can't be resolved when using MS VC++ as current toolchain (presumably because that compiler isn't C99 compliant). If you are using MS VC++ try switching toolchain to MinGW GCC for instance.
Related
I have two source files that contain routines I want in my .dll.
I can build the .dll, but I have to do something like this:
#include <stdio.h>
#include "routines1.h"
#include "routines2.h"
#include "routines1.c"
#include "routines2.c"
This works, but it is very ugly and I am sure it must be wrong. I am more familiar with building libraries in Linux wherein adding files together is less problematic. I am working in C.
Update Turnes out my lecturer will accept code written to the GNU99 standard, so, as User1 pointed out, I used _GNU_SOURCE at the beginning of my program. (See man feature_test_macros for more info.) Thanks for helping me understand!
On Ubuntu 13.10 with Clang 3.4, GCC 4.8.1, I am doing an assignment which requires me to use the C99 standard. (I also have GNUstep installed from SVN)
WRT GCC, I think I have 4 versions installed in these folders:
/usr/lib/gcc/x86_64-linux-gnu/4.7
/usr/lib/gcc/x86_64-linux-gnu/4.7.3
/usr/lib/gcc/x86_64-linux-gnu/4.8
/usr/lib/gcc/x86_64-linux-gnu/4.8.1
gcc --version reports 4.8.1, clang --version reports 3.4. ld -v reports 2.23.52.20130913
I'm writing a signal handler and when I use siginfo_t in my function header, I get a compiler error: unknown type name 'siginfo_t' I'm using sigaction() to install the handler.
While studying what needs to be done and how, I was able to compile a simple demo which also uses the same function header definition, and it works. However it's not limited to C99.
These are my includes (of which signal.h is one):
#define _POSIX_C_SOURCE 2
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <math.h>
#include <ctype.h>
#include <libgen.h>
#include <signal.h>
This is my signal handler function (only for debugging purposes):
static void sigSIGCHLDhandler(int sigNum, siginfo_t *siginfo, void *context) {
printf("PID = %ld",(long) siginfo->si_pid);
}
I am compiling with clang using -Wall and -std=c99 now -std=gnu99options.
I have tried locate signal.h and I have it in /usr/include. I tried adding #include <bits/siginfo.h> and that allowed me to compile, but the binary wouldn't work correctly.
(I have a bunch of signal.h and siginfo.h files on my system.)
Another student suggested that there is something wrong with my set up. So I've reinstalled Clang. Here are some of my environment variables that I think might be relevant (please notify me of any missing or wrong)
LD_LIBRARY_PATH=/home/user/ros_catkin_ws/install_isolated/lib:/home/user/GNUstep/Library/Libraries:/usr/local/lib
CPATH=/home/user/ros_catkin_ws/install_isolated/include
PATH=/home/user/ros_catkin_ws/install_isolated/bin:/home/user/GNUstep/Tools:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/user/bin:/usr/local/java/jdk1.7.0_51/bin
CLASSPATH=/home/user/GNUstep/Library/Libraries/Java:/usr/local/lib/GNUstep/Libraries/Java
LIBRARY_COMBO=gnu-gnu-gnu
INFOPATH=/usr/local/share/info::/home/user/GNUstep/Library/Documentation/info:
GNUSTEP_IS_FLATTENED=yes
GNUSTEP_LOCAL_ROOT=/usr/local/Local
GNUSTEP_HOST=x86_64-unknown-linux-gnu
GUILE_LOAD_PATH=/home/user/GNUstep/Library/Libraries/Guile:/usr/local/lib/GNUstep/Libraries/Guile
GNUSTEP_MAKEFILES=/usr/local/share/GNUstep/Makefiles
GNUSTEP_NETWORK_ROOT=/usr/local/Network
GNUSTEP_FLATTENED=yes
GNUSTEP_HOST_OS=linux-gnu
GNUSTEP_HOST_VENDOR=unknown
GNUSTEP_HOST_CPU=x86_64
GNUSTEP_USER_ROOT=/home/user/GNUstep
GNUSTEP_SYSTEM_ROOT=/usr/local/System
GNUSTEP_PATHLIST=/usr/local/System:/usr/local/Network:/usr/local/Local:/home/user/GNUstep
GNUSTEP_SYSTEM_ROOT=/usr/local/System
GNUSTEP_PATHLIST=/usr/local/System:/usr/local/Network:/usr/local/Local:/home/nap/GNUstep
I've spent hours searching for a fix but can't find anything, and I'm out of ideas.
What is broken?
If you look the man page of sigaction(2), you will find the following:
siginfo_t: _POSIX_C_SOURCE >= 199309L
Try adding the compiler option: -D_POSIX_C_SOURCE=199309L
It tells the required posix version to your c-lib (glibc).
EDIT:
See more about those from POSIX wiki page.
featuers.h tells more about how glibc use the define:
_POSIX_C_SOURCE
If ==1, like _POSIX_SOURCE;
if >=2 add IEEE Std 1003.2;
if >=199309L, add IEEE Std 1003.1b-1993;
if >=199506L, add IEEE Std 1003.1c-1995;
if >=200112L, all of IEEE 1003.1-2004
Similar information also in man page: feature_test_macros(7).
So: _POSIX_C_SOURCE=2 does not bring latest POSIX features for available, because 1003.2 (posix 2) is not the latest one. For getting more features available you need to define later version.
Don't get confused: POSIX.2 is not newer than POSIX.1c.
i have a program and work on win95 old machine. I want to work on win xp and want to be executed this program on xp. Application use some hardware (two card which is plugged in isa slot). I have application soruce code but, codes not support on xp. For example, graphics.h, eg_proto.h,color.h, wg_var.h header files don't have anywhere on modern compiler. I have turbo c 1.0 compiler but not support me for this situation.
So, what can i do about this situation? Would you suggest anythings about?
Some header files from source code:
#include <ctype.h>
#include <color.h>
#include <stdlib.h>
#include <errno.h>
#include <alloc.h>
#include <time.h>
#include <dir.h>
#include <process.h>
#include <eg_proto.h>
#include <pchrt.h>
#include <stdio.h>
#include <stdlib.h>
#include <dos.h>
#include <math.h>
#include <string.h>
#include <dw.h>
#include <dwdata.h>
#include <wdh.h>
I dont know anything about some header file. for example, dw.h, dwdata.h, wdh.h. I didnt found any description about this header file.
Edit:
My compiler is Turbo C 2.01
http://i.stack.imgur.com/LQFnI.jpg
If you're using the same compiler on both systems, it is almost certain that the missing headers are not part of the compiler package. They are certainly not part of the OS since your compiler predates both operating systems.
I see two main possibilities:
These headers are part of your project and are not being found due an error in the build process.
These headers are part of some third-party libraries that you have installed in one environment and not the other.
Either way, you need to find them and either fix your build settings, or copy the headers across from the old system to the new one.
I was given the source code to modify an MS-DOS program built back in 1992. I have the EXE file and it runs fine, but I need to modify the source code. The source code needs the below headers to compile.
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
#include <dos.h>
#include <dir.h>
#include <alloc.h>
#include <ctype.h>
#include <string.h>
#include <mem.h>
#include <values.h>
Does anyone know what was used and are there any modern compilers that can handle this? I tried with Visual Studio 2010 and GCC "out of the box", but it fails because some headers are missing (dir.h, alloc.h, mem.h, values.h)
It might be more interesting to ask what what function declarations, type declarations, global variable declarations and macros it needs to have. The particular arrangement of those things into headers isn't very interesting as long as they are all there.
So comment out the offending #includes and let the compiler complain about the bits it is missing. Then you know what you're looking for.
You could try the Open Watcom compiler, which is one of the few relatively up-to-date compilers that builds 16-bit DOS executables. Other than finding an old MS or Borland compiler (or whatever was originally used), that's probably the easiest route.
If you want to rebuild for a different platform instead of rebuilding for DOS again, you'll likely have to make a lot of changes to the program itself. That may be worthwhile, but may be a lot of work and have a lot of surprise headaches.
There's Turbo C++ 1.01, not so modern, though, that appears to have all these header files as well. I still occasionally use it.
You might try using DJGPP. According to the documentation, it may have the headers you need.
a) Remove all the header files
b) Try a compile
c) Look up which header file the undefined function/type is int
d) Add the header file
e) repeat
Like I said in the title. I'm trying to compile libipsec right now and am having a world of difficulty (not using the C library it was intended to be compiled on). Many of my errors are caused from the line
#include PATH_IPSEC_H,but path_ipsec_h is never declared anywhere and It does not seem like a C keyword...
What does PATH_IPSEC_H actually mean? Would this line be equivalent to #include <ipsec.h>?
If I did not provide the correct information...sorry..I'm still new to this. Just tell me what you need to know.
Look for a file named config.h, it is very likely to define this symbol to the proper value for your environment. I took a quick look in a randomly-chosen ipsec file, and it starts:
#include "config.h"
#include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include PATH_IPSEC_H
This indicates either that PATH_IPSEC_H is defined by config.h, or passed in on the command line when compiling this file. The presence of the #include "config.h" line makes that (in my opinion, without any prior knowledge of this particular library) the most likely choice.
Update: also, it's very likely that this config.h file is created by some build-tool, i.e. it's probably not there unless you've run the proper tool to generate it, typically after analyzing your environment.