aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2023-02-07T17:48:04Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12384mysqld consumes about 100% cpu when idle on arm v72023-02-07T17:48:04ZAndre Rmysqld consumes about 100% cpu when idle on arm v7Issue is also [filed in mariadb](https://jira.mariadb.org/browse/MDEV-24756)
Fresh alpine linux 3.13 container running on an arm v7 debian 10.7 host.
The following issue appeared with alpine 3.13 packing mariadb 10.5.8 (there is no iss...Issue is also [filed in mariadb](https://jira.mariadb.org/browse/MDEV-24756)
Fresh alpine linux 3.13 container running on an arm v7 debian 10.7 host.
The following issue appeared with alpine 3.13 packing mariadb 10.5.8 (there is no issue with alpine 3.12 and mariadb 10.4.x):
- On arm v7 (32 bits) mysqld consumes about 100% cpu when idle, but still works.
- On arm v8 (64 bits) or amd64, it consumes near 0% cpu when idle as expected.
I see only one difference in start logs (but that may be irrelevant):
- arm v7 : "Using generic crc32 instructions"
- arm v8 : "Using ARMv8 crc32 instructions"
Any idea why this happens and if there is an option in mysqld to circumvent the issue?
Steps to reproduce on a new alpine container:
```
~ # apk --update --upgrade add mariadb sudo
~ # mkdir /run/mysqld
~ # chown mysql:mysql /run/mysqld
~ # sudo -su mysql
~ $ mysql_install_db
~ $ mysqld --datadir=./data
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/11451main/openrc-0.42.1-r8 (possibly other versions) exports broken /etc/init.d/ru...2023-02-07T16:09:02Zopal hartgitlab.alpinelinux.org@wowana.memain/openrc-0.42.1-r8 (possibly other versions) exports broken /etc/init.d/runsvdirThe `openrc` package exports the service file `/etc/init.d/runsvdir` that has `command=/usr/bin/runsvdir`, which openrc does not provide. The `runit` package provides both `/etc/init.d/runitd` and `/sbin/runsvdir` files, so even with run...The `openrc` package exports the service file `/etc/init.d/runsvdir` that has `command=/usr/bin/runsvdir`, which openrc does not provide. The `runit` package provides both `/etc/init.d/runitd` and `/sbin/runsvdir` files, so even with runit installed, openrc's provided runsvdir service cannot be used out of the box.
I expect either openrc's runsvdir service to be removed, or for openrc to provide runsvdir. I'm biased toward the former solution because I don't think most people are going to think of OpenRC when they want this functionality that runsvdir provides.https://gitlab.alpinelinux.org/alpine/aports/-/issues/9260inefficient TLS access in mesa-gl due to workaround for upstream bug2023-02-07T15:55:22ZRich Felkerinefficient TLS access in mesa-gl due to workaround for upstream bugThe commit message here is wrong:
https://git.alpinelinux.org/cgit/aports/commit?id=f8b4641fcb29e11d4142e990427a6066ff693f41
The —disable-glx-tls workaround introduced in that commit uses
pthread\_key\_create/pthread\_\[gs\]etspecific ...The commit message here is wrong:
https://git.alpinelinux.org/cgit/aports/commit?id=f8b4641fcb29e11d4142e990427a6066ff693f41
The —disable-glx-tls workaround introduced in that commit uses
pthread\_key\_create/pthread\_\[gs\]etspecific to access the current GL
context, which is going to go through a couple layers of function calls,
and in principle could fail at runtime if too many keys were already
created when the library is loaded.
The root problem here is an upstream bug in mesa:
https://bugs.freedesktop.org/show\_bug.cgi?id=35268
The right fix is to patch out all instances of
*attribute*((*tls\_model*(“initial-exec”))) from mesa; this patch should
also be pushed upstream. The result will be very slightly (probably not
measurable) slower than with —enable-glx-tls (which only works when mesa
is directly linked, not dlopen’d), but should be a lot faster than with
—disable-glx-tls. It could be very slightly sped back up (probably as
fast as —enable-glx-tls) using TLSDESC (-mtls-dialect=gnu2) on archs
that support it (i386, x86\_64, aarch64, and in the future arm).
*(from redmine: issue id 9260, created on 2018-08-16)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/7580ioctl: overflow in implicit constant conversion2023-02-07T15:08:03Zalgitbotioctl: overflow in implicit constant conversionI’m compiling with `-Wall` on 3.6 and get
`overflow in implicit constant conversion` compiler warnings on some
`ioctl()` calls in my code.
Upon investigation, I found
int ioctl (int, int, ...)
in `/usr/include/sys/ioctl.h` and the...I’m compiling with `-Wall` on 3.6 and get
`overflow in implicit constant conversion` compiler warnings on some
`ioctl()` calls in my code.
Upon investigation, I found
int ioctl (int, int, ...)
in `/usr/include/sys/ioctl.h` and the following in
`/usr/include/bits/ioctl.h` (included by the former)
#define _IOC(a,b,c,d) ( ((a)<<30) | ((b)<<8) | (c) | ((d)<<16) )
#define _IOC_NONE 0U
#define _IOC_WRITE 1U
#define _IOC_READ 2U
#define _IO(a,b) _IOC(_IOC_NONE,(a),(b),0)
#define _IOW(a,b,c) _IOC(_IOC_WRITE,(a),(b),sizeof(c))
#define _IOR(a,b,c) _IOC(_IOC_READ,(a),(b),sizeof(c))
#define _IOWR(a,b,c) _IOC(_IOC_READ|_IOC_WRITE,(a),(b),sizeof(c))
If I am not mistaken and assuming a 32-bit `int`, that means that any
second argument passed to `ioctl()` that is created using the `_IOR` or
`_IOWR` macros will be an **unsigned** 32-bit integer with its most
significant bit set and will trigger the warning I observe.
I subscribe to AWARE (All Warnings Are Really Errors) and normally also
set `-Werror` so I really would like to get this fixed.
BTW, most other distributions I compile on define `ioctl()` as
int ioctl (int, unsigned long, ...)
and chaging your declaration to take an `unsigned int` “fixes” this for
me.
*(from redmine: issue id 7580, created on 2017-07-21)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9853lxdm does not restart, scritp are broken2023-02-07T15:07:40ZPICCORO Lenz McKAYlxdm does not restart, scritp are brokenthe lxdm package have buggy and uncomplete implementation..
if try to stop, does not property grab the status of proc:
<code class="text">
root@alpine:~/alpineinstalls/recetas$ rc-service lxdm restart
* Stopping lxdm ...
...the lxdm package have buggy and uncomplete implementation..
if try to stop, does not property grab the status of proc:
<code class="text">
root@alpine:~/alpineinstalls/recetas$ rc-service lxdm restart
* Stopping lxdm ...
* start-stop-daemon: 1 process refused to stop
* Failed to stop lxdm [ !! ]
* ERROR: lxdm failed to stop
root@alpine:~/alpineinstalls/recetas$ rc-service lxdm stop
* Stopping lxdm ...
* start-stop-daemon: 1 process refused to stop
* Failed to stop lxdm [ !! ]
* ERROR: lxdm failed to stop
</code>
as a suggestion must track all the recent patches in sf git lxde
repository and winbuntu patches to resolve it
*(from redmine: issue id 9853, created on 2019-01-13)*Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10356sudo do not respect environment variables for proxy2023-02-07T14:59:11ZOleg Titovsudo do not respect environment variables for proxyI have a setup with proxy enabled. Everything works fine in root shell
and for ordinary user.
Running \`sudo\` brings problem as the proxy corresponding environment
variables are not exported right.
To reproduce the problem I experienc...I have a setup with proxy enabled. Everything works fine in root shell
and for ordinary user.
Running \`sudo\` brings problem as the proxy corresponding environment
variables are not exported right.
To reproduce the problem I experience enable proxy and run \`sudo wget
www.google.com\`, it should block.
Typical problematic use cases are:
1. sudo apk update|upgrade|add
2. abuild -r
In both cases any web operations will be blocked as the proxy
configuration is missed.
A temporary workaround could be to use \`sudo -E\`. I was suggested to
edit /etc/sudoers to include http\_proxy variables.
I consider that setup-proxy could take care of this.
*(from redmine: issue id 10356, created on 2019-04-28)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13375community/apparmor: fix openssl and dovecot profile2023-02-07T13:31:51Zsuiong ngcommunity/apparmor: fix openssl and dovecot profile(1) /etc/apparmor.d/usr.sbin.dovecot
Alpine packages dovecot differently from other distros such as Arch. Several binaries are placed in /usr/libexec/dovecot/ instead of /usr/lib/dovecot/. Thus, upstream apparmor profile won't work. All...(1) /etc/apparmor.d/usr.sbin.dovecot
Alpine packages dovecot differently from other distros such as Arch. Several binaries are placed in /usr/libexec/dovecot/ instead of /usr/lib/dovecot/. Thus, upstream apparmor profile won't work. All executable entries with /usr/lib/dovecot/ should be replaced.
for example, this line in /etc/apparmor.d/usr.sbin.dovecot
/usr/lib/dovecot/auth mrPx,
should become
/usr/libexec/dovecot/auth mrPx,
(2) /etc/apparmor.d/usr.lib.dovecot.*
As mentioned in (1), other profiles confining /usr/libexec/dovecot/* binaries should also be renamed and have their content fixed.
for example,
/etc/apparmor.d/usr.lib.dovecot.anvil
should become
/etc/apparmor.d/usr.libexec.dovecot.anvil
to fix their content:
sed -e 's|/usr/lib/dovecot|/usr/libexec/dovecot|g' -i /etc/apparmor.d/usr.libexec.dovecot.*
(3) /etc/apparmor.d/abstractions/openssl
Alpine ships different openssl versions. So, this profile should also contain openssl 1.1.
This line should be added:
/etc/ssl1.1/openssl.cnf r,https://gitlab.alpinelinux.org/alpine/aports/-/issues/12194upx aarch64 support is required2023-02-07T13:22:55Ztim-oleksiiupx aarch64 support is requiredHello,
Can you please provide support of aarch64 for `upx` package? It seems that the tool does support aarch64
https://upx.github.io/main/2017/05/12/UPX-3.94-released.html
OleksiiHello,
Can you please provide support of aarch64 for `upx` package? It seems that the tool does support aarch64
https://upx.github.io/main/2017/05/12/UPX-3.94-released.html
Oleksiihttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12510Unsatisfiable constraints when adding g++62023-02-07T13:21:36ZercUnsatisfiable constraints when adding g++6It seems, for me, that the recipe for g++6 is broken. Here is how I reproduced.
Starting from a clean docker environment, when I try to `apk add g++6` it throws me the following error:
```
ERROR: unsatisfiable constraints:
libstdc++-9...It seems, for me, that the recipe for g++6 is broken. Here is how I reproduced.
Starting from a clean docker environment, when I try to `apk add g++6` it throws me the following error:
```
ERROR: unsatisfiable constraints:
libstdc++-9.3.0-r2:
breaks: g++6-6.4.0-r11[libstdc++=6.4.0-r11]
satisfies: gcc-9.3.0-r2[so:libstdc++.so.6] binutils-2.34-r1[so:libstdc++.so.6]
gcc-9.3.0-r2:
breaks: g++6-6.4.0-r11[gcc=6.4.0-r11]
```
Trying to understand what's happening, I've run the `apk dot g++6 gcc6` which gaves me the following graph:
![20210309155654_1047x707_scrot](/uploads/06facf3ce903fb9d70c59e292d261d47/20210309155654_1047x707_scrot.png)
The dependency line from `gcc6` to `binutils` to `libstdc++-10` caught my attention. As we can see, g++6 depends on libstdc++6, but `binutils` wants the latest version. Maybe `gcc6` should not depend on `binutils`?
Unfortunately I could not find the recipe of g++6, so I couldn't go any further. I'm still trying, if anyone wants to show me the right direction it would be very welcoming :)
Edit: I did find the recibe, it's the same of gcc6. But still, I could not find how to test it without a whole ready environment. Unfortunately I can't help much for now. I'll move on with another distro, but I'll keep an eye on this to try again later.Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13016"apk" give "Illegal instruction" in x86 edge on vortex86 device.2023-02-07T11:49:41ZThorbjørn Ravn Andersen"apk" give "Illegal instruction" in x86 edge on vortex86 device.We need to deploy Alpine Linux on vortex86 devices and since I used edge the last time about a month ago something has happened.
```
device-001beb6a7a42:~# gdb /sbin/apk
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, In...We need to deploy Alpine Linux on vortex86 devices and since I used edge the last time about a month ago something has happened.
```
device-001beb6a7a42:~# gdb /sbin/apk
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i586-alpine-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /sbin/apk...
(No debugging symbols found in /sbin/apk)
(gdb) run
Starting program: /sbin/apk
Program received signal SIGILL, Illegal instruction.
0xb7d312d0 in ?? () from /lib/libcrypto.so.3
(gdb)
```
Device type number one (which is what I saw the error on).
```
device-444d50627512:~# cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 9
model name : VIA Nehemiah
stepping : 10
cpu MHz : 530.989
cache size : 64 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse cpuid rng rng_en ace ace_en
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips : 1062.22
clflush size : 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
power management:
```
Other device (copied from https://gitlab.alpinelinux.org/alpine/aports/-/issues/12934) which I have not verified the bug on yet.
```
processor : 0
vendor_id : Vortex86 SoC
cpu family : 5
model : 2
model name : 05/02
stepping : 2
cpu MHz : 799.972
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu tsc cx8 cpuid
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips : 1600.60
clflush size : 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
power management:
```
Please advisehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11652community/gnome Notification banner fails to show after inserting usb storage...2023-01-29T20:59:04Zkeshtocommunity/gnome Notification banner fails to show after inserting usb storage device1. install `apk add gnome gdm udisks2 gvfs`
2. login via gdm
3. `notify-send "test"` will show a notification banner with the text "test"
4. plug in a usb mass storage device
5. repeat step 3. Notice that there is no notification banner ...1. install `apk add gnome gdm udisks2 gvfs`
2. login via gdm
3. `notify-send "test"` will show a notification banner with the text "test"
4. plug in a usb mass storage device
5. repeat step 3. Notice that there is no notification banner (or any banners from anywhere until relogin)
Other notes:
- Sound in general is also showing weird behavior. Sometimes when relogin there is no sound until pulse-daemon is killed. However, this is not reproducible easily like the above issue.
- Notifications can be seen when clicking and looking at the notification area [click time date middle of top bar and see list of notifications there].Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/1234[v2.5] Multiple vulnerabilities in xen 4.1.2 and earlier may allow privilege ...2023-01-17T19:57:22ZLeonardo Arena[v2.5] Multiple vulnerabilities in xen 4.1.2 and earlier may allow privilege escalationhttp://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0217
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0218
http://cve.mitre.org/cgi-bin/cvename.cgi?...http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0217
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0218
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2934
\- Patches available at the first link
*(from redmine: issue id 1234, created on 2012-07-01, closed on 2012-07-03)*Alpine 2.5.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/16Package 'transmission-1.51-r0' contains deprecated .INSTALL2023-01-08T23:59:22ZNatanael CopaPackage 'transmission-1.51-r0' contains deprecated .INSTALLShould be converted to new style pre/post-install
*(from redmine: issue id 16, created on 2009-03-24, closed on 2009-03-26)*
* Changesets:
* Revision bbd7886cd79ad2060c9199c768991035228905f7 by Carlo Landmeter on 2009-03-25T21:46:06...Should be converted to new style pre/post-install
*(from redmine: issue id 16, created on 2009-03-24, closed on 2009-03-26)*
* Changesets:
* Revision bbd7886cd79ad2060c9199c768991035228905f7 by Carlo Landmeter on 2009-03-25T21:46:06Z:
```
extra/transmission: updated install file to new style.
fixes #16
```Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/33/var/log/lastlog missing2023-01-08T23:59:22ZLeonardo Arena/var/log/lastlog missingssh daemon starting up gives this error:
lastlog\_openseek: Couldn’t stat /var/log/lastlog:No such file or
directory
*(from redmine: issue id 33, created on 2009-05-18, closed on 2009-06-23)*
* Changesets:
* Revision abeb4645b5f35b...ssh daemon starting up gives this error:
lastlog\_openseek: Couldn’t stat /var/log/lastlog:No such file or
directory
*(from redmine: issue id 33, created on 2009-05-18, closed on 2009-06-23)*
* Changesets:
* Revision abeb4645b5f35bfe0876adebe89838e0b39bf471 on 2009-05-18T12:34:26Z:
```
core/openssh: disable lastlog
fixes #33
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/30Alpine_1.9alpha9 - Postfix should use '/usr/lib/postfix' instead of '/usr/lib...2023-01-08T23:59:21ZMika HavelaAlpine_1.9alpha9 - Postfix should use '/usr/lib/postfix' instead of '/usr/libexec/postfix'Reasons are:
- FHS
(http://www.pathname.com/fhs/pub/fhs-2.3.html\#USRLIBLIBRARIESFORPROGRAMMINGANDPA)
- Compability
*(from redmine: issue id 30, created on 2009-05-14, closed on 2009-05-14)*
* Changesets:
* Revision b846d7e...Reasons are:
- FHS
(http://www.pathname.com/fhs/pub/fhs-2.3.html\#USRLIBLIBRARIESFORPROGRAMMINGANDPA)
- Compability
*(from redmine: issue id 30, created on 2009-05-14, closed on 2009-05-14)*
* Changesets:
* Revision b846d7e6a255de4c6ad97c536e0093952abca2f1 on 2009-05-14T12:23:53Z:
```
extra/postfix: use /usr/lib/postfix instead of /usr/libexec/postfix
fixes #30
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/311.9alpha10 - Can not mount floppy2023-01-08T23:59:21ZMika Havela1.9alpha10 - Can not mount floppySeems floppy module is not loaded at boot
*(from redmine: issue id 31, created on 2009-05-16, closed on 2009-05-20)*Seems floppy module is not loaded at boot
*(from redmine: issue id 31, created on 2009-05-16, closed on 2009-05-20)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/13359community/libreoffice: pyuno path not set [HASFIX]2023-01-07T04:36:14Ztobwencommunity/libreoffice: pyuno path not set [HASFIX]## issue
pyUNO is neither installed to _site-packages_ no to _dist-packages_.
## error
``` python
>>> import uno
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'uno'
```
##...## issue
pyUNO is neither installed to _site-packages_ no to _dist-packages_.
## error
``` python
>>> import uno
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'uno'
```
## fix
Do it the Debian way:
* copy the needed files to _site-packages_
* point to the LO's program path
``` shell
# define path
PATH_LO=/usr/lib/libreoffice/program
PATH_SP=/usr/lib/python3.10/site-packages
# copy unohelper.py
cp "$PATH_LO"/unohelper.py "$PATH_SP"/
# prefix path to uno.py
cat << EOF > "$PATH_SP"/uno.py
import sys, os
sys.path.append('/usr/lib/libreoffice/program')
os.putenv('URE_BOOTSTRAP', 'vnd.sun.star.pathname:/usr/lib/libreoffice/program/fundamentalrc')
EOF
# copy the original's content
cat "$PATH_LO"/uno.py >> "$PATH_SP"/uno.py
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/9112nagios-plugins-mailq comes with broken shebang and lacks perl dependency2022-12-30T11:15:52ZMarco Dickertnagios-plugins-mailq comes with broken shebang and lacks perl dependencyI noticed two problems with the nagios-plugins-mailq packet in v3.8.1
and edge.
1. The script check\_mailq has a broken magic line:
#! -w
2. The packet does not depend on perl, although check\_mailq is a perl
script.
*(from redm...I noticed two problems with the nagios-plugins-mailq packet in v3.8.1
and edge.
1. The script check\_mailq has a broken magic line:
#! -w
2. The packet does not depend on perl, although check\_mailq is a perl
script.
*(from redmine: issue id 9112, created on 2018-07-19)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/11979main/ruby: deadlock in test suite2022-12-30T10:14:35ZKevin Daudtmain/ruby: deadlock in test suiteThe ruby test suite deadlocks due to using async unsafe functions after fork. The test suite has been temporarily disabled.
Upstream bug: https://bugs.ruby-lang.org/issues/17189The ruby test suite deadlocks due to using async unsafe functions after fork. The test suite has been temporarily disabled.
Upstream bug: https://bugs.ruby-lang.org/issues/17189https://gitlab.alpinelinux.org/alpine/aports/-/issues/10304Missing libasan2022-12-20T22:43:30ZSerhii CharykovMissing libasanI use docker image and cannot build simple C/C<span
class="underline"></span> program with option: -fsanitize=address
I’ve checked several image version and have not find any package that
resembles libasan or has libasan\*.so.
Steps t...I use docker image and cannot build simple C/C<span
class="underline"></span> program with option: -fsanitize=address
I’ve checked several image version and have not find any package that
resembles libasan or has libasan\*.so.
Steps to reproduce:
docker run -it —rm alpine
apk add gcc musl-dev
echo “int main() {}” >test.c
gcc test.c -fsanitize=address
Result:
/usr/lib/gcc/x86\_64-alpine-linux-musl/8.3.0/../../../../x86\_64-alpine-linux-musl/bin/ld:
cannot find libasan\_preinit.o: No such file or directory
/usr/lib/gcc/x86\_64-alpine-linux-musl/8.3.0/../../../../x86\_64-alpine-linux-musl/bin/ld:
cannot find -lasan
collect2: error: ld returned 1 exit status
*(from redmine: issue id 10304, created on 2019-04-19, closed on 2019-05-06)*3.9.4