I'm trying to use the original som implementation by Kohonen but I'm getting a segmentation fault error using vcal.
It turns out that you can use an unofficial version which corrects this error found at
http://cis.legacy.ics.tkk.fi/hynde/lvq/
but its from 1997, i'm sure that there are a lot of changes in cc compiler so I'm getting this error
checo#canija:~/bin/som/som_pak-3.2$ make
gcc -O2 -c -o vcal.o vcal.c
In file included from datafile.h:28,
from vcal.c:26:
fileio.h:69: error: conflicting types for ‘getline’
/usr/include/stdio.h:651: note: previous declaration of ‘getline’ was here
make: *** [vcal.o] Error 1
checo#canija:~/bin/som/som_pak-3.2$
The file datafile.h
1:#ifndef SOMPAK_DATAFILE_H
2:#define SOMPAK_DATAFILE_H
...
24:#include
25:#include
26:#include "lvq_pak.h"
27:#include "errors.h"
28:#include "fileio.h"
Is there anything I can do to recomple this code?
Converting a comment to an answer to allow the question to be resolved.
getline() is now a POSIX function; it wasn't in 1997. Your best bet may be to rename the function in fileio.h and where it is used, maybe as simply as adding before the appearance of getline and after the #include <stdio.h>.
#undef getline
#define getline(a, b, c) som_getline(a, b, c)
Use the right number of parameters, or
#define getline(...) som_getline(__VA_ARGS__)
If <stdio.h> is not yet included, then add it to ensure that getline() is declared normally, then mapped by your macro.
Related
I'm currently toying around with the C library NanoVG library. The library depends on OpenGL fucntions and has 2 header files nanovg.h and nanovg_gl.h. The latter file contains part of the implementation. For convenience, I have placed these two header files in /usr/include/nanovg.
When I try to compile the following code to an object file, gcc does not complain:
// working.c
#include <GL/gl.h>
#include <nanovg/nanovg.h>
#define NANOVG_GL3_IMPLEMENTATION
#include <nanovg/nanovg_gl.h>
(Command: gcc -c working.c -o working.o)
Now, I copy the header files from /usr/include/nanovg/ to the working directory, and replace the code with:
// notworking.c
#include <GL/gl.h>
#include "nanovg.h"
#define NANOVG_GL3_IMPLEMENTATION
#include "nanovg_gl.h"
(Command: gcc -c notworking.c -o notworking.o)
Gcc now complains that some OpenGL functions are not declared:
... (many more similar complaints)
src/nanovg_gl.h: In function ‘glnvg__renderDelete’:
src/nanovg_gl.h:1540:3: warning: implicit declaration of function ‘glDeleteBuffers’; did you mean ‘glSelectBuffer’? [-Wimplicit-function-declaration]
1540 | glDeleteBuffers(1, &gl->fragBuf);
| ^~~~~~~~~~~~~~~
...
Why does one file compile smoothly but not the other?
A bit deeper:
Using the cpp tool, I found that the difference between the two pre-processed files is limited to # directives but I don't see any difference as far as the "C content" goes. Below is a snippet of the pre-processed working.c. If I add the # lines from the pre-processed notworking.c, then gcc no longer compiles the pre-processed working.c and complains about a missing declaration for glDeleteBuffers.
// ...
if (gl ==
// # 1533 "src/nanovg_gl.h" 3 4 // <- uncomment this line and glDeleteBuffers is considered missing by gcc
((void *)0)
// # 1533 "src/nanovg_gl.h" // <- idem
) return;
glnvg__deleteShader(&gl->shader);
if (gl->fragBuf != 0)
glDeleteBuffers(1, &gl->fragBuf); // <- the function that gcc complains about is here
// ...
Edit: Just to make sure that I did not do anything sneaky that might have caused the difference, I followed the following steps which hopefully should be reproducible on another computer:
GCC version: gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
Copy the version of GL/gl.h can be found here to working directory and call it glfoo.h
Copy the headers of nanovg (as found in the repo) to /usr/include/nanovg/ and nanovg/ (relative to working directory).
Save the following as test.c in the working dir:
#include "glfoo.h"
#include <nanovg/nanovg.h>
#define NANOVG_GL3_IMPLEMENTATION
#include <nanovg/nanovg_gl.h>
Run gcc -c test.c -o test.o => compilation works
Replace <...> with ".." on lines 2 and 4 and run command => compilation fails.
Just tried these exact steps and I was able to reproduce it.
After investigating this a bit I found the solution. gcc does not apply the same warning level to system headers as it does for "normal" files (this is mainly because system headers are sometimes doing weird things which are not backed up by the C standard, but are "safe" for the platform they are coming with).
The gcc documentation states (emphasis mine):
-Wsystem-headers:
Print warning messages for constructs found in system header files. Warnings from system headers are normally suppressed, on
the assumption that they usually do not indicate real problems and
would only make the compiler output harder to read. Using this
command-line option tells GCC to emit warnings from system headers as
if they occurred in user code. However, note that using -Wall in
conjunction with this option does not warn about unknown pragmas in
system headers—for that, -Wunknown-pragmas must also be used.
When you include nanovg via <...>, it is treated as a system header.
So doing gcc -Wsystem-headers working.c actually will bring on the warning.
Note that your code is neither working in working.c nor notworking.c, as working.c just hides the warning messages. The proper way to access any GL function beyond what is defined in GL 1.1 is to use the GL extension mechanism, which means you have to query the GL function pointers at run-time. Full GL loader libs like GLEW and glad can do that for you automatically. Many of these loaders (including GLEW and GLAD) work by re-#define-ing every GL function name to an internal function pointer, so when you include the header which comes with the loader, every GL function called in your code (and nanovg's) will be re-routed to the loader-libraries function pointers, and your code can actually work (provided you properly initialize the loader at run-time before any of the GL functions is called).
simply
#include <file.h>
include file from the path listed default to the compiler, while
#include "file.h"
include file from the current folder (where you are compiling).
As in your case , switching from <> to "" makes come files missing which makes that compiler error coming.
This question already has answers here:
GCC with -std=c99 complains about not knowing struct timespec
(3 answers)
Closed 6 years ago.
Hello and thanks in advance for all the problems this platform has solved for me in the past. Unfortunately I've found a problem, which I couldn't solve.
I'm pretty new to cmake and expanded a demo project with a new executable and some library files. I have no problems compiling the demo project. However, my new project needs to be compiled with c99 standard and suddenly, I get errors implementing the timespec struct from time.h. This is also used in the demo project, so I compiled the demo again with c99 and I've got the same problem.
Running this on Ubuntu, using the gcc compiler and cmake version 2.8.7
Hope I've got all necessary details covered. If not, please let me know and thanks in advance for your efforts!
Best regards
Edit#1: Error messages I get:
- >CLOCK_MONOTONIC< not declared (first use in this function)
- field 'tv_nsec' could not be resolved
- field 'tv_sec' could not be resolved
- Symbol 'CLOCK_MONOTONIC' could not be resolved
- Warnings for implicit declaration of functions 'clock_gettime', 'nanosleep', 'timeradd', 'timercmp'
Edit#2: error output with make VERBOSE=1
/usr/bin/gcc -D_XOPEN_SOURCE=600 -I/home/localadmin/Eclipse_Workspace/SOEM_master/soem -I/home/localadmin/Eclipse_Workspace/SOEM_master/osal -I/home/localadmin/Eclipse_Workspace/SOEM_master/osal/linux -I/home/localadmin/Eclipse_Workspace/SOEM_master/oshw/linux -std=c99 -o CMakeFiles/soem.dir/osal/linux/osal.c.o -c /home/localadmin/Eclipse_Workspace/SOEM_master/osal/linux/osal.c
/home/localadmin/Eclipse_Workspace/SOEM_master/osal/linux/osal.c:60:50: Warning: »struct timezone« declared in parameter list [activated by default]
/home/localadmin/Eclipse_Workspace/SOEM_master/osal/linux/osal.c:60:50: Warning: range of validity includes only this definition or declaration [activated by default]
/home/localadmin/Eclipse_Workspace/SOEM_master/osal/linux/osal.c: In function »osal_timer_start«:
/home/localadmin/Eclipse_Workspace/SOEM_master/osal/linux/osal.c:105:4: Warning: Implicit function »timeradd« [-Wimplicit-function-declaration]
/home/localadmin/Eclipse_Workspace/SOEM_master/osal/linux/osal.c: In function »osal_timer_is_expired«:
/home/localadmin/Eclipse_Workspace/SOEM_master/osal/linux/osal.c:120:4: Warning: Implicit declaration of function »timercmp« [-Wimplicit-function-declaration]
/home/localadmin/Eclipse_Workspace/SOEM_master/osal/linux/osal.c:120:61: Error: expected expression before »<« token
make[2]: *** [CMakeFiles/soem.dir/osal/linux/osal.c.o] Error 1
make[2]: Leaving directory '/home/localadmin/Eclipse_Workspace/SOEM_master/build'
make[1]: *** [CMakeFiles/soem.dir/all] Error 2
make[1]: Leaving directory '/home/localadmin/Eclipse_Workspace/SOEM_master/build'
make: *** [all] Error 2
This was the output after definining _XOPEN_SOURCE=600, what was suggested in the other thread that got posted below. So the timespec struct is available, but the functions aren't.
Edit #3: minimal, complete and verifiable example
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>
int main()
{
struct timespec test;
test.tv_sec = 0;
struct timeval start_time;
struct timeval timeout;
struct timeval stop_time;
timeradd(&start_time, &timeout, &stop_time);
return 0;
}
Compiles without problems. If I use gcc mcv_example.c -std=c99 I get:
mcv_example.c: In function 'main':
mcv_example.c:24:18: error: storage size of 'test' isn't known
mcv_example.c:29:2: warning: implicit declaration of function 'timeradd' [-Wimplicit-function-declaration]
Edit#4: The solution for me was using gnu99 instead of c99. Now I can create the UNIX Makefiles with cmake, but still can't create a working Eclipse project.
Since that is a different problem, I guess this case is closed and thank you all for your help and efforts!
As man timeradd says, definition of function timeradd is available only when _DEFAULT_SOURCE feature-test-macro is defined:
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
All functions shown above:
Since glibc 2.19:
_DEFAULT_SOURCE
Glibc 2.19 and earlier:
_BSD_SOURCE
Description for _DEFAULT_SOURCE macro in man feature_test_macros says:
This macro can be defined to ensure that the "default" definitions
are provided even when the defaults would otherwise be disabled,
as happens when individual macros are explicitly defined, or the
compiler is invoked in one of its "standard" modes (e.g.,
cc -std=c99).
So you need to explicitely define _DEFAULT_SOURCE macro for make function timeradd being available in -std=c99 mode:
#define _DEFAULT_SOURCE
#include <sys/time.h>
...
timeradd(...);
I have a function for getline function in my code block.But while compiling the make file i get the following error:
cc -DMAIN -c -o terp.o terp.c
terp.c:130:15: error: conflicting types for ‘getline’
In file included from terp.c:2:0:
/usr/include/stdio.h:675:20: note: previous declaration of ‘getline’ was here
make: *** [terp.o] Error 1
The part terp.c around 130:
PRIVATE char *getline()
{
static int first_time_called=1;
if(!first_time_called)
return 0;
first_time_called=0;
return Expr;
}
There are at least three possible solutions.
As getline() is not in standard c library, but in POSIX (and GLIBC), there could be switch to disable its extension (they enabled by default in GCC). Try compiling your source with command cc -DMAIN -std=c99 -c -o terp.o terp.c.
If you need POSIX extensions, you have to rename your getline() function to something else.
Remove #include <stdio.h> from your source, this error message will disappear. But you may become confused if POSIX's getline() is used in your source code, as it will be replaced by yours.
You need to choose a different name for your getline function, because there already is a getline in the standard clib.
I'm trying to use graphviz as a library for a C++ project, following the libguide provided here. However I'm having problems even compiling the examples in the appendix. When I try to compile demo.c using gcc I get the following output:
$ gcc -I/usr/local/Cellar/graphviz/2.28.0/include/ demo.c -L/usr/local/Cellar/graphviz/2.28.0/lib/ -lgvc -lgraph -lcdt
demo.c: In function ‘main’:
demo.c:14: error: ‘Agdirected’ undeclared (first use in this function)
demo.c:14: error: (Each undeclared identifier is reported only once
demo.c:14: error: for each function it appears in.)
demo.c:15: error: too many arguments to function ‘agnode’
demo.c:16: error: too many arguments to function ‘agnode’
demo.c:17: error: too many arguments to function ‘agedge’
Agdirected is found in cgraph.h, but if I change the includes in demo.c to
#include <graphviz/gvc.h>
#include <graphviz/cgraph.h>
Then all hell breaks loose (mostly conflicting declarations between the two headers). How can I include the necessary headers without the headache of all these conflicts?
Mac OS X 10.8.3, Graphviz 2.28.0, GCC 4.2.1
It seems after some experimentation that adding the flag
#define WITH_CGRAPH
has the effect of including cgraph.h, which gets rid of the "'Agdirected' undeclared" error.
The other errors can be fixed by changing the command line option in gcc from -lgraph to -lcgraph
The libguide you are using is the cgraph version, which assumes Graphviz 2.30 or later. With that version, the #define WITH_CGRAPH is already provided.
I'm trying to cross compile my application for the maemo environment (GNU).
When compiling the application normally, everything works fine, however when it's compiled through sb2 the following warning comes up:
$ sb2 gcc -D_GNU_SORCE -o app -Wall -g -I.......//don't think this is relevant
In file included from wifi_collector_menu.c:50:
wifi_collector_list.c: In function `show_net_apns':
wifi_collector_list.c:777: warning: implicit declaration of function `getline'
I am completely confused as to why this happens, there are other getlines that do work in the program, i have tried to define the variable _GNU_SOURCE both inside the code and in the compiler command (not at the same time)
This is the line of code which causes the warning apparently:
size_t bytesnum = MAX_ESSID;
size_t bytes_read;
char *netname = NULL;
printf("Enter name of selected network:");
bytes_read=getline(&netname,&bytesnum,stdin);//This line
Any help would be appreciated, thanks in advance.
Problem solved, all I had to do was add:
#define _GNU_SOURCE
In each header file, before stdio.h was included, very simple really.
I guess this info is assumed known between programmers as i was unable to find it anywhere online, and had to ask my C programming professor personally, and even then we had some trouble tracing the source.
Thanks anyway.
Change your compiler line to include the -E option and redirect the output. The compiler will only pre-proccess your file when this option is used. Do this for both versions, with and without sb2. getline() is normally found in stdio.h. By viewing the preprocessed output from both versions, you should be able to see where getline() is being included from.