(fwd) .so, .a and .o-files

(fwd) .so, .a and .o-files

[Axel Siebenwirth]

Sorry, I haven't seen my mail get to the list. So here goes it again.

----- Forwarded message from Axel Siebenwirth <axel@hh59.org> -----

Hi,

I have some stupid questions.

What makes the difference between .o and .so files? What is their use? Is it
just a naming convention?

When I want to link libraries to a program I am compiling, of what format do 
the libraries have to be?

I have found out that .a files are archives created with ar. What is that
for?

Many thanks and my best regards,
Axel Siebenwirth

----- End forwarded message -----
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: (fwd) .so, .a and .o-files

[Ray Olszewski]

If you have not seen your mail on the list, then almost certainly something 
is wrong at your end. This is the *third* time I have seen this message 
this morning.

Are you sure you are subscribed?

Might your MTA or MUA be filtering out messages that are From: your own 
address?

At 05:34 PM 8/15/02 +0200, Axel Siebenwirth wrote:
>Sorry, I haven't seen my mail get to the list. So here goes it again.
>
>----- Forwarded message from Axel Siebenwirth <axel@hh59.org> -----
>
>Hi,
>
>I have some stupid questions.
>
>What makes the difference between .o and .so files? What is their use? Is it
>just a naming convention?

.o is an object file. It represents the intermediate step in the 
compile-and-link process for a program. .so is a shared object file (i.e., 
a library); their linking (at runtime) is managed by ld.so .

I'm not sure if the naming differences are actually required or if the use 
of .so is a naming convention (not "juet" a naming convention, though, 
since if it is one, it is well established, hence important).

>When I want to link libraries to a program I am compiling, of what format do
>the libraries have to be?

Depends on how you link. Modern linking is done dynamically (only one copy 
of the library is loaded into memory and shared by all apps that use it), 
using .so libraries. Older linking was done statically (each app loaded its 
own personal copy of the library into memory), using .a libraries.

Of course, you need the appropriate header files in /usr/include to do 
either of these things. How to get them depends on which Linux distro you 
use; in Debian, most every library_package_name.deb has a corresponding 
library_package_name-dev.deb with the needed headers.

>I have found out that .a files are archives created with ar. What is that
>for?

It's been so long since I used a .a libraries, I didn't recall how they 
were created. They are the old-format libraries I referred to above. They 
are kept around, at least on full-size Linux installs, mainly for legacy 
reasons. Don't use them unless you have *very* unusual requirements (I 
can't even think of an example).

>Many thanks and my best regards,
>Axel Siebenwirth




--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: (fwd) .so, .a and .o-files

[lawson_whitney]

On Thu, 15 Aug 2002, Ray Olszewski wrote:

> It's been so long since I used a .a libraries, I didn't recall how they
> were created. They are the old-format libraries I referred to above. They
> are kept around, at least on full-size Linux installs, mainly for legacy
> reasons. Don't use them unless you have *very* unusual requirements (I
> can't even think of an example).

In case you want to make a static executable (one that does not require
dynamic linking.  Nost distro's link /sbin/ldconfig static so you can
use it to recover when you mess up your libraries and nothing woorks,
say when you try to upgrade libc and don't know how.

Some distros keep a /bin/ash.static or other small shell for use in
rescue root floppies and initrd images.

>
> >Many thanks and my best regards,
> >Axel Siebenwirth
>
> -------------------------------------------"Never tell me the odds!"--------
> Ray Olszewski					-- Han Solo
> Palo Alto, California, USA			  ray@comarre.com
> -------------------------------------------------------------------------------

Lawson
---oops---



________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/web/.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: (fwd) .so, .a and .o-files

[Ray Olszewski]

At 12:17 PM 8/15/02 -0400, lawson_whitney@juno.com wrote:
>On Thu, 15 Aug 2002, Ray Olszewski wrote:
>
> > It's been so long since I used a .a libraries, I didn't recall how they
> > were created. They are the old-format libraries I referred to above. They
> > are kept around, at least on full-size Linux installs, mainly for legacy
> > reasons. Don't use them unless you have *very* unusual requirements (I
> > can't even think of an example).
>
>In case you want to make a static executable (one that does not require
>dynamic linking.  Nost distro's link /sbin/ldconfig static so you can
>use it to recover when you mess up your libraries and nothing woorks,
>say when you try to upgrade libc and don't know how.

I don't really want to argue with you, Lawson, but I do want to ask how 
certain you are of this interpretation. "static" is a word that means 
different things in different contexts, and I think you and I may have 
crossed two of its meanings.

The ld option "--static" links in an actual copy of any needed library code 
to the executable during linking (instead of at runtime, via ld.so). But 
does ld use (or need) .a libraries to do this? Or does it just override the 
normal (dymanic) use of the .so libraries? I'd always assumed the latter.

While the man page for ld doesn't clear this up, the Makefile for busybox 
includes a static option (for the exact reason you suggest above -- it's 
basically a rescue-disk app), but its docs only mention compiling against 
glibc, uClibc, and libc5, with no explicit mention of .a libraries.

I could easily be the one here who is mixed up. But we should get it clear 
and correct on the list to protect the innocent victims, no?


--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: (fwd) .so, .a and .o-files

[lawson_whitney]

On Thu, 15 Aug 2002, Ray Olszewski wrote:

> At 12:17 PM 8/15/02 -0400, lawson_whitney@juno.com wrote:
> >
> >In case you want to make a static executable (one that does not require
> >dynamic linking.  Nost distro's link /sbin/ldconfig static so you can
> >use it to recover when you mess up your libraries and nothing woorks,
> >say when you try to upgrade libc and don't know how.
>
> I don't really want to argue with you, Lawson, but I do want to ask how
> certain you are of this interpretation. "static" is a word that means
> different things in different contexts, and I think you and I may have
> crossed two of its meanings.
>
No, I mean the same by static as you do, if I understand you aright.

> The ld option "--static" links in an actual copy of any needed library code
> to the executable during linking (instead of at runtime, via ld.so). But
> does ld use (or need) .a libraries to do this? Or does it just override the
> normal (dymanic) use of the .so libraries? I'd always assumed the latter.
>
The way I read the section of info ld on the subject, you need .a
libraries to make a static executable.

File: ld.info,  Node: Options,  Next: Environment,  Up: Invocation

`-Bdynamic'
`-dy'
`-call_shared'
     Link against dynamic libraries.  This is only meaningful on
     platforms for which shared libraries are supported.  This option
     is normally the default on such platforms.  The different variants
     of this option are for compatibility with various systems.  You
     may use this option multiple times on the command line: it affects
     library searching for `-l' options which follow it.

`-Bstatic'
`-dn'
`-non_shared'
`-static'
     Do not link against shared libraries.  This is only meaningful on
     platforms for which shared libraries are supported.  The different
     variants of this option are for compatibility with various
     systems.  You may use this option multiple times on the command
     line: it affects library searching for `-l' options which follow
     it.
Viewing line 503/1103, 45%

> While the man page for ld doesn't clear this up, the Makefile for busybox
> includes a static option (for the exact reason you suggest above -- it's
> basically a rescue-disk app), but its docs only mention compiling against
> glibc, uClibc, and libc5, with no explicit mention of .a libraries.

I bet you can find libc.a in the glibc-dev package, along with a
/usr/lib/libc.so that reads as follows:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
>
> I could easily be the one here who is mixed up. But we should get it clear
> and correct on the list to protect the innocent victims, no?
>
I'm not the sort to start an argument I can't win.

> -------------------------------------------"Never tell me the odds!"--------
> Ray Olszewski					-- Han Solo
> Palo Alto, California, USA			  ray@comarre.com
> -------------------------------------------------------------------------------
>
Lawson

No offense meant.



________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/web/.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Axel Siebenwirth]

Hi Ray!

On Thu, 15 Aug 2002, Ray Olszewski wrote:

> .o is an object file. It represents the intermediate step in the 
> compile-and-link process for a program. .so is a shared object file (i.e., 
> a library); their linking (at runtime) is managed by ld.so .

Ok. So I compile from sources many .o's and link them together into an .so
and I have a shared library.

> Depends on how you link. Modern linking is done dynamically (only one copy 
> of the library is loaded into memory and shared by all apps that use it), 
> using .so libraries. Older linking was done statically (each app loaded its 
> own personal copy of the library into memory), using .a libraries.

I figured out that when a program is statically linked, the libraries are in
the executable itself so no additional libraries are required...?

Regards,
Axel
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Axel Siebenwirth]

Hi Ray!

What is the difference between the linking that gcc does i.e. to link many
object files into an executable and  the linking that ld does?
Is it really that gcc is just to link object files together to an executable
and ld is there to link object files to an shared library?

Thank you,
Axel
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Ray Olszewski]

At 07:25 PM 8/15/02 +0200, Axel Siebenwirth wrote:
>Hi Ray!
>
>What is the difference between the linking that gcc does i.e. to link many
>object files into an executable and  the linking that ld does?
>Is it really that gcc is just to link object files together to an executable
>and ld is there to link object files to an shared library?


gcc compiles; it does not link. It calls ld to link. ld  links multiple .o 
files into an executable that includes the hooks to use the shared-library 
functions. Then at runtime, ld.so does the runtime linking to the .so files.



--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Axel Siebenwirth]

Hi Ray!

On Thu, 15 Aug 2002, Ray Olszewski wrote:

> Depends on how you link. Modern linking is done dynamically (only one copy 
> of the library is loaded into memory and shared by all apps that use it), 
> using .so libraries. Older linking was done statically (each app loaded its 
> own personal copy of the library into memory), using .a libraries.

Does this mean what I think? that when an executable is linked statically
all the libraries are in the executable? So none of the required libraries
are required when executing?

Is there a difference between statically linking object files to a library
and statically linking libraries to an executable?
I'm really sorry about such fundamental questions but I want to get
clarity about all that.

Thank you very much and my best regards,
Axel Siebenwirth
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Ray Olszewski]

As I indicated in my message to Lawson, "static" is a tricky term, with an 
assortment of context-dependent meanings. It is messy enough that you 
should take what I write next with a grain of salt, since it is easy to get 
mixed up here.

Both .a and .so libraries get linked at runtime. .a linking was called 
static, but not in the sense you mean (at least as best I can recall). In 
that context, static meant that a dedicated copy of the needed library was 
loaded into memory and used just with that process. The .so approach was an 
improbvement on this runtime linking, loading just one copy of the library 
memory into memory and sharing it among all the processes that need those 
routines.

But when the linker ld is used with the --static option, an actual copy of 
any needed library function is incorporated into the executable, allowing 
it to run standalone (without access to the .so libraries).

At 07:31 PM 8/15/02 +0200, Axel Siebenwirth wrote:
>Hi Ray!
>
>On Thu, 15 Aug 2002, Ray Olszewski wrote:
>
> > Depends on how you link. Modern linking is done dynamically (only one copy
> > of the library is loaded into memory and shared by all apps that use it),
> > using .so libraries. Older linking was done statically (each app loaded 
> its
> > own personal copy of the library into memory), using .a libraries.
>
>Does this mean what I think? that when an executable is linked statically
>all the libraries are in the executable? So none of the required libraries
>are required when executing?
>
>Is there a difference between statically linking object files to a library
>and statically linking libraries to an executable?
>I'm really sorry about such fundamental questions but I want to get
>clarity about all that.


--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[lawson_whitney]

On Thu, 15 Aug 2002, Ray Olszewski wrote:

> As I indicated in my message to Lawson, "static" is a tricky term, with an
> assortment of context-dependent meanings. It is messy enough that you
> should take what I write next with a grain of salt, since it is easy to get
> mixed up here.
>
> Both .a and .so libraries get linked at runtime. .a linking was called
> static, but not in the sense you mean (at least as best I can recall). In
> that context, static meant that a dedicated copy of the needed library was
> loaded into memory and used just with that process. The .so approach was an
> improbvement on this runtime linking, loading just one copy of the library
> memory into memory and sharing it among all the processes that need those
> routines.

IIRC, it was possible but difficult to make a shared .a library: each
shared library had to have the same dedicated address range in every
address space.  I don't think anybody does this any more.

ELF (.so) libraries are relocatable at runtime.

> But when the linker ld is used with the --static option, an actual copy of
> any needed library function is incorporated into the executable, allowing
> it to run standalone (without access to the .so libraries).
>
Exactly.

Lawson
---oops---



________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/web/.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Axel Siebenwirth]

Originally to: All


Hi Ray!

On Thu, 15 Aug 2002, Ray Olszewski wrote:

> Depends on how you link. Modern linking is done dynamically (only one copy 
> of the library is loaded into memory and shared by all apps that use it), 
> using .so libraries. Older linking was done statically (each app loaded its 
> own personal copy of the library into memory), using .a libraries.

Does this mean what I think? that when an executable is linked statically
all the libraries are in the executable? So none of the required libraries
are required when executing?

Is there a difference between statically linking object files to a library
and statically linking libraries to an executable?
I'm really sorry about such fundamental questions but I want to get
clarity about all that.

Thank you very much and my best regards,
Axel Siebenwirth
-

<-> Gateway Information.
This message originated from a Fidonet System (http://www.fidonet.org)
and was gated at TCOB1 (http://www.tcob1.net)
Please do not respond direct to this message but via the list


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Axel Siebenwirth]

Originally to: All


Hi Ray!

What is the difference between the linking that gcc does i.e. to link many
object files into an executable and  the linking that ld does?
Is it really that gcc is just to link object files together to an executable
and ld is there to link object files to an shared library?

Thank you,
Axel
-

<-> Gateway Information.
This message originated from a Fidonet System (http://www.fidonet.org)
and was gated at TCOB1 (http://www.tcob1.net)
Please do not respond direct to this message but via the list


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Axel Siebenwirth]

Originally to: All


Me again.

Whats the use of stripping object files of their symbols. Symbols reflect
the functions in an object file, right?

Axel
-

<-> Gateway Information.
This message originated from a Fidonet System (http://www.fidonet.org)
and was gated at TCOB1 (http://www.tcob1.net)
Please do not respond direct to this message but via the list


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

.so, .a and .o-files

[Axel Siebenwirth]

Originally to: All


Hi,

I have some stupid questions.

What makes the difference between .o and .so files? What is their use? Is it
just a naming convention?

When I want to link libraries to a program I am compiling, of what format do 
the libraries have to be?

I have found out that .a files are archives created with ar. What is that
for?

Many thanks and my best regards,
Axel Siebenwirth
-

<-> Gateway Information.
This message originated from a Fidonet System (http://www.fidonet.org)
and was gated at TCOB1 (http://www.tcob1.net)
Please do not respond direct to this message but via the list


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

.so, .a and .o-files

[Axel Siebenwirth]

Hi,

I have some stupid questions.

What makes the difference between .o and .so files? What is their use? Is it
just a naming convention?

When I want to link libraries to a program I am compiling, of what format do 
the libraries have to be?

I have found out that .a files are archives created with ar. What is that
for?

Many thanks and my best regards,
Axel Siebenwirth
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Axel Siebenwirth]

Me again.

Whats the use of stripping object files of their symbols. Symbols reflect
the functions in an object file, right?

Axel
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Axel Siebenwirth]

Me again.

Whats the use of stripping object files of their symbols. Symbols reflect
the functions in an object file, right?

Axel
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

.so, .a and .o-files

[Axel Siebenwirth]

Hi,

I have some stupid questions.

What makes the difference between .o and .so files? What is their use? Is it
just a naming convention?

When I want to link libraries to a program I am compiling, of what format do 
the libraries have to be?

I have found out that .a files are archives created with ar. What is that
for?

Many thanks and my best regards,
Axel Siebenwirth
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Ray Olszewski]

Originally to: All


At 07:25 PM 8/15/02 +0200, Axel Siebenwirth wrote:
>Hi Ray!
>
>What is the difference between the linking that gcc does i.e. to link many
>object files into an executable and  the linking that ld does?
>Is it really that gcc is just to link object files together to an executable
>and ld is there to link object files to an shared library?


gcc compiles; it does not link. It calls ld to link. ld  links multiple .o 
files into an executable that includes the hooks to use the shared-library 
functions. Then at runtime, ld.so does the runtime linking to the .so files.



--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-

<-> Gateway Information.
This message originated from a Fidonet System (http://www.fidonet.org)
and was gated at TCOB1 (http://www.tcob1.net)
Please do not respond direct to this message but via the list


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: .so, .a and .o-files

[Ray Olszewski]

Originally to: All


As I indicated in my message to Lawson, "static" is a tricky term, with an 
assortment of context-dependent meanings. It is messy enough that you 
should take what I write next with a grain of salt, since it is easy to get 
mixed up here.

Both .a and .so libraries get linked at runtime. .a linking was called 
static, but not in the sense you mean (at least as best I can recall). In 
that context, static meant that a dedicated copy of the needed library was 
loaded into memory and used just with that process. The .so approach was an 
improbvement on this runtime linking, loading just one copy of the library 
memory into memory and sharing it among all the processes that need those 
routines.

But when the linker ld is used with the --static option, an actual copy of 
any needed library function is incorporated into the executable, allowing 
it to run standalone (without access to the .so libraries).

At 07:31 PM 8/15/02 +0200, Axel Siebenwirth wrote:
>Hi Ray!
>
>On Thu, 15 Aug 2002, Ray Olszewski wrote:
>
> > Depends on how you link. Modern linking is done dynamically (only one copy
> > of the library is loaded into memory and shared by all apps that use it),
> > using .so libraries. Older linking was done statically (each app loaded 
> its
> > own personal copy of the library into memory), using .a libraries.
>
>Does this mean what I think? that when an executable is linked statically
>all the libraries are in the executable? So none of the required libraries
>are required when executing?
>
>Is there a difference between statically linking object files to a library
>and statically linking libraries to an executable?
>I'm really sorry about such fundamental questions but I want to get
>clarity about all that.


--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-

<-> Gateway Information.
This message originated from a Fidonet System (http://www.fidonet.org)
and was gated at TCOB1 (http://www.tcob1.net)
Please do not respond direct to this message but via the list


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs