linux guru's , i got a question

[Ameesh]

Do you have DLL's in linux? if not what do you have that replaces them with a similar functionality.

 

[Ameesh]

a bump before i head off to work

 

[notfred]

no DLLs, but you do have source and object libraries. check out the /lib directory at a unix machine near you.

 

[Ameesh]

Originally posted by: notfred
no DLLs, but you do have source and object libraries. check out the /lib directory at a unix machine near you.

those are statically linked, not dynamically, there is no dynamically linked library available in linux?

 

[notfred]

Um.... I dunno 🙂

 

[Talon]

This might provide some information.

 

[Ameesh]

Originally posted by: Talon
This might provide some information.

just a quick followup, how many of your programs use dll's? including the the stuff that comes with KDE and gnome and the shells themselves.

 

[Talon]

I can't answer that, Ameesh. I don't actually use Linux. I've just started reading up on it and the BSD's and came upon that site by chance.🙂😱

 

[singh]

Google is your friend. Here's a thread with a little discussion: Dynamic Linked libraries equivalent

Doesn't seem nearly as elegant as Win32, but what do I know 🙂

 

[manly]

And why aren't they as elegant as DLLs? Because they don't come w/ the associated hell? 🙂

I don't know specifically, but dynamic linking is more the norm than the exception. Static linking is very much pre-1990s...

Talon linked to a pretty decent introductory article.

 

[singh]

Originally posted by: manly
And why aren't they as elegant as DLLs? Because they don't come w/ the associated hell? 🙂

In theory, you can do LOT with DLL's on Win32 and they seem to have a lot more native support in Windows.

As for "DLL Hell", I have never witnessed any DLL problem first-hand - neither as a developer nor as a user (maybe I'm just lucky)🙂 I have only heard people having problems. Anyways, I know nothing of *nix, so my opinion is just that - an opinion.

 

[Nothinman]

All the .so files in /lib, /usr/lib, etc (no, not /etc) are libraries you can dynamically link against.

I don't see the confusion. What's inelegant about them?

 

[cleverhandle]

just a quick followup, how many of your programs use dll's? including the the stuff that comes with KDE and gnome and the shells themselves.

Most every program in a typical linux installation is dynamically linked, from low level file utilities, through shells, up to X and GNOME/KDE. There are a few rare exceptions - some things don't seem to like sharing a library for whatever reason, and some maintenance/recovery programs are compiled statically so that they can be used directly off a boot disk or at some other time when the shared libraries are unavailable. But overall, shared libraries are the rule, not the exception. Exact choices about whether to compile a program statically or dynamically would be up to the distributor, but you can get an idea by going to /usr/bin, /usr/sbin, /opt/gnome, or whatever your favorite busy directory is and running "ldd *". Every line that comes up is a link to a shared library.

 

[n0cmonkey]

Originally posted by: Ameesh

Originally posted by: Talon
This might provide some information.

just a quick followup, how many of your programs use dll's? including the the stuff that comes with KDE and gnome and the shells themselves.

Do you want an exact count?

cd /
file `ls -R` | grep dynamic | wc -l

Should do it for you (havent tested it out, just a quick guess). 🙂

 

[Nothinman]

just a quick followup, how many of your programs use dll's?

Nearly every binary on a Linux system is dynamically linked, that's why there's packages like sash, e2fsck-static, etc so that you can fix your root filesystem if you break your libs.

LDD(1) LDD(1)

NAME
ldd - print shared library dependencies

SYNOPSIS
ldd [OPTION]... FILE...

DESCRIPTION
ldd prints the shared libraries required by each program or shared library specified on the command line.

$ ldd `which ls`
librt.so.1 => /lib/librt.so.1 (0x000002000002e000)
libc.so.6.1 => /lib/libc.so.6.1 (0x0000020000054000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00000200001ea000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0000020000000000)

 

[n0cmonkey]

Originally posted by: Nothinman

just a quick followup, how many of your programs use dll's?

Nearly every binary on a Linux system is dynamically linked, that's why there's packages like sash, e2fsck-static, etc so that you can fix your root filesystem if you break your libs.

LDD(1) LDD(1)

NAME
ldd - print shared library dependencies

SYNOPSIS
ldd [OPTION]... FILE...

DESCRIPTION
ldd prints the shared libraries required by each program or shared library specified on the command line.

$ ldd `which ls`
librt.so.1 => /lib/librt.so.1 (0x000002000002e000)
libc.so.6.1 => /lib/libc.so.6.1 (0x0000020000054000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00000200001ea000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0000020000000000)

$ ldd `which ls`
ldd: /bin/ls: not a dynamic executable

This is OpenBSD though and nothing in /bin is dynamic...

 

[earthman]

I was under the impression that if dymamic linking wasn't always used in Linux apps its because of the various distrubutions and the fact that they may use c libraries that are not compatible from one system to the next, or which may vary in version...for this reason many of the apps available are compiled as statically linked to ensure they work. Windows is a closed system and the standard dll's are generally there always so its less of a problem.

 

[Nothinman]

I was under the impression that if dymamic linking wasn't always used in Linux apps its because of the various distrubutions and the fact that they may use c libraries that are not compatible from one system to the next, or which may vary in version...

Some people like Opera give you the option for a static binary to get around any library problems you might have. But IME library versioning problems and incompatibilities are a lot less common on Linux than Windows, otherwise every program for Windows wouldn't install it's own version of MFC*.dll or whatever.

The general consensus in the Linux community seems to be that source level compatibility is what's important and binary compatibility takes the back seat. If you want to distribute a binary-only application you get to deal with the inherent problems with it.