Bug#862176: gcc-snapshot: needs packages from experimental, with -fsanitize=address

[Vincent Lefevre]

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/lib/gcc-snapshot/bin:$PATH
rpath=""
OLD_IFS="$IFS"
IFS=:
for i in $LD_RUN_PATH
do
  rpath="$rpath -Wl,-rpath -Wl,$i"
done
IFS="$OLD_IFS"
exec gcc -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib32 \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/libx32 $rpath "$@"

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#862176: gcc-snapshot: needs packages from experimental, with -fsanitize=address

[Vincent Lefevre]

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 wrapper could be:
> 
> --- snip --
> #!/bin/sh
> LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
> PATH=/usr/lib/gcc-snapshot/bin:$PATH
> exec gcc -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib \
>  -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib32 \
>  -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/libx32 "$@"
> --- snip --

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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#862176: gcc-snapshot: needs packages from experimental, with -fsanitize=address

[Vincent Lefevre]

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 provided
/usr/lib/gcc-snapshot/lib/libasan.so.4), but this was not clear.
The /usr/share/doc/gcc-snapshot/README.Debian file first says:


To use this snapshot, you should set the following environment variables:

LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH


That way, things will work. But just after, it suggests an alternate
solution:


You might also like to use a shell script to wrap up this 
funcationality, e.g. 
 
place in /usr/local/bin/gcc-snapshot and chmod +x it 
 
--- snip --
#! /bin/sh
LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH
gcc "$@"
--- snip --

Make the same for g++, g77, gij, gcj, cpp, ...


This is the solution I'm currently using, but as you say, this may
not be sufficient. There should be some warning saying that under
some conditions, such as the use of the address sanitizer, the
LD_LIBRARY_PATH will also be needed for the generated binaries.
Or...

> 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 wrapper could be:

--- snip --
#!/bin/sh
LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH
exec gcc -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib32 \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/libx32 "$@"
--- snip --

This seems to work (I've tested on amd64 with and without -m32).
Wouldn't this be a better solution?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Processed: Re: Bug#862176: gcc-snapshot: needs packages from experimental, with -fsanitize=address

[Debian Bug Tracking System]

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 #862176 [gcc-snapshot] gcc-snapshot: needs packages from experimental, with 
-fsanitize=address
Severity set to 'minor' from 'important'
> retitle -1 gcc-snapshot: README.Debian is inaccurate concerning 
> LD_LIBRARY_PATH
Bug #862176 [gcc-snapshot] gcc-snapshot: needs packages from experimental, with 
-fsanitize=address
Changed Bug title to 'gcc-snapshot: README.Debian is inaccurate concerning 
LD_LIBRARY_PATH' from 'gcc-snapshot: needs packages from experimental, with 
-fsanitize=address'.

-- 
862176: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862176
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#862176: gcc-snapshot: needs packages from experimental, with -fsanitize=address

[Vincent Lefevre]

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 libasan4, which exists only in experimental,
while gcc-snapshot 20170505-1 is in unstable.

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-snapshot depends on:
ii  binutils2.28-4
ii  libc6   2.24-10
ii  libc6-dev   2.24-10
ii  libc6-dev-i386  2.24-10
ii  libc6-dev-x32   2.24-10
ii  libc6-i386  2.24-10
ii  libc6-x32   2.24-10
ii  libgc1c21:7.4.2-8
ii  libgmp102:6.1.2+dfsg-1
ii  libisl150.18-1
ii  libmpc3 1.0.3-1+b2
ii  libmpfr43.1.5-1
ii  python  2.7.13-2
ii  zlib1g  1:1.2.8.dfsg-5

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.28-4

-- no debconf information