On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> I honestly don't see what the hell is wrong with using a shell script to
> do this so a binary can be relocating.
1) You have to figure out whether to use LD_LIBRARY_PATH, SHLIB_PATH,
LD32_LIBRARY_PATH, LD64_LIBRARY_PATH, etc.
2) You
On Apr 14, 2000, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> Note that since free software is available with full source code, it
> can be compiled to specifically match a particular system
> configuration if an appropriate binary distribuition for that system
> is not available.
As long as the
On Fri, 14 Apr 2000, Bob Friesenhahn wrote:
> On Fri, 14 Apr 2000, Kevin Atkinson wrote:
>
> > On Fri, 14 Apr 2000, Bob Friesenhahn wrote:
> >
> > > Commercial programs typically include a shell script which sets
> > > LD_LIBRARY_PATH (and other variables) in order to find the package
> > > com
On Fri, 14 Apr 2000, Kevin Atkinson wrote:
> On Fri, 14 Apr 2000, Bob Friesenhahn wrote:
>
> > Commercial programs typically include a shell script which sets
> > LD_LIBRARY_PATH (and other variables) in order to find the package
> > components. While this may be fine for commercial software, i
On Fri, 14 Apr 2000, Bob Friesenhahn wrote:
> Commercial programs typically include a shell script which sets
> LD_LIBRARY_PATH (and other variables) in order to find the package
> components. While this may be fine for commercial software, it is not
> acceptable for free software since free sof
On Fri, 14 Apr 2000, Kevin Atkinson wrote:
> > Try supporting this for 5000 users of your installed program across
> > 5000 workstations/PCs. This approach fails miserably. Besides the
> > effort to get your users to use the same LD_LIBRARY_PATH, there is the
> > problem with conflicts between si
On Fri, 14 Apr 2000, Bob Friesenhahn wrote:
> On Fri, 14 Apr 2000, Kevin Atkinson wrote:
> > Doesn't either setting LD_LIBRARY_PATH (or the equivalent variable for
> > your particular system) or adding the weird location to /etc/ld.so.conf
> > (or the equivalent file for your particular system)
On Fri, 14 Apr 2000, Kevin Atkinson wrote:
> Doesn't either setting LD_LIBRARY_PATH (or the equivalent variable for
> your particular system) or adding the weird location to /etc/ld.so.conf
> (or the equivalent file for your particular system) generally solve the
> problem?
Try supporting this f
On 14 Apr 2000, Alexandre Oliva wrote:
> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > Doesn't either setting LD_LIBRARY_PATH (or the equivalent variable for
> > your particular system) or adding the weird location to /etc/ld.so.conf
> > (or the equivalent file for your partic
On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> Doesn't either setting LD_LIBRARY_PATH (or the equivalent variable for
> your particular system) or adding the weird location to /etc/ld.so.conf
> (or the equivalent file for your particular system) generally solve the
> problem?
It s
On 14 Apr 2000, Alexandre Oliva wrote:
> My fear is that others might start to depend on this feature, which
> might solve the problem for them, but not for people who happen to
> install libraries in places other than /usr or /usr/local, like me.
> In fact, I've always advocated against these *-
On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> Ok, so how difficult would it be to have libtool list out these libraries
> for my "pspell-config" script.
I don't think it would be very hard. It's just a matter of copying
the parts of libtool that expand dependency_libs to the new
On 14 Apr 2000, Alexandre Oliva wrote:
> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > So will listing out ALL the required libraries, provided that they are in
> > the library search path (ie no rpath nonsense) work on most system in both
> > the shared and static case?
>
>
On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> So will listing out ALL the required libraries, provided that they are in
> the library search path (ie no rpath nonsense) work on most system in both
> the shared and static case?
I hope so :-)
> In the static cast will listing out a
On 14 Apr 2000, Alexandre Oliva wrote:
> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > On 14 Apr 2000, Alexandre Oliva wrote:
> >> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> >>
> >> > If the rpath is not needed or the equivalent will simply listing out the
>
On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> On 14 Apr 2000, Alexandre Oliva wrote:
>> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>>
>> > If the rpath is not needed or the equivalent will simply listing out the
>> > necessary libraries work on most, or the most co
On 14 Apr 2000, Alexandre Oliva wrote:
> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > If the rpath is not needed or the equivalent will simply listing out the
> > necessary libraries work on most, or the most common systems?
>
> If a library depends on another, and you don't
On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> If the rpath is not needed or the equivalent will simply listing out the
> necessary libraries work on most, or the most common systems?
If a library depends on another, and you don't explicitly link the
dependency in, the program will
On 13 Apr 2000, Alexandre Oliva wrote:
> On Apr 13, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > Could you elaborate. When shared libraries are used simply linking with
> > -lpspell should work as all the dependences will automatically be tracked
> > down provided that the system supp
On Apr 13, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>> In general, it can't be done. Sometimes libtool has to combine flags,
>> or to set environment variables, in order to link successfully.
> Could you elaborate. When shared libraries are used simply linking with
> -lpspell should wo
On 13 Apr 2000, Alexandre Oliva wrote:
> On Apr 13, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > The basic idea is NOT to use the preload feature of libtool but instead
> > build up the data structure myself.
>
> Wait a minute. If you're not dlopening anything, you don't need any
> pr
On Apr 13, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> The basic idea is NOT to use the preload feature of libtool but instead
> build up the data structure myself.
Wait a minute. If you're not dlopening anything, you don't need any
preloading. `-dlopen' only applies to modules you're go
For those of you who are interested here is the solution I came up with to
me preloading problem.
The basic idea is NOT to use the preload feature of libtool but instead
build up the data structure myself. To do this I use the following:
<<<
#ifndef PRELOAD__H
#define PRELOAD__H
#include
#
23 matches
Mail list logo
