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.
Related
I'm knee-deep in [K&R88] and I get chided by gcc because the function getline(), which K&R use as example and practise material, is now in stdio.h (and has been since around 2010, I'm told.)
Would there be any manner to tell the compiler to play it like it's 1988 and to have my homespun version supersede the one from the library ?
(yes it's futile, but wadding in [K&R88] is my new hobby ;-)
Obligatory compiler output :
gcc -g -Wall -o "pgm" "pgm.c" (in directory: /home/eric/Development/6.087)
pgm.c:9:7: error: conflicting types for ‘getline’
9 | char *getline(){
| ^~~~~~~
In file included from pgm.c:1:
/usr/include/stdio.h:616:18: note: previous declaration of ‘getline’ was here
616 | extern __ssize_t getline (char **__restrict __lineptr,
| ^~~~~~~
Compilation failed.
The getline function that conflicts with yours isn't part of standard C - it's POSIX's getline.
If you compile with standard C using -std:
gcc -g -Wall -std=c17 -o pgm pgm.c
you can avoid the conflict.
Having said that there's no reason to learn from K&R C (it's more of a reference imo) if you're starting out in C. And we're not going back to 1988 either ;-)
The language has changed a lot since and there's a good list of recommendations available at The Definitive C Book Guide and List.
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.
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.
Here is the error I get from the gcc call:
gcc -o rr4 shells2.c graph1.c rng.c;
Undefined symbols:
"_getdisc", referenced from:
_main in cckR7zjP.o
ld: symbol(s) not found
The "cckR7zjP.o" keeps changing every time I call the compiler. The code for the method is in the file graph1.c; its header file is called graph2.h, and I am importing it to the file with the main method called shells2.c using:
#include "graph2.h"
The method or function definition is:
int getdisc(int i){ return disc[i];}
which attempts to return the ith member of the array disc created by
static int *disc;
that I already initialized in some other method! I think the problematic call is:
for (iter = 0; iter < n; iter++) {
if (getdisc(iter) == cln)
avgbtwn += get_betweenness(iter);
}
This seems like a linker problem I checked with some other questions, and I think I am linking my method properly (and am using the same method elsewhere in the code) but I still can't figure this out.
Edit: So I switched the order of the command in linux to
gcc -o rr4 graph1.c rng.c shells2.c
as per Soren's suggestion and the function compiled as normal, does anyone know why?
Further it seems when i put a trailing line break in the file graph1.c alleviates the problem.
There used to be a issue in the old GCC 2.x compilers/linkers where the linker couldn't resolve linking when the symbols were not group together -- think of it as that the linker would only looks for symbols that is still needed, and it would drop symbols which were unused.
To most people the problem would manifest itself as a problem of the ordering of libraries (specified with -l or as .a).
I see from the comments that you use a mac, so it might just be that the mac version of the compiler/linker still has that problem -- anyway since reordering the source files solved the problem, then you certainly have some variation of this bug.
So possible solutions;
Group all your source files into larger files -- bad solution -- but the linker is less likely to fail with this symptom -- or
Try to compiler all the files to .o first and then link the .o files (using a makefile would usually do this, but may or may not resolve the problem) and possibly combine the .o into a single .a (man ar), or
Change the order of the source files to have the shells2.c last (which worked for you), or
See if upgrading your compiler helps
Sorry for the long laundry list, but this is clearly just a compiler bug which just need a simple work around.
That's definitely an error with getdisc not being visible to the linker but, if what you say is correct, that shouldn't happen.
The gcc command line you have includes graph1.c which you assure use contains the function.
Don't worry about the object file name, that's just a temprary name created by the compiler to pass to the linker.
Can you confirm (exact cut and paste) the gcc command line you're using, and show us the function definition with some context around it?
In addition, make sure that graph1.c is being compiled as expected by inserting immediately before the getdisc function, the following line:
xyzzy plugh twisty;
If your function is being seen by the compiler, that should cause an error first. It may be something like ifdef statements causing your code not to be compiled.
By way of testing, the following transcript shows that what you are trying to do works just fine:
pax> cat shells2.c
#include "graph2.h"
int main (void) {
int x = getdisc ();
return x;
}
pax> cat graph2.h
int getdisc (void);
pax> cat graph1.c
int getdisc (void) {
return 42;
}
pax> gcc -o rr4 shells2.c graph1.c
pax> ./rr4
pax> echo $?
42
We have to therefore assume that what you're actually doing is something different, and that's unusually tactful for me :-)
What you're experiencing is what would happen with something like:
pax> gcc -o rr4 shells2.c
/tmp/ccb4ZOpG.o: In function `main':
shells2.c:(.text+0xa): undefined reference to `getdisc'
collect2: ld returned 1 exit status
or if getdisc was not declared correctly in graph1.c.
That last case could be for many reasons including, but not limited to:
mis-spelling of getdisc.
#ifdef type statements meaning the definition is never seen (though you seem to have discounted that in a comment).
some wag using #define to change getdisc to something else (unlikely, but possible).
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.