[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Working around package conflict



I think this idea will work just fine - I'll test it shortly.

Thanks.
JS.

On Fri, 22 Aug 2003 07:52 am, Bob Proulx wrote:
> James Steward<stewardje@netscape.net> wrote:
> > Sorry Bob - that didn't quite work.  I did something like the following;
> > mkdir /usr/lib/libkde3
> > cp /root/kdelib3/usr/lib/* /usr/lib/libkde3/
> > vi /etc/ld.so.conf
> > { add the path /usr/lib/libkde3 }
> > ldconfig
>
> Ooo.  I would not make that change a global change.  Instead I would
> make it a private change just for the application.
>
> File myvericad:
>   #!/bin/sh
>   export LD_LIBRARY_PATH=/usr/lib/libkde3
>   exec vericad "$@"
>
> Now in that case when you run vericad it gets the old libraries but
> this does not affect anything else.  Actually I would call it by the
> same name and put it in /usr/local/bin which is ahead of /usr/bin in
> PATH and have it do the rest.  That way it behaves the same.
>
> File /usr/local/bin/vericad:
>   #!/bin/sh
>   export LD_LIBRARY_PATH=/usr/lib/libkde3
>   exec /usr/bin/vericad "$@"
>
> > start varicad - runs ok - no SEGV - cool.
> > start konqueror - SEGV
> >
> > remove the lib path from ld.so.conf and ldconfig, konqueror runs ok now.
>
> This proposal above should solve this problem.
>
> Caveat: Since LD_LIBRARY_PATH is in the environment it will persist
> into subshells launched by vericad.  If you shell out of vericad into
> a subshell and then launch konqueror you will get the old libs which
> cause konqueror to core dump.  So don't do that.  :-)  I don't even
> know if you can do that with vericad but just in case.
>
> Bob



Reply to: