I'm trying to compile libpcap with cross compilator arm-linux-gcc. When I run 'make' I get an error:
./pcap-linux.c:254:14: conflicting types for socklen_t /usr/arm-linux-gnueabi/include/unistd.h:275:21: note previous declaration of 'socklen_t'
I've also tried to compile it using common gcc but i have the same error. I work on ubuntu. How to resolve this problem
pcap-linux.c makes an alias in next way:
#ifndef HAVE_SOCKLEN_T
typedef int socklen_t;
#endif
You should pass -DHAVE_SOCKLEN_T to compiler or put
#define HAVE_SOCKLEN_T
to some header (usually it is done automatically by configure script or similar, that generates config.h).
Seems like you skipped build configuration step, so be ready to see another weird build errors.
Related
I'm doing some compile works recently.
After updated openssl1.1.1f to openssl1.1.1h, I met some compile errors for packages using the openssl headers "bio.h" and "evp.h".
That's because openssl1.1.1h add something like this:
/*
* name is cast to lose const, but might be better to route through a
* function so we can do it safely
*/
#ifdef CONST_STRICT
/*
* If you are wondering why this isn't defined, its because CONST_STRICT is
* purely a compile-time kludge to allow const to be checked.
*/
int BIO_read_filename(BIO *b, const char *name);
# else
# define BIO_read_filename(b,name) (int)BIO_ctrl(b,BIO_C_SET_FILENAME, \
BIO_CLOSE|BIO_FP_READ,(char *)(name))
# endif
If the CONST_STRICT marco is defined, you have to implement the api yourself otherwise you will get an undefined reference error during linkage phase.
I wonder what compile option I have to add to make the CONST_STRICT marco NOT defined?
Thanks in advance!
I miss-understood what the comment in the openssl header file means, thanks to Guillaume Petitjean who corrected me.
The error I got is due to other cause. One of my packages has an older version of openssl in it, and it installed it's header files after it's being built. In that version the api BIO_read_filename was not implemented by marco definition but in a source file. I modified the makefile of the package to not install the older openssl header file and the error are gone.
I am attempting to build a project that comes with an automake/autoconf build system. This is a well-used project, so I'm skeptical about a problem with the configure scripts, makefiles, or code as I received them. It is likely some kind of environment, path, flag, etc problem - something on my end with simply running the right commands with the right parameters.
The configuration step seems to complete in a satisfactory way. When I run make, I'm shown a set of errors primarily of these types:
error: ‘TRUE’ undeclared here (not in a function)
error: ‘struct work’ has no member named ‘version’
error: expected ‘)’ before ‘PRIu64’
Let's focus on the last one, which I have spent time researching - and I suspect all the errors are related to missing definitions. Apparently the print-friendly extended definitions from the C standard library header file inttypes.h is not being found. However, in the configure step everything is claimed to be in order:
configure:4930: checking for inttypes.h
configure:4930: /usr/bin/x86_64-linux-gnu-gcc -c -g -O2 conftest.c >&5
configure:4930: $? = 0
configure:4930: result: yes
All the INTTYPES flags are set correctly if I look in confdefs.h, config.h, config.log Output Variables, etc:
HAVE_INTTYPES_H='1'
#define HAVE_INTTYPES_H 1
The problem is the same whether doing a native build, or cross-compiling (for arm-linux-gnueabihf, aka armhf).
The source .c file in question does have config.h included as you'd expect, which by my understanding via the m4 macros mechanic should be adding an
#include <inttypes.h>
line. Yes, as you may be inclined to ask, if I enter this line myself into the .c file it appears to work and the PRIu64 errors go away.
I'm left with wondering how to debug this type of problem - essentially, everything I am aware of tells me I've done the configure properly, but I'm left with a bogus make process. Aside from trying every ./configure tweak and trick I can find, I've started looking at the auto-generated Makefile.in itself, but nothing so far. Also looking into how I can get the C pre-processor to tell me which header files it's actually inserting.
EDIT: I've confirmed that the -DHAVE_CONFIG_H mechanic looks good through configure, config.log, Makefile, etc.
autoconf does not automatically produce #include directives. You need to do that on your own based on the HAVE_* macros. So you'll have to add something like this:
#ifdef HAVE_INTTYPES_H
# include <inttypes.h>
#endif
If these lines show up in confdefs.h, a temporary header file used by configure scripts, this does excuse your application from performing these #includes. If configure writes them to confdefs.h, this is solely for the benefit of other configure tests, and not for application use.
First, run make -n for the target that failed. This is probably some .o file; you may need some tweaking to get its path correctly.
Now you have the command used to compile your file. If you don't find the problem by meditating on this command, try to run it, adding the -E to force preprocessor output text instead of invoking the compiler.
Note that now the .o file will be text, and you must rebuild it without -E later.
You may find some preprocessor flags useful to get more details: -dM or -dD, or others.
I compile my project with -Werror to make sure all of my code is without recognizable warnings. However my current project has a third-party dependency that has an issue in it which causes a warning - and that warning fails my build because of the -Werror flag.
I want to use the -Werror flag and I don't want to correct the third-party package. Is there a way to ignore this warning?
package.h:126:1: error: useless storage class specifier in empty declaration [-Werror]
};
The line of code that generates the error is a struct definition with a "dangling" typedef.
typedef struct my_data_obj {
char* data;
uint32_t data_size;
};
This is obviously a mistake - but I can't find any pragma or any such mechanic to ignore the warning generated from that header file. Any ideas?
EDIT: SOLUTION
Though I'm accepting Florian Weimer's answer because it answers the question most closely it's not the actual fix I settled with. I'll describe that bellow. By including the headers as system headers I did exactly what I wanted to do - suppress the error without having to fix the package.
What I finally did was create a patch file and simply apply that patch each time the project is built.
vim package.h
# fix the file
git add package.h
git diff --cached > package.h.patch
# on build time
git apply package.h.patch
I assume that you want to include package.h from files where you want to enable -Werror.
GCC does not have a separate flag to control this warning, otherwise the compiler would have printed it. With the separate flag, you could have used #pragma GCC diagnostics ignore, as indicated in the other answers, possibly with a wrapper header file.
However, you could put the header file into a separate directory, and instead of using -I to add it to the include path, use -isystem. As a result, the header file is treated as a system header, and unless you also compile with -Wsystem-headers, warnings in system headers are suppressed.
All warnings and errors have specific names, and can be enabled or disabled on a per-warning/-error basis.
For example lets say I have an unused variable and enabled warnings about it, then I will get a message similar to
/some/path/main.cpp:18:9: warning: unused variable ‘i’ [-Wunused-variable]
That last part of the message, the one inside the square brackets, is the name of the specific warning.
With this name you can then disable warnings using the -Wno-<name of warning> option. In the case of the above warning it's disabled with -Wno-unused-variable.
Your use-case is a little different in that you want to disable a warning turned into an error. This is very similar to the above, but the general form of the option is -Wno-error=<name of warning or error>. In our example case it's -Wno-error=unused-variable.
All of this is of course in the GCC documentation, more specifically in the warning options documentation.
So what you have to do is figure out the name of the warning, so you can use it for the -Wno-error= option.
I have compiled program in minGW which I want to run in my computer which has Cygwin installed in my system. I have the following compilation error:
error: 'off64_t' undeclared (first use in this function)
I added the following to the CFLAGS in Makefile, but still having the same error.
-D"_LARGEFILE64_SOURCE" -D"_FILE_OFFSET_BITS=64"
Can someone suggest what am I missing here and what I need to add?
Cygwin does not define the off64_t type. Instead, if defines _off64_t. If you want to compile your existing code with minimal changes, add the following at the top of your sources:
#include <sys/types.h>
typedef _off64_t off64_t;
I'm using cygwin to compile a network tool(iffinder).
After ./configure and make i have a problem that i guess is related to struct icmp. Where is the icmp struct in header files. I searched for it in cygwin header files, but i didn't find anything.
How can i compile source codes which need icmp, in cygwin?
If it helps, you can find the source code of iffinder here
Note: I have ip_icmp.h in my cygwin's header files.
Compile error:
iffinder.c:1059: warning: "struct icmp" declared inside parameter list
iffinder.c:1059: warning: its scope is only this definition or
declaration, which is probably not what you want iffinder.c: In
function `handle_icmp_error': iffinder.c:1069: error: dereferencing
pointer to incomplete type
...
In cygwin, the icmp.h is empty. I suggest you copy a icmp.h from a open source project, and compile it with your project. Maybe, you have many errors and you have to correct them, but you just need an icmp struct and it will solve your problem.
iffinder.c line 54 does #include <netinet/ip_icmp.h> - is this header file present on your system?