Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #97624 > unrolled thread

Can't link a simple header file to an even more simple program

Back to article view | Back to comp.lang.c

Contents

  Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 02:41 -0800
    Re: Can't link a simple header file to an even more simple program BartC <bc@freeuk.com> - 2016-11-28 11:00 +0000
      Re: Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 03:17 -0800
    Re: Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 03:04 -0800
      Re: Can't link a simple header file to an even more simple program Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-28 13:39 +0000
    Re: Can't link a simple header file to an even more simple program Ike Naar <ike@iceland.freeshell.org> - 2016-11-28 12:48 +0000
      Re: Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 08:05 -0800
        Re: Can't link a simple header file to an even more simple program Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 16:20 +0000
          Re: Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 09:26 -0800
            Re: Can't link a simple header file to an even more simple program Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 17:56 +0000
              Re: Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 10:04 -0800
                Re: Can't link a simple header file to an even more simple program Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 18:08 +0000
            Re: Can't link a simple header file to an even more simple program "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-28 12:57 -0500
              Re: Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 10:10 -0800
                Re: Can't link a simple header file to an even more simple program Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 18:13 +0000
                  Re: Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 10:17 -0800
                Re: Can't link a simple header file to an even more simple program "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-28 13:19 -0500
                  Re: Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 10:22 -0800
              Re: Can't link a simple header file to an even more simple program David Thompson <dave.thompson2@verizon.net> - 2016-12-10 22:40 -0500
    Re: Can't link a simple header file to an even more simple program Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 12:55 +0000
      Re: Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 08:45 -0800
        Re: Can't link a simple header file to an even more simple program Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 17:11 +0000
          Re: Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 09:49 -0800
            Re: Can't link a simple header file to an even more simple program Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 18:00 +0000
              Re: Can't link a simple header file to an even more simple program Alla _ <modelling.data@gmail.com> - 2016-11-28 10:12 -0800

Page 1 of 2  [1] 2  Next page →

#97624 — Can't link a simple header file to an even more simple program

Hello!

I have an issue with a very simple test code (downloaded from net): the compiler shows an error 
message, which usually would indicate (at least this what I managed to learn about his error message) 
that I have not added a correct library

Undefined symbols for architecture x86_64:
  "_function1", referenced from:
      _main in 02_01-18ac0b.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Originally both the header and the .c file, which defines functions in the header file, didn't have an #include <stdio.h> line; the compiler displayed the above error message. Haven't found any mistake, I have added the stdio.h library, but the compiler still displays the same error message. I don't 
understand why the header is not being linked. 

(1) a program:  
    #include <stdio.h>			
    #include <stdlib.h>

    #include "myLibrary.h"		

   #define MAX_LENGTH 21.8
   #define WORK_WEEK  5

   int main(void) {
	function1();
	return EXIT_SUCCESS;
  }

(2) header file:

 #include <stdio.h> /** wasn't in the original file, added by me**/

#ifndef MYLIBRARY_H_
#define MYLIBRARY_H_

void function1(void);
void function2(void);

#endif /* MYLIBRARY_H_ */

(3) 
#include <stdio.h>  /** wasn't in the original file, added by me**/

void function1(void){
	puts("It works :)\n");
}

void function2(void){
	//This function does nothing as well
}

Thank you very much!

[toc] | [next] | [standalone]

#97625

On 28/11/2016 10:41, Alla _ wrote:

> I have an issue with a very simple test code (downloaded from net): the compiler shows an error
> message, which usually would indicate (at least this what I managed to learn about his error message)
> that I have not added a correct library
>
> Undefined symbols for architecture x86_64:
>   "_function1", referenced from:
>       _main in 02_01-18ac0b.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>
> Originally both the header and the .c file, which defines functions in the header file, didn't have an #include <stdio.h> line; the compiler displayed the above error message. Haven't found any mistake, I have added the stdio.h library, but the compiler still displays the same error message. I don't
> understand why the header is not being linked.
>
> (1) a program:
>     #include <stdio.h>			
>     #include <stdlib.h>
>
>     #include "myLibrary.h"		
>
>    #define MAX_LENGTH 21.8
>    #define WORK_WEEK  5
>
>    int main(void) {
> 	function1();
> 	return EXIT_SUCCESS;
>   }
>
> (2) header file:
>
>  #include <stdio.h> /** wasn't in the original file, added by me**/
>
> #ifndef MYLIBRARY_H_
> #define MYLIBRARY_H_
>
> void function1(void);
> void function2(void);
>
> #endif /* MYLIBRARY_H_ */
>
> (3)
> #include <stdio.h>  /** wasn't in the original file, added by me**/
>
> void function1(void){
> 	puts("It works :)\n");
> }
>
> void function2(void){
> 	//This function does nothing as well
> }

If file (1) is called test.c, file (2) is called myLibrary.h, and (3) is 
called myLibrary.c, then try this command line:

   gcc test.c myLibrary.c

(Similar for clang.)

It should compile both files and generate an executable a.out or a.exe 
(unless you specify -o test.exe or something but I won't go into that).

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#97627

<snip>
> If file (1) is called test.c, file (2) is called myLibrary.h, and (3) is 
> called myLibrary.c, then try this command line:
> 
>    gcc test.c myLibrary.c
> 
> (Similar for clang.)
> 
> It should compile both files and generate an executable a.out or a.exe 
> (unless you specify -o test.exe or something but I won't go into that).
> 
Yes, thank you )

[toc] | [prev] | [next] | [standalone]

#97626

<snip>
I think I have found the solution: I have completely forgotten that I have to compile both .c files together
by using gcc -o final_file functions.c main.c
where functions.c contains functions for the header file, and main.c is the main program.

[toc] | [prev] | [next] | [standalone]

#97634

Alla _ <modelling.data@gmail.com> writes:

> <snip>
> I think I have found the solution: I have completely forgotten that I
> have to compile both .c files together
> by using gcc -o final_file functions.c main.c
> where functions.c contains functions for the header file, and main.c
> is the main program.

Or you can compile them separately:

  gcc -c main.c
  gcc -c functions.c

and then link the resulting .o files:

  gcc main.o functions.o

When programs get bigger, compiling just the bits you need can start to
pay off.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#97631

On 2016-11-28, Alla _ <modelling.data@gmail.com> wrote:
> Hello!
>
> I have an issue with a very simple test code (downloaded from net): the compiler shows an error 
> message, which usually would indicate (at least this what I managed to learn about his error message) 
> that I have not added a correct library
>
> Undefined symbols for architecture x86_64:
>   "_function1", referenced from:
>       _main in 02_01-18ac0b.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>
> Originally both the header and the .c file, which defines functions in the header file, didn't have an #include <stdio.h> line; the compiler displayed the above error message. Haven't found any mistake, I have added the stdio.h library, but the compiler still displays the same error message. I don't 
> understand why the header is not being linked. 

Elsethread it has already been explained that you must compile both the main
.c file and myLibrary.c . A few other comments:

> (1) a program:  
>     #include <stdio.h>			

The #include <stdio.h> is unnecessary.

>     #include <stdlib.h>
>
>     #include "myLibrary.h"		
>
>    #define MAX_LENGTH 21.8
>    #define WORK_WEEK  5
>
>    int main(void) {
> 	function1();
> 	return EXIT_SUCCESS;
>   }
>
> (2) header file:
>
>  #include <stdio.h> /** wasn't in the original file, added by me**/

The #include <stdio.h> is unnecessary.

> #ifndef MYLIBRARY_H_
> #define MYLIBRARY_H_
>
> void function1(void);
> void function2(void);
>
> #endif /* MYLIBRARY_H_ */
>
> (3) 
> #include <stdio.h>  /** wasn't in the original file, added by me**/

Here it would be a good idea to #include "myLibrary.h" as well.
This way, the compiler can check that the declararions in 
myLibrary.h and myLibrary.c are not conflicting.

> void function1(void){
> 	puts("It works :)\n");


The "\n" at the string is not necessary, puts() already adds a terminating
newline to the string to be printed.

> }
>
> void function2(void){
> 	//This function does nothing as well
> }

[toc] | [prev] | [next] | [standalone]

#97644

On Monday, November 28, 2016 at 3:50:16 PM UTC+3, Ike Naar wrote:
> On 2016-11-28, Alla _ <modelling.data@gmail.com> wrote:
> > Hello!
> >
> > I have an issue with a very simple test code (downloaded from net): the compiler shows an error 
> > message, which usually would indicate (at least this what I managed to learn about his error message) 
> > that I have not added a correct library
> >
> > Undefined symbols for architecture x86_64:
> >   "_function1", referenced from:
> >       _main in 02_01-18ac0b.o
> > ld: symbol(s) not found for architecture x86_64
> > clang: error: linker command failed with exit code 1 (use -v to see invocation)
> >
> > Originally both the header and the .c file, which defines functions in the header file, didn't have an #include <stdio.h> line; the compiler displayed the above error message. Haven't found any mistake, I have added the stdio.h library, but the compiler still displays the same error message. I don't 
> > understand why the header is not being linked. 
> 
> Elsethread it has already been explained that you must compile both the main
> .c file and myLibrary.c . A few other comments:
> 
> > (1) a program:  
> >     #include <stdio.h>			
> 
> The #include <stdio.h> is unnecessary.
> 
> >     #include <stdlib.h>
> >
> >     #include "myLibrary.h"		
> >
> >    #define MAX_LENGTH 21.8
> >    #define WORK_WEEK  5
> >
> >    int main(void) {
> > 	function1();
> > 	return EXIT_SUCCESS;
> >   }
> >
> > (2) header file:
> >
> >  #include <stdio.h> /** wasn't in the original file, added by me**/
> 
> The #include <stdio.h> is unnecessary.
> 
> > #ifndef MYLIBRARY_H_
> > #define MYLIBRARY_H_
> >
> > void function1(void);
> > void function2(void);
> >
> > #endif /* MYLIBRARY_H_ */
> >
> > (3) 
> > #include <stdio.h>  /** wasn't in the original file, added by me**/
> 
> Here it would be a good idea to #include "myLibrary.h" as well.
> This way, the compiler can check that the declararions in 
> myLibrary.h and myLibrary.c are not conflicting.
> 
Thank you! ) Yes, I did eventually use #include "myLibrary.h" . I don't know why
but I had to add stdio.h library because without it I kept getting the error message
about puts function; once I included the standard library, the error was gone.

[toc] | [prev] | [next] | [standalone]

#97647

On 28/11/16 16:05, Alla _ wrote:
> On Monday, November 28, 2016 at 3:50:16 PM UTC+3, Ike Naar wrote:
>> On 2016-11-28, Alla _ <modelling.data@gmail.com> wrote:
>>> Hello!
>>>
>>> I have an issue with a very simple test code (downloaded from net): the compiler shows an error
>>> message, which usually would indicate (at least this what I managed to learn about his error message)
>>> that I have not added a correct library
>>>
>>> Undefined symbols for architecture x86_64:
>>>   "_function1", referenced from:
>>>       _main in 02_01-18ac0b.o
>>> ld: symbol(s) not found for architecture x86_64
>>> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>>>
>>> Originally both the header and the .c file, which defines functions in the header file, didn't have an #include <stdio.h> line; the compiler displayed the above error message. Haven't found any mistake, I have added the stdio.h library, but the compiler still displays the same error message. I don't
>>> understand why the header is not being linked.
>>
>> Elsethread it has already been explained that you must compile both the main
>> .c file and myLibrary.c . A few other comments:
>>
>>> (1) a program:
>>>     #include <stdio.h>			
>>
>> The #include <stdio.h> is unnecessary.
>>
>>>     #include <stdlib.h>
>>>
>>>     #include "myLibrary.h"		
>>>
>>>    #define MAX_LENGTH 21.8
>>>    #define WORK_WEEK  5
>>>
>>>    int main(void) {
>>> 	function1();
>>> 	return EXIT_SUCCESS;
>>>   }
>>>
>>> (2) header file:
>>>
>>>  #include <stdio.h> /** wasn't in the original file, added by me**/
>>
>> The #include <stdio.h> is unnecessary.
>>
>>> #ifndef MYLIBRARY_H_
>>> #define MYLIBRARY_H_
>>>
>>> void function1(void);
>>> void function2(void);
>>>
>>> #endif /* MYLIBRARY_H_ */
>>>
>>> (3)
>>> #include <stdio.h>  /** wasn't in the original file, added by me**/
>>
>> Here it would be a good idea to #include "myLibrary.h" as well.
>> This way, the compiler can check that the declararions in
>> myLibrary.h and myLibrary.c are not conflicting.
>>
> Thank you! ) Yes, I did eventually use #include "myLibrary.h" . I don't know why
> but I had to add stdio.h library because without it I kept getting the error message
> about puts function; once I included the standard library, the error was gone.

Stop right there.

Several points.

1) you did /not/ "include" the standard library. <stdio.h> is not a 
library, but a header. You included the <stdio.h> header, not the 
<stdio.h> library (no such thing!). Libraries are never included; they 
are linked. Generally you don't have to worry about linking the standard 
library because the implementation pulls it in anyway. (Exception: gcc 
moans if you don't specifically mention the math library when you need 
it, so if you do use any functions from the math library you need to add 
-lm to your link line.)

2) The header is not required in "mylibrary.h", because nothing in 
"mylibrary.h" needs any of the types, aliases, macros, or function 
prototypes defined in <stdio.h>

3) It is not required in your first C file either, because nothing in 
your first C file needs any of the types, aliases, macros, or function 
prototypes defined in <stdio.h>

4) It *is* required in your second C file, because your second C file 
calls puts(), so you need a valid prototype in scope for puts(). You 
provide that prototype by inserting

#include <stdio.h>

in your second C file.

When you get an error message from your implementation, it is always a 
good idea to stop and think about what that error message is telling 
you. In this case, when you removed <stdio.h> completely, gcc would have 
compiled your first C file quite happily, but it would have complained 
about your second C file because it was calling puts(), for which a 
prototype was required.

Don't program randomly. When the compiler (or linker) complains, don't 
just make arbitrary changes until the problem goes away. Think about 
what the error message *means*, and use that opportunity to learn more 
about C.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#97654

On Monday, November 28, 2016 at 7:21:07 PM UTC+3, Richard Heathfield wrote:
> On 28/11/16 16:05, Alla _ wrote:
> > On Monday, November 28, 2016 at 3:50:16 PM UTC+3, Ike Naar wrote:
> >> On 2016-11-28, Alla _ <modelling.data@gmail.com> wrote:
> >>> Hello!
> >>>
> >>> I have an issue with a very simple test code (downloaded from net): the compiler shows an error
> >>> message, which usually would indicate (at least this what I managed to learn about his error message)
> >>> that I have not added a correct library
> >>>
> >>> Undefined symbols for architecture x86_64:
> >>>   "_function1", referenced from:
> >>>       _main in 02_01-18ac0b.o
> >>> ld: symbol(s) not found for architecture x86_64
> >>> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> >>>
> >>> Originally both the header and the .c file, which defines functions in the header file, didn't have an #include <stdio.h> line; the compiler displayed the above error message. Haven't found any mistake, I have added the stdio.h library, but the compiler still displays the same error message. I don't
> >>> understand why the header is not being linked.
> >>
> >> Elsethread it has already been explained that you must compile both the main
> >> .c file and myLibrary.c . A few other comments:
> >>
> >>> (1) a program:
> >>>     #include <stdio.h>			
> >>
> >> The #include <stdio.h> is unnecessary.
> >>
> >>>     #include <stdlib.h>
> >>>
> >>>     #include "myLibrary.h"		
> >>>
> >>>    #define MAX_LENGTH 21.8
> >>>    #define WORK_WEEK  5
> >>>
> >>>    int main(void) {
> >>> 	function1();
> >>> 	return EXIT_SUCCESS;
> >>>   }
> >>>
> >>> (2) header file:
> >>>
> >>>  #include <stdio.h> /** wasn't in the original file, added by me**/
> >>
> >> The #include <stdio.h> is unnecessary.
> >>
> >>> #ifndef MYLIBRARY_H_
> >>> #define MYLIBRARY_H_
> >>>
> >>> void function1(void);
> >>> void function2(void);
> >>>
> >>> #endif /* MYLIBRARY_H_ */
> >>>
> >>> (3)
> >>> #include <stdio.h>  /** wasn't in the original file, added by me**/
> >>
> >> Here it would be a good idea to #include "myLibrary.h" as well.
> >> This way, the compiler can check that the declararions in
> >> myLibrary.h and myLibrary.c are not conflicting.
> >>
> > Thank you! ) Yes, I did eventually use #include "myLibrary.h" . I don't know why
> > but I had to add stdio.h library because without it I kept getting the error message
> > about puts function; once I included the standard library, the error was gone.
> 
> Stop right there.
> 
> Several points.
> 
> 1) you did /not/ "include" the standard library. <stdio.h> is not a 
> library, but a header. You included the <stdio.h> header, not the 
> <stdio.h> library (no such thing!). Libraries are never included; they 
> are linked. Generally you don't have to worry about linking the standard 
> library because the implementation pulls it in anyway. (Exception: gcc 
> moans if you don't specifically mention the math library when you need 
> it, so if you do use any functions from the math library you need to add 
> -lm to your link line.)
> 
> 2) The header is not required in "mylibrary.h", because nothing in 
> "mylibrary.h" needs any of the types, aliases, macros, or function 
> prototypes defined in <stdio.h>
> 
> 3) It is not required in your first C file either, because nothing in 
> your first C file needs any of the types, aliases, macros, or function 
> prototypes defined in <stdio.h>
> 
> 4) It *is* required in your second C file, because your second C file 
> calls puts(), so you need a valid prototype in scope for puts(). You 
> provide that prototype by inserting
> 
> #include <stdio.h>
> 
> in your second C file.
> 
> When you get an error message from your implementation, it is always a 
> good idea to stop and think about what that error message is telling 
> you. In this case, when you removed <stdio.h> completely, gcc would have 
> compiled your first C file quite happily, but it would have complained 
> about your second C file because it was calling puts(), for which a 
> prototype was required.
> 
> Don't program randomly. When the compiler (or linker) complains, don't 
> just make arbitrary changes until the problem goes away. Think about 
> what the error message *means*, and use that opportunity to learn more 
> about C.
> 
Yes, exactly; that was not a random choice from my side; I have spent a while thinking why 
the compiler was giving me that error message. I thought that as far as I use any standard functions, 
like puts, or printf, etc, I need <stdio.h>, as in all other numerous little and bigger programs I have worked
with during this time. But I was frustrated by the fact that the original file (the one I have taken from the 
net) did not have that header, and nothing was mentioned about it; and I didn't understand why the guy 
who has created the code didn't face any issues when he compiled the program; as you have said, 
 "Generally you don't have to worry about linking the standard library because the implementation pulls
 it in anyway."; well, in my case I have to link it  everywhere.
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#97658

On 28/11/16 17:26, Alla _ wrote:

<snip>

> I thought that as far as I use any standard functions,
> like puts, or printf, etc, I need <stdio.h>,

For those functions, yes. For other functions, you need different 
headers. But you only need to include the header into the file that uses 
the features provided by that header.

In your case, your first file didn't use any of the features provided by 
<stdio.h> so it didn't need to include it. The same applied to your own 
custom header --- that didn't need anything from <stdio.h> either. But 
your second C file /did/ call puts(), so it needed to include <stdio.h>.

> as in all other numerous little and bigger programs I have worked
> with during this time. But I was frustrated by the fact that the original file (the one I have taken from the
> net) did not have that header, and nothing was mentioned about it; and I didn't understand why the guy
> who has created the code didn't face any issues when he compiled the program; as you have said,
>  "Generally you don't have to worry about linking the standard library because the implementation pulls
>  it in anyway."; well, in my case I have to link it  everywhere.

Really? I find that very surprising and almost certainly mistaken. Are 
you sure you are not still confusing headers and libraries?

Headers are included. <stdio.h> is a header. You need it in your 
*second* C file *only*.

Libraries are linked. The C runtime library is normally linked 
automatically by gcc. Are you saying your version of gcc does not do this?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#97661

On Monday, November 28, 2016 at 8:57:10 PM UTC+3, Richard Heathfield wrote:
> On 28/11/16 17:26, Alla _ wrote:
> 
> <snip>
> 
> > I thought that as far as I use any standard functions,
> > like puts, or printf, etc, I need <stdio.h>,
> 
> For those functions, yes. For other functions, you need different 
> headers. But you only need to include the header into the file that uses 
> the features provided by that header.
> 
Yes yes )

> In your case, your first file didn't use any of the features provided by 
> <stdio.h> so it didn't need to include it. The same applied to your own 
> custom header --- that didn't need anything from <stdio.h> either. But 
> your second C file /did/ call puts(), so it needed to include <stdio.h>.
> 
> > as in all other numerous little and bigger programs I have worked
> > with during this time. But I was frustrated by the fact that the original file (the one I have taken from the
> > net) did not have that header, and nothing was mentioned about it; and I didn't understand why the guy
> > who has created the code didn't face any issues when he compiled the program; as you have said,
> >  "Generally you don't have to worry about linking the standard library because the implementation pulls
> >  it in anyway."; well, in my case I have to link it  everywhere.
> 
> Really? I find that very surprising and almost certainly mistaken. Are 
> you sure you are not still confusing headers and libraries?
> 
> Headers are included. <stdio.h> is a header. You need it in your 
> *second* C file *only*.
> 
> Libraries are linked. The C runtime library is normally linked 
> automatically by gcc. Are you saying your version of gcc does not do this?

:D I got it. Yes, I have confused two verbs "include" and "link". 
I was a bit surprised to read (given I gathered the meaning incorrectly) that I don't
need to link the standard library, as I have been doing since the very first day, i.e.
not by "linking", but by "including" the header ))) And by saying "I have to 
link it everywhere" I meant that I have to include (not link) the header, which is, obviously,
a must do thing for everyone ))) Sorry. 
Two seemingly simple verbs - to link and to include ))) 
> 
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#97662

On 28/11/16 18:04, Alla _ wrote:
<snip>
>
> :D I got it. Yes, I have confused two verbs "include" and "link".

Quite so. The difference is very important.

> I was a bit surprised to read (given I gathered the meaning incorrectly) that I don't
> need to link the standard library,

Well, it has to be linked, but gcc does it for you (except as noted 
previously regarding the math library), so you don't need to do anything 
special (except as noted previously regarding the math library).

But you /do/ need to keep your headers straight; gcc won't do that for you.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#97659

On 11/28/2016 12:26 PM, Alla _ wrote:
> On Monday, November 28, 2016 at 7:21:07 PM UTC+3, Richard Heathfield wrote:
...
>> Don't program randomly. When the compiler (or linker) complains, don't
>> just make arbitrary changes until the problem goes away. Think about
>> what the error message *means*, and use that opportunity to learn more
>> about C.
>>
> Yes, exactly; that was not a random choice from my side; I have spent a while thinking why
> the compiler was giving me that error message. I thought that as far as I use any standard functions,
> like puts, or printf, etc, I need <stdio.h>,

Wrong. You're just guessing, which is what Richard is telling you to 
stop doing. You happened to guess correctly for puts(), but the C 
standard library has 29 different header files. <stdio.h> is one of the 
most used, but it won't, for instance, provide any help if you want to 
call cacos() or wctrans(), which require <complex.h> and <wctype.h>, 
respectively.

Stop guessing. Until you've got the relevant headers memorized, always 
check the documentation on any function you want to use, to find out 
which header is needed. On unix systems, "man va_end", for instance, 
will tell you that you need to #include <stdarg.h> to use the va_end macro.

  as in all other numerous little and bigger programs I have worked
> with during this time. But I was frustrated by the fact that the original file (the one I have taken from the
> net) did not have that header, and nothing was mentioned about it; and I didn't understand why the guy
> who has created the code didn't face any issues when he compiled the program; as you have said,
>  "Generally you don't have to worry about linking the standard library because the implementation pulls
>  it in anyway."; well, in my case I have to link it  everywhere.

You're confusing #including a header with linking the library - again. 
Those are two entirely different, though related, activities.

The prototype for puts() is

     int puts(const char *s);

In early versions of C, right up through C90, if you used an undeclared 
identifier in a context where the name of a function was required,  the 
compiler would implicitly declare a function with that identifier as 
it's name, taking arguments of the types that you passed to it, and 
returning an 'int'. As you can see, that implicit declaration would 
match puts() exactly. The code you're looking at was probably written to 
rely upon this (mis)feature.

"implicit int" was dropped in C90 - and good riddance! It simplified 
writing programs, but was extremely error prone.

[toc] | [prev] | [next] | [standalone]

#97664

On Monday, November 28, 2016 at 8:57:47 PM UTC+3, James R. Kuyper wrote:
> On 11/28/2016 12:26 PM, Alla _ wrote:
> > On Monday, November 28, 2016 at 7:21:07 PM UTC+3, Richard Heathfield wrote:
> ...
> >> Don't program randomly. When the compiler (or linker) complains, don't
> >> just make arbitrary changes until the problem goes away. Think about
> >> what the error message *means*, and use that opportunity to learn more
> >> about C.
> >>
> > Yes, exactly; that was not a random choice from my side; I have spent a while thinking why
> > the compiler was giving me that error message. I thought that as far as I use any standard functions,
> > like puts, or printf, etc, I need <stdio.h>,
> 
> Wrong. You're just guessing, which is what Richard is telling you to 
> stop doing. You happened to guess correctly for puts(), but the C 
> standard library has 29 different header files. <stdio.h> is one of the 
> most used, but it won't, for instance, provide any help if you want to 
> call cacos() or wctrans(), which require <complex.h> and <wctype.h>, 
> respectively.
> 
> Stop guessing. Until you've got the relevant headers memorized, always 
> check the documentation on any function you want to use, to find out 
> which header is needed. On unix systems, "man va_end", for instance, 
> will tell you that you need to #include <stdarg.h> to use the va_end macro.
> 
Thank you ) But, honestly, I didn't guess. I knew that puts is part of the 
standard library, but anyway I have checked it once again before including 
stdio header. Yes, I understand that there are numerous libraries and I have 
used a few of them ) But I do agree that I was confused initially. 

>   as in all other numerous little and bigger programs I have worked
> > with during this time. But I was frustrated by the fact that the original file (the one I have taken from the
> > net) did not have that header, and nothing was mentioned about it; and I didn't understand why the guy
> > who has created the code didn't face any issues when he compiled the program; as you have said,
> >  "Generally you don't have to worry about linking the standard library because the implementation pulls
> >  it in anyway."; well, in my case I have to link it  everywhere.
> 
> You're confusing #including a header with linking the library - again. 
> Those are two entirely different, though related, activities.
Yes, I have just posted my answer to the message Richard has posted - indeed, I have 
confused to verbs; I was wrong. Now I understand my mistake. Thank you, really. 
> 
> The prototype for puts() is
> 
>      int puts(const char *s);
> 
> In early versions of C, right up through C90, if you used an undeclared 
> identifier in a context where the name of a function was required,  the 
> compiler would implicitly declare a function with that identifier as 
> it's name, taking arguments of the types that you passed to it, and 
> returning an 'int'. As you can see, that implicit declaration would 
> match puts() exactly. The code you're looking at was probably written to 
> rely upon this (mis)feature.
> 
> "implicit int" was dropped in C90 - and good riddance! It simplified 
> writing programs, but was extremely error prone.

I see. Thank you very much )

[toc] | [prev] | [next] | [standalone]

#97668

On 28/11/16 18:10, Alla _ wrote:
> On Monday, November 28, 2016 at 8:57:47 PM UTC+3, James R. Kuyper wrote:
>> On 11/28/2016 12:26 PM, Alla _ wrote:
>>> On Monday, November 28, 2016 at 7:21:07 PM UTC+3, Richard Heathfield wrote:
>> ...
>>>> Don't program randomly. When the compiler (or linker) complains, don't
>>>> just make arbitrary changes until the problem goes away. Think about
>>>> what the error message *means*, and use that opportunity to learn more
>>>> about C.
>>>>
>>> Yes, exactly; that was not a random choice from my side; I have spent a while thinking why
>>> the compiler was giving me that error message. I thought that as far as I use any standard functions,
>>> like puts, or printf, etc, I need <stdio.h>,
>>
>> Wrong. You're just guessing, which is what Richard is telling you to
>> stop doing. You happened to guess correctly for puts(), but the C
>> standard library has 29 different header files. <stdio.h> is one of the
>> most used, but it won't, for instance, provide any help if you want to
>> call cacos() or wctrans(), which require <complex.h> and <wctype.h>,
>> respectively.
>>
>> Stop guessing. Until you've got the relevant headers memorized, always
>> check the documentation on any function you want to use, to find out
>> which header is needed. On unix systems, "man va_end", for instance,
>> will tell you that you need to #include <stdarg.h> to use the va_end macro.
>>
> Thank you ) But, honestly, I didn't guess. I knew that puts is part of the
> standard library, but anyway I have checked it once again before including
> stdio header. Yes, I understand that there are numerous libraries and I have
> used a few of them ) But I do agree that I was confused initially.

Numerous? You've used a few of them? Are you sure you're not talking 
about headers?

If you're talking about <stdio.h>, <string.h>, <stdlib.h>, <ctype.h>, 
etc, those are headers, not libraries.

If you think there are numerous standard libraries, perhaps you'd care 
to tell us what you think they are.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#97669

On Monday, November 28, 2016 at 9:13:27 PM UTC+3, Richard Heathfield wrote:
> On 28/11/16 18:10, Alla _ wrote:
> > On Monday, November 28, 2016 at 8:57:47 PM UTC+3, James R. Kuyper wrote:
> >> On 11/28/2016 12:26 PM, Alla _ wrote:
> >>> On Monday, November 28, 2016 at 7:21:07 PM UTC+3, Richard Heathfield wrote:
> >> ...
> >>>> Don't program randomly. When the compiler (or linker) complains, don't
> >>>> just make arbitrary changes until the problem goes away. Think about
> >>>> what the error message *means*, and use that opportunity to learn more
> >>>> about C.
> >>>>
> >>> Yes, exactly; that was not a random choice from my side; I have spent a while thinking why
> >>> the compiler was giving me that error message. I thought that as far as I use any standard functions,
> >>> like puts, or printf, etc, I need <stdio.h>,
> >>
> >> Wrong. You're just guessing, which is what Richard is telling you to
> >> stop doing. You happened to guess correctly for puts(), but the C
> >> standard library has 29 different header files. <stdio.h> is one of the
> >> most used, but it won't, for instance, provide any help if you want to
> >> call cacos() or wctrans(), which require <complex.h> and <wctype.h>,
> >> respectively.
> >>
> >> Stop guessing. Until you've got the relevant headers memorized, always
> >> check the documentation on any function you want to use, to find out
> >> which header is needed. On unix systems, "man va_end", for instance,
> >> will tell you that you need to #include <stdarg.h> to use the va_end macro.
> >>
> > Thank you ) But, honestly, I didn't guess. I knew that puts is part of the
> > standard library, but anyway I have checked it once again before including
> > stdio header. Yes, I understand that there are numerous libraries and I have
> > used a few of them ) But I do agree that I was confused initially.
> 
> Numerous? You've used a few of them? Are you sure you're not talking 
> about headers?
> 
> If you're talking about <stdio.h>, <string.h>, <stdlib.h>, <ctype.h>, 
> etc, those are headers, not libraries.
> 
That was a clear and obvious typo this time - headers, definitely headers, not libraries. 
I am not confusing one with another anymore, as well as two verbs "link" and "include" )

> If you think there are numerous standard libraries, perhaps you'd care 
> to tell us what you think they are.
> 
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#97670

On 11/28/2016 01:10 PM, Alla _ wrote:
> On Monday, November 28, 2016 at 8:57:47 PM UTC+3, James R. Kuyper wrote:
...
>> Stop guessing. Until you've got the relevant headers memorized, always
>> check the documentation on any function you want to use, to find out
>> which header is needed. On unix systems, "man va_end", for instance,
>> will tell you that you need to #include <stdarg.h> to use the va_end macro.
>>
> Thank you ) But, honestly, I didn't guess. I knew that puts is part of the
> standard library, but anyway I have checked it once again before including
> stdio header.

You've missed the point. Being in the C standard library is not 
sufficient to make <stdio.h> the right header. Other parts of the C 
standard library are described by 28 other headers, and one of those 
other headers might be the one you need.

> ... Yes, I understand that there are numerous libraries and I have

This isn't about different libraries. <ctype.h>, <signal.h> and 
<wchar.h> are three different headers that all describe different parts 
of the same library. If you try to use isdigit(), raise(), or 
wcsrtombs(), adding <stdio.h> won't help you, even though those are all 
C standard library functions.

[toc] | [prev] | [next] | [standalone]

#97672

On Monday, November 28, 2016 at 9:19:59 PM UTC+3, James R. Kuyper wrote:
> On 11/28/2016 01:10 PM, Alla _ wrote:
> > On Monday, November 28, 2016 at 8:57:47 PM UTC+3, James R. Kuyper wrote:
> ...
> >> Stop guessing. Until you've got the relevant headers memorized, always
> >> check the documentation on any function you want to use, to find out
> >> which header is needed. On unix systems, "man va_end", for instance,
> >> will tell you that you need to #include <stdarg.h> to use the va_end macro.
> >>
> > Thank you ) But, honestly, I didn't guess. I knew that puts is part of the
> > standard library, but anyway I have checked it once again before including
> > stdio header.
> 
> You've missed the point. Being in the C standard library is not 
> sufficient to make <stdio.h> the right header. Other parts of the C 
> standard library are described by 28 other headers, and one of those 
> other headers might be the one you need.
> 
> > ... Yes, I understand that there are numerous libraries and I have
> 
> This isn't about different libraries. <ctype.h>, <signal.h> and 
> <wchar.h> are three different headers that all describe different parts 
> of the same library. If you try to use isdigit(), raise(), or 
> wcsrtombs(), adding <stdio.h> won't help you, even though those are all 
> C standard library functions.

Thank you very much! I hope my confusion is finally eliminated. 

[toc] | [prev] | [next] | [standalone]

#98754

On Mon, 28 Nov 2016 12:57:39 -0500, "James R. Kuyper"
<jameskuyper@verizon.net> wrote:
<snip>
> You're confusing #including a header with linking the library - again. 
> Those are two entirely different, though related, activities.
> 
> The prototype for puts() is
> 
>      int puts(const char *s);
> 
> In early versions of C, right up through C90, if you used an undeclared 
> identifier in a context where the name of a function was required,  the 
> compiler would implicitly declare a function with that identifier as 
> it's name, taking arguments of the types that you passed to it, and 
> returning an 'int'. As you can see, that implicit declaration would 
> match puts() exactly. The code you're looking at was probably written to 
> rely upon this (mis)feature.
> 
> "implicit int" was dropped in C90 - and good riddance! It simplified 
> writing programs, but was extremely error prone.

"Implicit int" (on a declaration that was written but had no type
specifier(s)) and "implicit function" (where no declaration was
written at all) were different though similar features and BOTH were
dropped in C99 (not C90). 

And as a nitpick, the implicit function declaration was as taking
_unspecified default-argument-promoted aka K&R1 arguments_ 
and returning int.

[toc] | [prev] | [next] | [standalone]

#97632

On 28/11/16 10:41, Alla _ wrote:
> Hello!
>
> I have an issue with a very simple test code (downloaded from net): the compiler shows an error
> message,

No, it's the linker that shows the error message. The compiler converts 
the code from C into relocatable object code, and the linker's job is to 
join together the object code of all the modules and libraries to make 
an executable program.

> which usually would indicate (at least this what I managed to learn about his error message)
> that I have not added a correct library

That would be one explanation, but it isn't the correct one on this 
occasion. You forgot to tell the linker that you have /two/ object files.

> Undefined symbols for architecture x86_64:
>   "_function1", referenced from:
>       _main in 02_01-18ac0b.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>
> Originally both the header and the .c file, which defines functions in the header file, didn't have an #include <stdio.h> line; the compiler displayed the above error message. Haven't found any mistake, I have added the stdio.h library, but the compiler still displays the same error message. I don't
> understand why the header is not being linked.

Headers are included, not linked.

Translation occurs in a number of distinct phases. There are actually 
quite a few phases, but they can be summarised as:

i) pre-processing - the removal of comments, the inclusion of headers, 
the expansion of macros;
ii) compilation - turning the resulting code from C into an object format;
iii) linking - the joining together of object code generated from your 
sources and the object code stored in libraries to form an executable 
program.

>
> (1) a program:

You haven't given us the name, so I'll call it allax.c

>     #include <stdio.h>			
>     #include <stdlib.h>
>
>     #include "myLibrary.h"		
>
>    #define MAX_LENGTH 21.8
>    #define WORK_WEEK  5
>
>    int main(void) {
> 	function1();
> 	return EXIT_SUCCESS;
>   }
>
> (2) header file:

I deduce that this is called mylibrary.h - which is a lousy name for a 
header, but never mind that.

>
>  #include <stdio.h> /** wasn't in the original file, added by me**/
>
> #ifndef MYLIBRARY_H_
> #define MYLIBRARY_H_
>
> void function1(void);
> void function2(void);
>
> #endif /* MYLIBRARY_H_ */
>
> (3)

Another C module the name of which you haven't shared. I'll call it allay.c

> #include <stdio.h>  /** wasn't in the original file, added by me**/

You should add:

#include "mylibrary.h"

Thought for the day: WHY should you add it? (And would everybody else 
who already knows the answer PLEASE let Alla think this one through for 
herself!)

>
> void function1(void){
> 	puts("It works :)\n");
> }
>
> void function2(void){
> 	//This function does nothing as well
> }

Step by step:

gcc -c -o allax.o allax.c # compile the first file
gcc -c -o allay.o allay.c # compile the second file
gcc -o alla allax.o allay.o # link them together

-c means "just compile, don't try to link"
-o means "the next arg is the name in which to store the output"

(gcc can tell the difference between C source and object files, so you 
don't have to tell it, in the third step, not to bother compiling the .o 
files.)

You'd rather do it all in one go? Like this:

gcc -o alla allax.c allay.c

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web