🚀 go-pugleaf

frank wrote:
> I'm replicating a program provided by Richard Heathfield in _C 
> Unleashed_.  The custom header for this project is in the same directory 
> as the source:
> 
> dan@dan-desktop:~/source/unleashed/ch11$ ls -l
> 
> -rw-r--r-- 1 dan dan  1612 2000-06-08 16:13 strarr.h
> 
> dan@dan-desktop:~/source/unleashed/ch11$
> 
> When I compile with -v, this is what I see:
> 
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>  /usr/lib/gcc/i486-linux-gnu/4.3.3/include
>  /usr/lib/gcc/i486-linux-gnu/4.3.3/include-fixed
>  /usr/include
> End of search list.
> 
> On compilation, I get errors that indicate that gcc is not finding the 
> header:
> dan@dan-desktop:~/source/unleashed/ch11$  gcc -std=c99 -Wall -Wextra 
> t1.c -o out/tmp/ccmpPiuM.o: In function `ReadFile':
> t1.c:(.text+0x7e): undefined reference to `AllocStrArray'
> t1.c:(.text+0x147): undefined reference to `AddRowsToStrArray'
> t1.c:(.text+0x187): undefined reference to `ResizeOneString'
> t1.c:(.text+0x203): undefined reference to `AddRowsToStrArray'
> t1.c:(.text+0x246): undefined reference to `FreeStrArray'
> t1.c:(.text+0x269): undefined reference to `ConsolidateStrArray'
> /tmp/ccmpPiuM.o: In function `main':
> t1.c:(.text+0x322): undefined reference to `FreeStrArray'
> collect2: ld returned 1 exit status
> dan@dan-desktop:~/source/unleashed/ch11$
> 
> So it doesn't find a header in the same directory.  So, I decide to put 
> the header where gcc *is* looking, but ubuntu won't let me put a header 
> in any of the directories that are included in the search.
> 
> Question 1:  Where am I supposed to put home-rolled headers when I 
> compile with gcc on ubuntu?
> 
> Thanks for your comment.

Dear franck,

what's missing is not the header but the symbols at link time. You 
should probably link with a .a or .so file that comes with your header file.

Yann

frank schrieb:
> I'm replicating a program provided by Richard Heathfield in _C
> Unleashed_.  The custom header for this project is in the same directory
> as the source:
> 
> dan@dan-desktop:~/source/unleashed/ch11$ ls -l
> 
> -rw-r--r-- 1 dan dan  1612 2000-06-08 16:13 strarr.h
> 
> dan@dan-desktop:~/source/unleashed/ch11$
> 
> When I compile with -v, this is what I see:
> 
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>  /usr/lib/gcc/i486-linux-gnu/4.3.3/include
>  /usr/lib/gcc/i486-linux-gnu/4.3.3/include-fixed
>  /usr/include
> End of search list.
> 
> On compilation, I get errors that indicate that gcc is not finding the
> header:
> dan@dan-desktop:~/source/unleashed/ch11$  gcc -std=c99 -Wall -Wextra
> t1.c -o out/tmp/ccmpPiuM.o: In function `ReadFile':
> t1.c:(.text+0x7e): undefined reference to `AllocStrArray'
> t1.c:(.text+0x147): undefined reference to `AddRowsToStrArray'
> t1.c:(.text+0x187): undefined reference to `ResizeOneString'
> t1.c:(.text+0x203): undefined reference to `AddRowsToStrArray'
> t1.c:(.text+0x246): undefined reference to `FreeStrArray'
> t1.c:(.text+0x269): undefined reference to `ConsolidateStrArray'
> /tmp/ccmpPiuM.o: In function `main':
> t1.c:(.text+0x322): undefined reference to `FreeStrArray'
> collect2: ld returned 1 exit status
> dan@dan-desktop:~/source/unleashed/ch11$
> 
> So it doesn't find a header in the same directory.

These are not messages from gcc not finding a header, these are messages from
the linker ("ld returned 1 exit status"). When you header contains more than
just a bunch of defines and datatypes, you need the coresponding object files
where the compiled code of the defined functions reside. Either as object files
(.o), archive (.a) or shared library (.so).
You have to pass them on the link line. Please look at the Manual for the
options -L and -l (for .o's you need no options).

Look around in your Ubuntu System, you have /usr/include, a bunch of system
header files (text only), and /usr/lib, where the librarys for the system libs
reside (the binaries).
Where you put your project stuff, thats up to you. As long as your project is
not part of the installed System, it has no business in writing to the system paths.

Maybe before you "unleash" C, you want to read a tutorial on how building
software under Unix works (or more concrete the classic multipart C stack:
preprocessor, compiler, assembler, linker), because you just ran into the "what?
a header is not the complete lib"-FAQ

> So, I decide to put
> the header where gcc *is* looking, but ubuntu won't let me put a header
> in any of the directories that are included in the search.
> 

Because these are system directories, you need the right permission to do so.
Something with "sudo cp ..."

> Question 1:  Where am I supposed to put home-rolled headers when I
> compile with gcc on ubuntu?
> 

Right beside the rest of your project, no need to put them somewhere else.

> Thanks for your comment.
Greetings
	Jan

-- 
Fun things to slip into your budged:
Traffic shaping on the loopback interface

BJ wrote:
> On Wed, 20 Jan 2010 10:02:04 -0700, frank <frank@example.invalid> wrote:
> 
>> I'm replicating a program provided by Richard Heathfield in _C 
>> Unleashed_.  The custom header for this project is in the same directory 
>> as the source:
>>
>> dan@dan-desktop:~/source/unleashed/ch11$ ls -l
>>
>> -rw-r--r-- 1 dan dan  1612 2000-06-08 16:13 strarr.h
>>
>> dan@dan-desktop:~/source/unleashed/ch11$
>>
>> When I compile with -v, this is what I see:
>>
>> #include "..." search starts here:
>> #include <...> search starts here:
>>  /usr/local/include
>>  /usr/lib/gcc/i486-linux-gnu/4.3.3/include
>>  /usr/lib/gcc/i486-linux-gnu/4.3.3/include-fixed
>>  /usr/include
>> End of search list.
>>
>> On compilation, I get errors that indicate that gcc is not finding the 
>> header:
>> dan@dan-desktop:~/source/unleashed/ch11$  gcc -std=c99 -Wall -Wextra 
>> t1.c -o out/tmp/ccmpPiuM.o: In function `ReadFile':
>> t1.c:(.text+0x7e): undefined reference to `AllocStrArray'
>> t1.c:(.text+0x147): undefined reference to `AddRowsToStrArray'
>> t1.c:(.text+0x187): undefined reference to `ResizeOneString'
>> t1.c:(.text+0x203): undefined reference to `AddRowsToStrArray'
>> t1.c:(.text+0x246): undefined reference to `FreeStrArray'
>> t1.c:(.text+0x269): undefined reference to `ConsolidateStrArray'
>> /tmp/ccmpPiuM.o: In function `main':
>> t1.c:(.text+0x322): undefined reference to `FreeStrArray'
>> collect2: ld returned 1 exit status
>> dan@dan-desktop:~/source/unleashed/ch11$
>>
>> So it doesn't find a header in the same directory.  So, I decide to put 
>> the header where gcc *is* looking, but ubuntu won't let me put a header 
>> in any of the directories that are included in the search.
>>
>> Question 1:  Where am I supposed to put home-rolled headers when I 
>> compile with gcc on ubuntu?
>>
>> Thanks for your comment.
> 
> The previous responses looked good to me, but there is information
> missing in your post.
> 
> We generally put our own headers in the same directory as the rest of
> the source code. The include statement should enclose the file name in
> quotes, which tells the compiler to look for the file in the source
> directory. System supplied headers are enclosed in <> (guillemets). This
> tells the compiler to look in the gcc include directory.
> 
> Is there a .cpp or .c file with the same name as the header? It should
> also be in the source directory. If it exists it should be compiled
> along with your other .cpp or .c files. If it doesn't exist, but there
> exists a file with the same name as the header file, but with a .o or
> .so extension, see the previous posts.
> 
> BJ
> Barry Jones

Thanks all for responses.  I was missing a source file with the 
definitions of the functions that the linker couldn't find.  Having the 
header right there next to the caller wasn't a problem for gcc.

So I was misunderstanding what gcc was telling me.  As long as I'm 
talking about messages I don't understand from gcc, what about:


> dan@dan-desktop:~/source$ gcc -std=c99 -Wall -Wextra rd2.c -o out; ./out
> rd2.c: In function �process_directory�:
> rd2.c:40: warning: implicit declaration of function �readdir_r�
> rd2.c:48: warning: implicit declaration of function �lstat�
> rd2.c:66: warning: implicit declaration of function �readlink�
> dan@dan-desktop:~/source$ 

( I can only paste as quotation.  What a pain.), when I have the right 
headers included:
> #include <stdio.h>
> #include <stdlib.h>
> #include <errno.h>
> #include <string.h>
> #include <limits.h>
> 
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <dirent.h>
> #include <unistd.h>

It links and behaves fine.
-- 
frank

Jan Seiffert wrote:

> These are not messages from gcc not finding a header, these are messages from
> the linker ("ld returned 1 exit status"). When you header contains more than
> just a bunch of defines and datatypes, you need the coresponding object files
> where the compiled code of the defined functions reside. Either as object files
> (.o), archive (.a) or shared library (.so).
> You have to pass them on the link line. Please look at the Manual for the
> options -L and -l (for .o's you need no options).
> 
> Look around in your Ubuntu System, you have /usr/include, a bunch of system
> header files (text only), and /usr/lib, where the librarys for the system libs
> reside (the binaries).
> Where you put your project stuff, thats up to you. As long as your project is
> not part of the installed System, it has no business in writing to the system paths.
> 
> Maybe before you "unleash" C, you want to read a tutorial on how building
> software under Unix works (or more concrete the classic multipart C stack:
> preprocessor, compiler, assembler, linker), because you just ran into the "what?
> a header is not the complete lib"-FAQ
> 
>> So, I decide to put
>> the header where gcc *is* looking, but ubuntu won't let me put a header
>> in any of the directories that are included in the search.
>>
> 
> Because these are system directories, you need the right permission to do so.
> Something with "sudo cp ..."
> 
>> Question 1:  Where am I supposed to put home-rolled headers when I
>> compile with gcc on ubuntu?
>>
> 
> Right beside the rest of your project, no need to put them somewhere else.


Thanks, Jan, everything you write here is correct and helpful.
-- 
frank

Yann Renard wrote:

> Dear franck,
> 
> what's missing is not the header but the symbols at link time. You 
> should probably link with a .a or .so file that comes with your header 
> file.
> 
> Yann

Thanks, Yann, the linker couldn't find find the symbols of the file I 
had yet to add to the project.
-- 
frank

In article <7rshd7Fa3vU1@mid.individual.net>,
frank  <frank@example.invalid> wrote:
>> dan@dan-desktop:~/source$ gcc -std=c99 -Wall -Wextra rd2.c -o out; ./out
>> rd2.c: In function �process_directory�:
>> rd2.c:40: warning: implicit declaration of function �readdir_r�
>> rd2.c:48: warning: implicit declaration of function �lstat�
>> rd2.c:66: warning: implicit declaration of function �readlink�
>> dan@dan-desktop:~/source$ 
>

Every one of those functions has a "Feature Test Macro Requirements for
glibc" note in the SYNOPSIS section of its man page. (If not, get some newer
man pages.) Read those. Read the feature_test_macros(7) man page. Then add
the necessary -D options to activate the set of features you want. WIth
-std=c99 and no other feature-enabling macros defined, you get only the
functions that are actually part of C99.

The quick way to enable just about everything is -D_GNU_SOURCE

-- 
Alan Curry

Alan Curry wrote:
> In article <7rshd7Fa3vU1@mid.individual.net>,
> frank  <frank@example.invalid> wrote:
>>> dan@dan-desktop:~/source$ gcc -std=c99 -Wall -Wextra rd2.c -o out; ./out
>>> rd2.c: In function �process_directory�:
>>> rd2.c:40: warning: implicit declaration of function �readdir_r�
>>> rd2.c:48: warning: implicit declaration of function �lstat�
>>> rd2.c:66: warning: implicit declaration of function �readlink�
>>> dan@dan-desktop:~/source$ 
> 
> Every one of those functions has a "Feature Test Macro Requirements for
> glibc" note in the SYNOPSIS section of its man page. (If not, get some newer
> man pages.) Read those. Read the feature_test_macros(7) man page. Then add
> the necessary -D options to activate the set of features you want. WIth
> -std=c99 and no other feature-enabling macros defined, you get only the
> functions that are actually part of C99.
> 
> The quick way to enable just about everything is -D_GNU_SOURCE
> 

Bravo, Alan, you're always a clutch hitter.  I decided that I would use 
that in place of specifying a c standard, because I'm intentionally 
going to do things aren't defined by standard C as opposed to posix.

Given this intention, would you say this is an appropriate compile 
command line:

dan@dan-desktop:~/source$ gcc -D_GNU_SOURCE -Wall -Wextra rd3.c -o out

?  I'm not sure where I picked up -Wall and -Wextra.  Are they both 
still useful?

-- 
frank

frank <frank@example.invalid> writes:
[...]
> Given this intention, would you say this is an appropriate compile
> command line:
>
> dan@dan-desktop:~/source$ gcc -D_GNU_SOURCE -Wall -Wextra rd3.c -o out
>
> ?  I'm not sure where I picked up -Wall and -Wextra.  Are they both
> still useful?

I'm not going to comment on the -D_GNU_SOURCE portion of this (due to
a lack of expertise), but I will say something about the "-o".

When compiling and linking a source file "foo.c" to create an
executable, the convention is to call the executable "foo":

    gcc ... foo.c -o foo

(It might be something like "foo.exe" on non-Unix-like systems.)

When compiling a source file "foo.c" to create an object file without
linking, the convention is to call the object file "foo.o":

    gcc -c ... foo.c -o foo.o

or just:

    gcc -c ... foo.c

since "foo.o" is the default output name.

You are of course free to call your output files whatever you like,
but I suggest following these conventions unless you have a good
reason not to.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:
> frank <frank@example.invalid> writes:
> [...]
>> Given this intention, would you say this is an appropriate compile
>> command line:
>>
>> dan@dan-desktop:~/source$ gcc -D_GNU_SOURCE -Wall -Wextra rd3.c -o out
>>
>> ?  I'm not sure where I picked up -Wall and -Wextra.  Are they both
>> still useful?
> 
> I'm not going to comment on the -D_GNU_SOURCE portion of this (due to
> a lack of expertise), but I will say something about the "-o".
> 
> When compiling and linking a source file "foo.c" to create an
> executable, the convention is to call the executable "foo":
> 
>     gcc ... foo.c -o foo
> 
> (It might be something like "foo.exe" on non-Unix-like systems.)
> 
> When compiling a source file "foo.c" to create an object file without
> linking, the convention is to call the object file "foo.o":
> 
>     gcc -c ... foo.c -o foo.o
> 
> or just:
> 
>     gcc -c ... foo.c
> 
> since "foo.o" is the default output name.
> 
> You are of course free to call your output files whatever you like,
> but I suggest following these conventions unless you have a good
> reason not to.
> 

Added to my linuxlog.
--