Devin Carraway [EMAIL PROTECTED] immo vero scripsit:
Ignoring the irksome ld.so issues for a moment, upstram for this package
is doing exactly the right thing by putting common functionality out in
shared libs, even if the only executables sharing them are the ones in
the package itself.
On Mon, Sep 23, 2002 at 11:49:50PM +0900, Junichi Uekawa wrote:
Matt Zimmerman [EMAIL PROTECTED] immo vero scripsit:
Sometimes this happens because it makes sense to share the library within
the (to conserve resources), but either:
- It does not make sense for other programs to use
On Sun, Sep 22, 2002 at 01:40:12PM -0600, Bob Proulx wrote:
If you can avoid those shared libraries it would be best. Libraries
should be either shared in /usr/lib or not shared at all. The halfway
between place is not a mature methodology at this time and contains
many problems.
Ignoring
On Sun, Sep 22, 2002 at 08:54:19PM +0900, Junichi Uekawa wrote:
Devin Carraway [EMAIL PROTECTED] immo vero scripsit:
I'm working on a package containing several executables, whose common
functionality lives in a few shared libraries. They're linked in the
usual way at compile time.
Matt Zimmerman [EMAIL PROTECTED] immo vero scripsit:
Sometimes this happens because it makes sense to share the library within
the (to conserve resources), but either:
- It does not make sense for other programs to use the library (very
specific)
But we all know that it is very often
Devin Carraway [EMAIL PROTECTED] immo vero scripsit:
Ignoring the irksome ld.so issues for a moment, upstram for this package
is doing exactly the right thing by putting common functionality out in
shared libs, even if the only executables sharing them are the ones in
the package itself.
On Mon, Sep 23, 2002 at 11:49:50PM +0900, Junichi Uekawa wrote:
Matt Zimmerman [EMAIL PROTECTED] immo vero scripsit:
Sometimes this happens because it makes sense to share the library within
the (to conserve resources), but either:
- It does not make sense for other programs to use
I'm working on a package containing several executables, whose common
functionality lives in a few shared libraries. They're linked in the
usual way at compile time. Policy says they should live in
/usr/lib/packagename/, but I need to make them available for the runtime
linker.
I know of three
Devin Carraway [EMAIL PROTECTED] immo vero scripsit:
I'm working on a package containing several executables, whose common
functionality lives in a few shared libraries. They're linked in the
usual way at compile time. Policy says they should live in
/usr/lib/packagename/, but I need to
Devin Carraway [EMAIL PROTECTED] [2002-09-22 01:35:32 -0700]:
I'm working on a package containing several executables, whose common
functionality lives in a few shared libraries. They're linked in the
usual way at compile time. Policy says they should live in
/usr/lib/packagename/, but I
Devin Carraway [EMAIL PROTECTED] [2002-09-22 01:35:32 -0700]:
BTW, I wanted to also say...
I know of three ways to deal with this one -- add a new path to
ld.so.conf (yuck),
Blech! Very yucky taste in mouth. ;-)
link with -rpath, or wrap the apps in a script which alters
Junichi Uekawa [EMAIL PROTECTED] [2002-09-22 20:54:19 +0900]:
What would be the point of restricting the shared libraries to
within the software ?
The traditional argument is usually that shared libraries save disk
space. If your have a large amount of code that is completely shared
between N
On Sunday 22 Sep 2002 8:31 pm, Bob Proulx wrote:
Is there a dependency that you continue to provide the shared
libraries? If so then they should be in /usr/lib and should be public
shared libraries. Private shared libraries really don't make much
sense to me. There are specific uses but
I'm working on a package containing several executables, whose common
functionality lives in a few shared libraries. They're linked in the
usual way at compile time. Policy says they should live in
/usr/lib/packagename/, but I need to make them available for the runtime
linker.
I know of three
Devin Carraway [EMAIL PROTECTED] immo vero scripsit:
I'm working on a package containing several executables, whose common
functionality lives in a few shared libraries. They're linked in the
usual way at compile time. Policy says they should live in
/usr/lib/packagename/, but I need to
Devin Carraway [EMAIL PROTECTED] [2002-09-22 01:35:32 -0700]:
I'm working on a package containing several executables, whose common
functionality lives in a few shared libraries. They're linked in the
usual way at compile time. Policy says they should live in
/usr/lib/packagename/, but I
Devin Carraway [EMAIL PROTECTED] [2002-09-22 01:35:32 -0700]:
BTW, I wanted to also say...
I know of three ways to deal with this one -- add a new path to
ld.so.conf (yuck),
Blech! Very yucky taste in mouth. ;-)
link with -rpath, or wrap the apps in a script which alters
Junichi Uekawa [EMAIL PROTECTED] [2002-09-22 20:54:19 +0900]:
What would be the point of restricting the shared libraries to
within the software ?
The traditional argument is usually that shared libraries save disk
space. If your have a large amount of code that is completely shared
between N
On Sunday 22 Sep 2002 8:31 pm, Bob Proulx wrote:
Is there a dependency that you continue to provide the shared
libraries? If so then they should be in /usr/lib and should be public
shared libraries. Private shared libraries really don't make much
sense to me. There are specific uses but
19 matches
Mail list logo
