On 1/20/19 8:47 PM, Mohammad Akhlaghi wrote:
Thank you very much for the prompt replies, they were very useful.
In the end (for the time being!), I am using patchelf. I couldn't find a
way to configure Bash with RPATH (I still haven't stopped searching, but
I need to progress for now).
I ha
Thank you very much for the prompt replies, they were very useful.
In the end (for the time being!), I am using patchelf. I couldn't find a
way to configure Bash with RPATH (I still haven't stopped searching, but
I need to progress for now).
It is interesting that exported variables are not s
On Sun, 2019-01-20 at 21:57 +, Martin Dorey wrote:
> > Why ouch?
>
> Because it's unpleasant and wasteful to work in an environment where
> you're not trusted.
Well, it might not be work-related.
I can ssh into my ISP server using my local account so I can muck
around and set things up, but
> Why ouch?
Because it's unpleasant and wasteful to work in an environment where you're not
trusted.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
On Sun, 2019-01-20 at 21:18 +, Martin Dorey wrote:
> >> on a server, where I don't have root access
>
> Ouch.
Why ouch? He's installing his own bash so he can modify his own
version of bash. He just can't install it as the system version or add
libraries to the default runtime library searc
>> on a server, where I don't have root access
Ouch.
> using RPATH at link time
Debian has a package called chrpath, supplying an executable of the same name
which lets you change the RPATH later. That might be easier than doing battle
with the underlying bash package's build rules. The man
On Sun, 2019-01-20 at 19:32 +, Mohammad Akhlaghi wrote:
> Since I couldn't find any mention of this in in the manual, I wanted to
> see if this removal of LD_LIBRARY_PATH from the $(shell) function is
> intentional or if its a bug?
It is not the case that LD_LIBRARY_PATH is removed by the $(
