On 2017-05-10 03:26:14 +0200, Vincent Lefevre wrote:
> Forget that. This breaks the use of LD_RUN_PATH. :( Or the contents
> of LD_RUN_PATH should be added as rpath arguments by the wrapper.
In case this can be useful:
#!/bin/sh
LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr
On 2017-05-10 01:31:02 +0200, Vincent Lefevre wrote:
> > closing this issue, there is no "propoer" solution.
>
> I'm just thinking... Couldn't the use of a run path for
> /usr/lib/gcc-snapshot/lib be a proper solution? i.e. give
> a better wrapper as an example? For instance, on amd64,
> the wrapp
Control: reopen -1
Control: severity -1 minor
Control: retitle -1 gcc-snapshot: README.Debian is inaccurate concerning
LD_LIBRARY_PATH
On 2017-05-10 00:00:10 +0200, Matthias Klose wrote:
> set LD_LIBRARY_PATH for running your binaries.
OK, I now understand (I didn't see that gcc-snapshot provide
Processing control commands:
> reopen -1
Bug #862176 {Done: Matthias Klose } [gcc-snapshot]
gcc-snapshot: needs packages from experimental, with -fsanitize=address
Bug reopened
Ignoring request to alter fixed versions of bug #862176 to the same values
previously set
> severity -1 minor
Bug #8621
Your message dated Wed, 10 May 2017 00:00:10 +0200
with message-id <51d44b04-d261-b070-e68a-5dbf41927...@debian.org>
and subject line Re: Bug#862176: gcc-snapshot: needs packages from
experimental, with -fsanitize=address
has caused the Debian Bug report #862176,
regarding gcc-snapshot: needs pack
LAST_UPDATED: Fri May 5 15:03:06 UTC 2017 (revision 247636)
=== acats tests ===
=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is mips-unknown-linux-gnu
=== g++ tests ===
Running
Package: gcc-snapshot
Version: 20170505-1
Severity: important
If I compile a program with
gcc-snapshot -fsanitize=address
I get when running it:
./a.out: error while loading shared libraries: libasan.so.4: cannot open shared
object file: No such file or directory
libasan.so.4 is part of lib
7 matches
Mail list logo
