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

Groups > comp.programming > #2883 > unrolled thread

.SO files

Back to article view | Back to comp.programming

Contents

  .SO files bob <bob@coolfone.comze.com> - 2013-01-22 07:00 -0800
    Re: .SO files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-22 15:26 +0000
    Re: .SO files "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2013-01-22 16:37 +0100
    Re: .SO files "BartC" <bc@freeuk.com> - 2013-01-22 17:42 +0000
      Re: .SO files Noob <root@127.0.0.1> - 2013-02-08 10:41 +0100
        Re: .SO files Robert Wessel <robertwessel2@yahoo.com> - 2013-02-08 04:13 -0600
        Re: .SO files "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2013-02-08 12:09 +0100
        Re: .SO files "BartC" <bc@freeuk.com> - 2013-02-08 18:13 +0000
          Re: .SO files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-02-08 21:20 +0000
            Re: .SO files "BartC" <bc@freeuk.com> - 2013-02-08 23:30 +0000
              Re: .SO files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-02-09 02:32 +0000
                Re: .SO files "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2013-02-09 09:27 +0100
                  Re: .SO files "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-02-09 10:09 +0000
                  Re: .SO files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-02-09 12:11 +0000
                    Re: .SO files "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2013-02-09 14:15 +0100
                  Re: .SO files "BartC" <bc@freeuk.com> - 2013-02-09 14:56 +0000
                    Re: .SO files clarcky297@gmail.com - 2013-02-13 07:30 -0800
                Re: .SO files "BartC" <bc@freeuk.com> - 2013-02-09 14:48 +0000
    Re: .SO files BGB <cr88192@hotmail.com> - 2013-01-22 15:19 -0600
    Re: .SO files Ian Collins <ian-news@hotmail.com> - 2013-01-23 10:25 +1300

#2883 — .SO files

Can someone help me understand .SO files?

Are these basically the Linux version of DLLs?

Are there any utilities to see what functions exist in a .SO file?

Thanks.

[toc] | [next] | [standalone]

#2884

bob <bob@coolfone.comze.com> writes:

> Can someone help me understand .SO files?
>
> Are these basically the Linux version of DLLs?

Yes.

> Are there any utilities to see what functions exist in a .SO file?

objdump -T xyz.so

You might want to ask in comp.unix.programmer for more details.

-- 
Ben.

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

#2885

On Tue, 22 Jan 2013 07:00:15 -0800 (PST), bob wrote:

> Can someone help me understand .SO files?
> Are these basically the Linux version of DLLs?
> Are there any utilities to see what functions exist in a .SO file?

nm

http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/index.html

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#2886

"bob" <bob@coolfone.comze.com> wrote in message 
news:54f17a5a-5add-4402-93fa-03a5af4b7dd1@googlegroups.com...
> Can someone help me understand .SO files?
>
> Are these basically the Linux version of DLLs?

Yes, but they're .so files not .SO. Linux is very, very fussy about getting 
upper and lower case just right.

-- 
Bartc 

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

#2966

BartC wrote:

> Yes, but they're .so files not .SO. Linux is very, very fussy about
> getting upper and lower case just right.

You, Sir, are an elite troll, and I fall for it /every/ /single/
/time/.

No, Linux is not "very, very fussy about getting upper and lower
case just right" whatever the **** that means.

Most file systems are /case sensitive/. And that's a feature.
The 1950s are long gone.

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

#2967

On Fri, 08 Feb 2013 10:41:23 +0100, Noob <root@127.0.0.1> wrote:

>BartC wrote:
>
>> Yes, but they're .so files not .SO. Linux is very, very fussy about
>> getting upper and lower case just right.
>
>You, Sir, are an elite troll, and I fall for it /every/ /single/
>/time/.
>
>No, Linux is not "very, very fussy about getting upper and lower
>case just right" whatever the **** that means.
>
>Most file systems are /case sensitive/. And that's a feature.
>The 1950s are long gone.


You'd have to pick a context for "most".  If we count the number of
file systems as the number of types (e.g. FAT16, NTFS, UFS, ext2,
etc.), you may be right, but there have been many non-case sensitive
FS's over the years.  And you get into a counting issue (is FAT one
FS, or three - FAT12/16/32?).

But if you look at the number of installed *volumes*, there are a
*lot* of non-case sensitive FS's out there.  Consider that almost all
flash drives (USB sticks, SD cards in cameras, etc.) are FAT, and that
most data CDs and DVDs are ISO9660, and both of those are non-case
sensitive.  Not to mention a few billion FAT formatted floppies lying
in the bottom of drawers.  And how do you count a billion NTFS
volumes, where the FS itself can maintain case, but almost all of the
OS instances using them "fix" that support?

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

#2968

On Fri, 08 Feb 2013 10:41:23 +0100, Noob wrote:

> Most file systems are /case sensitive/. And that's a feature.

Yep, "it's not a bug, it's a feature."

> The 1950s are long gone.

As well as 70's. Case-sensitive systems (programming languages included) is 
abomination. [Unicode case mapping is not rocket science to implement.]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#2971

"Noob" <root@127.0.0.1> wrote in message news:kf2gqq$99a$1@dont-email.me...
> BartC wrote:
>
>> Yes, but they're .so files not .SO. Linux is very, very fussy about
>> getting upper and lower case just right.
>
> You, Sir, are an elite troll, and I fall for it /every/ /single/
> /time/.
>
> No, Linux is not "very, very fussy about getting upper and lower
> case just right" whatever the **** that means.

It means it won't have a clue what you're on about if you try and give it an 
.SO, .sO or .So filename.

Maybe you think it's a feature where the filename AAAAAAAAAA can appear in 
over a thousand variations within the same directory. Some people don't.

-- 
Bartc 

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

#2977

"BartC" <bc@freeuk.com> writes:

> "Noob" <root@127.0.0.1> wrote in message news:kf2gqq$99a$1@dont-email.me...
>> BartC wrote:
>>
>>> Yes, but they're .so files not .SO. Linux is very, very fussy about
>>> getting upper and lower case just right.
>>
>> You, Sir, are an elite troll, and I fall for it /every/ /single/
>> /time/.
>>
>> No, Linux is not "very, very fussy about getting upper and lower
>> case just right" whatever the **** that means.
>
> It means it won't have a clue what you're on about if you try and give
> it an .SO, .sO or .So filename.
>
> Maybe you think it's a feature where the filename AAAAAAAAAA can
> appear in over a thousand variations within the same directory. Some
> people don't.

No one has made any such claim.  On the other hand, you have said that a
file system that takes a name literally is being "very, very fussy" and
someone else has gone so far as to say that such systems are an
abomination.  The level of debate about an interesting technical matter
has not, so far, been very high!

-- 
Ben.

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

#2978

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.4a92f4aa3839d40e6654.20130208212051GMT.87fw1633kc.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:

>> Maybe you think it's a feature where the filename AAAAAAAAAA can
>> appear in over a thousand variations within the same directory. Some
>> people don't.
>
> No one has made any such claim.  On the other hand, you have said that a
> file system that takes a name literally is being "very, very fussy"

What else is it being then? If it is refusing to recognise a file because 
the capitalisation isn't quite right, then it's being unnecessarily fussy.

Case-sensitivity would be a PITA in most other areas of life and in 
technology, and is just as much so in a file system. Duplicate filenames 
that differ only in case or capitalisation are unwise and undesirable 
anyway, so what's the point?

So, if you had one file called "One Day in the Life of Ivan 
Denisovitch.doc", would there be any point in having another, subtly 
different one called "One Day In The Life Of Ivan Denisovitch.doc", or any 
other variation?

Fortunately systems such as Google aren't quite as fussy, otherwise 
searching for anything could get quite frustrating!

-- 
Bartc 

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

#2979

"BartC" <bc@freeuk.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.4a92f4aa3839d40e6654.20130208212051GMT.87fw1633kc.fsf@bsb.me.uk...
>> "BartC" <bc@freeuk.com> writes:
>
>>> Maybe you think it's a feature where the filename AAAAAAAAAA can
>>> appear in over a thousand variations within the same directory. Some
>>> people don't.
>>
>> No one has made any such claim.  On the other hand, you have said that a
>> file system that takes a name literally is being "very, very fussy"
>
> What else is it being then? If it is refusing to recognise a file
> because the capitalisation isn't quite right, then it's being
> unnecessarily fussy.

Is it just case that gets your goat?  What about accents and spaces?
Do "Belle Époque", "belle èpoque", "Belle  Époque" and "Belle Époque"
all name the same file?  What about "aeon" and "æon"?

> Case-sensitivity would be a PITA in most other areas of life and in
> technology, and is just as much so in a file system. Duplicate
> filenames that differ only in case or capitalisation are unwise and
> undesirable anyway, so what's the point?

Duplicate file names that differ only in the number and type of spaces
in the name are also unwise and undesirable anyway, so presumably they
must be aliased too?

> So, if you had one file called "One Day in the Life of Ivan
> Denisovitch.doc", would there be any point in having another, subtly
> different one called "One Day In The Life Of Ivan Denisovitch.doc", or
> any other variation?

When a technical design works well it is often because it is able to
support uses that were not dreamt of by the designers.  My sorry lack of
imagination does not provide a sound reason to limit what distinct names
a file may have.

> Fortunately systems such as Google aren't quite as fussy, otherwise
> searching for anything could get quite frustrating!

Yes, it's amazing what the clever people at Google have achieved,
hampered as they are by having chosen to use a case-sensitive file
system.

-- 
Ben.

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

#2980

On Sat, 09 Feb 2013 02:32:56 +0000, Ben Bacarisse wrote:

> "BartC" <bc@freeuk.com> writes:
> 
>> Case-sensitivity would be a PITA in most other areas of life and in
>> technology, and is just as much so in a file system. Duplicate
>> filenames that differ only in case or capitalisation are unwise and
>> undesirable anyway, so what's the point?
> 
> Duplicate file names that differ only in the number and type of spaces
> in the name are also unwise and undesirable anyway, so presumably they
> must be aliased too?

Are you arguing against aliasing in general? Look, either (1) names must be
literally indistinguishable or else (2) there are classes of equivalence
and you must decide what is in a class.

The position #1 is undefendable for files, merely due to relative vs.
absolute path issue. Are "foo.txt", "./foo.txt", "/home/foo.txt" same,
different?

Considering #2, the argument that two spaces could or not make a distinct
name is irrelevant to whether 'A' vs. 'a' should.

Otherwise, letting any characters in a name (identifier) is a bad idea what
spaces and ascents promptly illustrate. This includes some letters as well,
e.g. are "ärger", "aerger", "аеrger" same? For a German reader the first
two are same, the third is not because it uses Cyrillic 'а' and 'е'.

>> Fortunately systems such as Google aren't quite as fussy, otherwise
>> searching for anything could get quite frustrating!
> 
> Yes, it's amazing what the clever people at Google have achieved,
> hampered as they are by having chosen to use a case-sensitive file
> system.

BTW HTTP-based, isn't it?

Reading RFC 2616 3.2.3:

"  When comparing two URIs to decide if they match or not, a client
   SHOULD use a case-sensitive octet-by-octet comparison of the entire
   URIs, with these exceptions:

      - A port that is empty or not given is equivalent to the default
        port for that URI-reference;

        - Comparisons of host names MUST be case-insensitive;

        - Comparisons of scheme names MUST be case-insensitive; ..."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#2981

Dmitry A. Kazakov wrote:

> Reading RFC 2616 3.2.3:
> [...]
>        - Comparisons of host names MUST be case-insensitive;

And what in Hell that means now that we've had non-ASCII host names pushed into 
the system (with far too little thought, IMO), is anybody's guess...

Unless someone has a link to an official clarification ?

    -- chris 

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

#2984

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 09 Feb 2013 02:32:56 +0000, Ben Bacarisse wrote:
>
>> "BartC" <bc@freeuk.com> writes:
>> 
>>> Case-sensitivity would be a PITA in most other areas of life and in
>>> technology, and is just as much so in a file system. Duplicate
>>> filenames that differ only in case or capitalisation are unwise and
>>> undesirable anyway, so what's the point?
>> 
>> Duplicate file names that differ only in the number and type of spaces
>> in the name are also unwise and undesirable anyway, so presumably they
>> must be aliased too?
>
> Are you arguing against aliasing in general?

No, I was asking for more details about BartC's position.  I wanted to
know if case was all the mattered so I posed a question echoing his form
of words.

> Look, either (1) names must be
> literally indistinguishable or else (2) there are classes of equivalence
> and you must decide what is in a class.
>
> The position #1 is undefendable for files, merely due to relative vs.
> absolute path issue. Are "foo.txt", "./foo.txt", "/home/foo.txt" same,
> different?

That's a new issue that I can only imagine you've introduced in order to
make #1 seem indefensible.  We can certainly talk what pros and cons of
having multiple paths refer to the same file, but it's not the same
issue.

> Considering #2, the argument that two spaces could or not make a distinct
> name is irrelevant to whether 'A' vs. 'a' should.

I don't yet know if there even *is* an argument about spacing being
ignored so I can't say if the argument about it is relevant to the
argument about case.  It's possible that someone will want to make
closely related arguments about both issues, in which case the argument
about one *will* be relevant to the other.

> Otherwise, letting any characters in a name (identifier) is a bad idea what
> spaces and ascents promptly illustrate. This includes some letters as well,
> e.g. are "ärger", "aerger", "аеrger" same? For a German reader the first
> two are same, the third is not because it uses Cyrillic 'а' and 'е'.

I don't follow exactly, but I think I agree.

>>> Fortunately systems such as Google aren't quite as fussy, otherwise
>>> searching for anything could get quite frustrating!
>> 
>> Yes, it's amazing what the clever people at Google have achieved,
>> hampered as they are by having chosen to use a case-sensitive file
>> system.
>
> BTW HTTP-based, isn't it?

The paper I've read did not say that it's HTTP-based, but I am no
expert.  A reference would be very helpful here.

> Reading RFC 2616 3.2.3:
>
> "  When comparing two URIs to decide if they match or not, a client
>    SHOULD use a case-sensitive octet-by-octet comparison of the entire
>    URIs, with these exceptions:
>
>       - A port that is empty or not given is equivalent to the default
>         port for that URI-reference;
>
>         - Comparisons of host names MUST be case-insensitive;
>
>         - Comparisons of scheme names MUST be case-insensitive; ..."

If Google's FS is HTTP-based one would have to know the role that HTTP
played to be able to tell if file names are case-sensitive or not.  As
your quote shows, URIs are case sensitive with only historic exceptions.

-- 
Ben.

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

#2985

On Sat, 09 Feb 2013 12:11:54 +0000, Ben Bacarisse wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Look, either (1) names must be
>> literally indistinguishable or else (2) there are classes of equivalence
>> and you must decide what is in a class.
>>
>> The position #1 is undefendable for files, merely due to relative vs.
>> absolute path issue. Are "foo.txt", "./foo.txt", "/home/foo.txt" same,
>> different?
> 
> That's a new issue that I can only imagine you've introduced in order to
> make #1 seem indefensible.  We can certainly talk what pros and cons of
> having multiple paths refer to the same file, but it's not the same
> issue.

It is about whether two different chains of characters may denote the same
file. E.g. "Foo.txt" and "foo.txt", and "foo.txt" and "./foo.txt"? Once you
agree that lexical equivalence of names is not necessarily implied by the
equivalence or named objects, you leave #1 and enter #2.

>> Considering #2, the argument that two spaces could or not make a distinct
>> name is irrelevant to whether 'A' vs. 'a' should.
> 
> I don't yet know if there even *is* an argument about spacing being
> ignored so I can't say if the argument about it is relevant to the
> argument about case.

Within #2 spaces can be treated as illegal characters, a character
equivalent to any non-empty chain of spaces, a character equivalent to any
non-empty chain of Unicode spaces, and so on.

The point is that the way you do it is unrelated to the way you do letters
of Indo-European alphabets, where capitalization is an aspect of a glyph,
which is not supposed to change its meaning, i.e. both 'A' and 'a' denote
the *same* letter.

>>>> Fortunately systems such as Google aren't quite as fussy, otherwise
>>>> searching for anything could get quite frustrating!
>>> 
>>> Yes, it's amazing what the clever people at Google have achieved,
>>> hampered as they are by having chosen to use a case-sensitive file
>>> system.
>>
>> BTW HTTP-based, isn't it?
> 
> The paper I've read did not say that it's HTTP-based, but I am no
> expert.  A reference would be very helpful here.
> 
>> Reading RFC 2616 3.2.3:
>>
>> "  When comparing two URIs to decide if they match or not, a client
>>    SHOULD use a case-sensitive octet-by-octet comparison of the entire
>>    URIs, with these exceptions:
>>
>>       - A port that is empty or not given is equivalent to the default
>>         port for that URI-reference;
>>
>>         - Comparisons of host names MUST be case-insensitive;
>>
>>         - Comparisons of scheme names MUST be case-insensitive; ..."
> 
> If Google's FS is HTTP-based one would have to know the role that HTTP
> played to be able to tell if file names are case-sensitive or not.  As
> your quote shows, URIs are case sensitive with only historic exceptions.

That should be a misunderstanding. I thought you meant Google as a
successful search engine.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#2987

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:15o1nwus3az88$.1pus193jmde35.dlg@40tude.net...
> On Sat, 09 Feb 2013 02:32:56 +0000, Ben Bacarisse wrote:

>> Yes, it's amazing what the clever people at Google have achieved,
>> hampered as they are by having chosen to use a case-sensitive file
>> system.

>        - Comparisons of host names MUST be case-insensitive;

There might be other reasons for that. For example, to prevent 30,000-odd
other companies from having host names that are just variations of www dot
microsoft dot com.

However, that's pretty much the same common sense approach that deems all
upper/lower case combinations of an individual's name to be equivalent. Or 
their street address or city name. (Imagine sending some mail to a LONDON 
address, and having it returned to sender! Yet file systems that do that are 
so clever!)

-- 
Bartc
 

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

#3012

One of the things I don't have much time for is cleaning up my computer files, so this morning I downloaded one of these new duplicate finder computer programs. It sounded simple enough, a computer program that finds exact duplicate and partial duplicate files and lets you decide what you want to do with them. I nearly didn't have time to download it and only just caught the seven forty-two train. It would have kinda defeated the object of saving time if the process of downloading the program had forced me to get a later train.Get A Free Software On : http://www.ashisoft.com

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

#2986

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.079fd0d6adb80e339f92.20130209023256GMT.87a9re2p47.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:

>> What else is it being then? If it is refusing to recognise a file
>> because the capitalisation isn't quite right, then it's being
>> unnecessarily fussy.
>
> Is it just case that gets your goat?  What about accents and spaces?
> Do "Belle Époque", "belle èpoque", "Belle  Époque" and "Belle Époque"
> all name the same file?  What about "aeon" and "æon"?

That's the main issue I have with Unix-like file systems (and with
programming language identifiers, but that's another matter).

I don't use spaces inside filenames myself, and certainly wouldn't use
accents.

We shouldn't forget that a filename is a key used to identify a file which
contains the actual content. Once you allow anything in a filename, and
remove the restriction on length, then you no longer need a separate content
part! Because you can just store everything in the filename.

But that's not practical (imagine trying to locate a book by typing in the
entire contents! And it wouldn't be practical to do a literal match because
you will already have ambiguity half-way through the first sentence.)

So it make sense to impose some restrictions on an identifier to be used a
filename. Allowing letter case to be significant is a bad idea that perhaps
had origins in C or Unix, and that seems to have permeated through
everything since.

>> Fortunately systems such as Google aren't quite as fussy, otherwise
>> searching for anything could get quite frustrating!
>
> Yes, it's amazing what the clever people at Google have achieved,
> hampered as they are by having chosen to use a case-sensitive file
> system.

You mean in spite of it?

It's easy enough to program case-insensitivity when you want to. The Windows 
file systems, for example. In the case of Google, their indexing systems 
must already be complex enough without having to treat all 2^N combinations 
of an N-character index word separately!

-- 
bartc 

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

#2888

On 1/22/2013 9:00 AM, bob wrote:
> Can someone help me understand .SO files?
>
> Are these basically the Linux version of DLLs?
>

more or less.

> Are there any utilities to see what functions exist in a .SO file?
>

objdump


they serve basically a similar role, but there are differences:
DLLs use the PE/COFF file-format, SOs use ELF;
DLLs are searched for using PATH, SOs in specific locations;
...

on Windows, it is typical for a person to access a DLL via 
"LoadLibrary()" and "GetProcAddress()".

whereas, on Linux, it is "dlopen()" and "dlsym()".

but, in general, they are similar enough to where most differences can 
be glossed over with a few #ifdef's.


the searching in specific locations is kind of annoying IMO, since it 
requires compiling with special options to make the loader check in the 
same directory in the program for its SOs, which is sort of a "why isn't 
this the default behavior?!" issue (or at least a shorter command-line 
option would have been nice, like "--rpathcwd" or something).


in my case, when dynamically loading SOs by name (in my OS wrapper 
code), there is some code which iteratively probes various locations to 
search for DLLs/SOs, similar to its own sort of path.

for example:
appdir/resource_foo/
appdir/resource/
appdir/
...


well, that, and I have my own funkiness for embedding files (typically 
script code and metadata) into both DLLs and SOs.

it is an idea sort of like a JAR stuffed into an DLL, except using a 
hierarchical WAD variant, rather than a ZIP-based package format 
(intentional, for various reasons).

then one can fetch things like script code and bytecode, VM metadata, 
... from files embedded within the DLL or SO.


yes, ZIP-based package formats are popular, but have a big annoyance, 
namely apps being like "hey, its contents look like a ZIP, but I don't 
recognize the extension, so I will rename it for you".

so, one ends up with lots of JAR / ODT / DOCX / ... files all 
"conviniently" renamed to have a ZIP extension (and people whining about 
"I try to download this JAR/ODT/..." and all I get is a ZIP file with 
lots of little files in it). little to say it wouldn't also happen with 
EXEs and DLLs.

so, in my case, I chose a custom packaging. WAD was an obvious-enough 
choice to base the design off of.


actually, it is sort of like .NET CLR images:
they are just sort of crudely tacked onto the end of an EXE or DLL 
PE/COFF image;
but, for the most part, their existence is hidden and ignorable (users 
don't care, the OS loader doesn't care, ... then the VM notices images 
that contain data it cares about).


ironically, it doesn't much effect the size of SOs, because it seems my 
VM image data is typically dwarfed by the DWARF data.


or such...

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

#2889

bob wrote:
> Can someone help me understand .SO files?
>
> Are these basically the Linux version of DLLs?

No, they are more or less the UNIX version of DLLs.  Linux uses them as 
well, but they are not specific to Linux.  As others have pointed out, 
the shared library extension is .so not .SO.

-- 
Ian Collins

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web