gentoo / musl Goto Github PK

nfct-daemon.c:22:10: fatal error: 'sys/queue.h' file not found
#include <sys/queue.h>
         ^~~~~~~~~~~~~

Updates: Missing <sys/select.h> in examples/netfilter/nfct-daemon.c

diff --git a/examples/netfilter/nfct-daemon.c b/examples/netfilter/nfct-daemon.c
index a97c2ec..4e93e47 100644
--- a/examples/netfilter/nfct-daemon.c
+++ b/examples/netfilter/nfct-daemon.c
@@ -20,6 +20,7 @@
 #include <linux/netfilter/nfnetlink_conntrack.h>
 
 #include <sys/queue.h>
+#include <sys/select.h>
 
 struct nstats {
 	LIST_ENTRY(nstats)	list;

https://bugs.gentoo.org/643742

This is an easy fix, something along the lines of this must be added to the gentoo/gentoo compiler-rt ebuild.

post_pkg_postinst() {
        ln -sf /usr/lib/clang/${PV}/lib/linux/libclang_rt.builtins-x86_64.a ${ROOT}/usr/lib/libcompiler_rt.a
}

ppp-2.4.7-r99-build.log.txt

crypto.c:969:74: error: missing field 'veracrypt_pim' initializer [-Werror,-Wmissing-field-initializers]
    struct crypt_params_tcrypt params = {NULL,0,NULL,0,NULL,NULL,NULL,0,0};

Issue resolved by adding another 0 parameter on the end;

    struct crypt_params_tcrypt params = {NULL,0,NULL,0,NULL,NULL,NULL,0,0,0};

postfix builds without problems, but when used with a milter or its postscreen utility, it fails at runtime with the following error:

warning: unix_send_fd: your system has no support for file descriptor passing
warning: pass_accept_attr: cannot receive file descriptor: No error information
error: accept connection: No error information

sys_defs.h checks for file descriptor support like this, assuming that __GLIBC__ is defined:

 #if (LINUX_VERSION_CODE < KERNEL_VERSION(2,2,0)) || (__GLIBC__ < 2)

To make this work with musl, the following patch is needed:

--- postfix-3.1.2-r2/src/util/sys_defs.h 2017-06-05 02:46:02.016419848 +0000
+++ src/util/sys_defs.h	2017-06-05 02:46:37.275600185 +0000
@@ -813,7 +813,7 @@
 #define KERNEL_VERSION(a,b,c) (LINUX_VERSION_CODE + 1)
 #endif
 #if (LINUX_VERSION_CODE < KERNEL_VERSION(2,2,0)) \
-	|| (__GLIBC__ < 2)
+	|| (defined(__GLIBC__) && (__GLIBC__ < 2))
 #define CANT_USE_SEND_RECV_MSG
 #define DEF_SMTP_CACHE_DEMAND	0
 #else

See also this bug for Alpine Linux.

The ebuild for app-emulation/qemu-2.8.0-r7 is broken because there is a missing file. It tries to generate an init script by concatenating files, but they are missing.

https://github.com/gentoo/musl/blob/master/app-emulation/qemu/qemu-2.8.0-r7.ebuild#L625

Hi,

Tried to compile sys-libs/pam-1.2.1 (as part of running emerge -uDU --with-bdeps=y @world during initial system setup using a Stage3 tarball) and it returned: https://paste.pound-python.org/show/6PsAuc2MBgaC60wY4aL4/. My emerge --info '=sys-libs/pam-1.2.1::musl' output is https://paste.pound-python.org/show/CluNDBoMSzmfhME64B0Z/. emerge -pqv '=sys-libs/pam-1.2.1::musl' returns:

[ebuild   R   ] sys-libs/pam-1.2.1 [1.2.1] USE="cracklib nls pie -audit -berkdb* -debug -nis (-selinux) {-test} -vim-syntax" 

The exact error seems to be:

libtool: link: x86_64-pc-linux-gnu-gcc -shared  -fPIC -DPIC  .libs/pam_pwhistory.o .libs/opasswd.o   -Wl,-rpath -Wl,/var/tmp/portage/sys-libs/pam-1.2.1/work/Linux-PAM-1.2.1-abi_x86_64.amd64/libpam/.libs -Wl,--as-needed ../../libpam/.libs/libpam.so -ldl  -O2 -Wl,--version-script=/var/tmp/portage/sys-libs/pam-1.2.1/work/Linux-PAM-1.2.1/modules/pam_pwhistory/../modules.map -Wl,-O1 -Wl,--no-undefined -Wl,-O1   -Wl,-soname -Wl,pam_pwhistory.so -o .libs/pam_pwhistory.so
.libs/opasswd.o: In function `check_old_pass':
opasswd.c:(.text+0x278): undefined reference to `crypt'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:652: pam_pwhistory.la] Error 1
make[3]: Leaving directory '/var/tmp/portage/sys-libs/pam-1.2.1/work/Linux-PAM-1.2.1-abi_x86_64.amd64/modules/pam_pwhistory'
make[2]: *** [Makefile:422: all-recursive] Error 1
make[2]: Leaving directory '/var/tmp/portage/sys-libs/pam-1.2.1/work/Linux-PAM-1.2.1-abi_x86_64.amd64/modules'
make[1]: *** [Makefile:471: all-recursive] Error 1
make[1]: Leaving directory '/var/tmp/portage/sys-libs/pam-1.2.1/work/Linux-PAM-1.2.1-abi_x86_64.amd64'
make: *** [Makefile:402: all] Error 2

if there's some info I can provide that I'm missing please tell me as I would like to get this compile error resolved.

Thanks for your time,
Brenton

2 patch to check, I could emerge apparmor but aren't sure that they are both ok for a pull.

{ Deleted, those patch aren't good }

Thanks

If I chose ACCEPT_KEYWORDS="~amd64"
Then portage tries to install lastest testing version which is in main repository, not in musl.
How to add priority to musl over lastest versions of pascages in main repo?

Clang's compiler header <stddef.h> contains typedefs which conflict with musl's <bits/alltypes.h>. This is fixed by making the relevant typedef guards consistent between the two header files as in this patch.

The compilation issues for net-misc/iputils have been solved with recent 20171016_pre, but according to https://bugs.gentoo.org/604542 the idn part still doesn't seem to work. Quote from the bug:
ATM, musl release is 1.1.18, and support for IDN is now expected for 1.1.20. Consequently, iputils are still unusable when compiled with idn USE flag, due to lack of support in musl

So I think this is so horribly broken, it should be masked until musl 1.1.20 get's shipped, right?

Hello,

Nice to see apparmor into the musl repo, however I could not make the build on my system :

https://paste.pound-python.org/show/h33LuYuziQXGxTXIFMQi/

Thanks

Hello,

Would like to known what should be do when a ebuild stable isn't working with musl but the ~amd64 (not stable one) work just fine.

Example

net-analyzer/traceroute stable (2.0.20) have a lot of issue (AI_IDN, header to fix...) but the 2.1.0 is perfect.

I would like to have portage to pickup automatically the 2.1.0 with the [1] "musl" showed, how this work ? should I simply commit the ebuild in this repo or there is another way to define which version to pickup for musl ?

Thanks

commit d9d1068 stabilized linux-headers-4.14. this broke sys-apps/net-tools. i tried to compensate by c235bfe where i stabilized the overlay version of sys-apps/net-tools. this worked in one environment but not in catalyst.

as a result, stage3 builds are currently broken. i don't have time to debug this now but it has to be fixed asap. if we can't resolve this soon, i will have to do a lot of reverting. i will by jan 10, 2018 if we can't fix this.

i would ask that people please test commits to make sure they don't break stage3 builds. be careful with any @System packages. i'm not as picky about non @System so don't worry if you break those, but if you break @System, then i'll be sad.

So it turns out in liblibc in rust for musl amd64 and in the musl amd64 C headers, struct cmsghdr is defined something like this:

struct cmsghdr {
	socklen_t cmsg_len;
	int __pad1;
	int cmsg_level;
	int cmsg_type;
};

Unfortunately all other linux arches that use cmsghdr lack the __pad1 field.

In firefox 60.0, media/audioipc/audioipc/src/cmsg.rs, the cmsghdr struct is initialized but it doesn't supply a default value for __pad1, so the build fails:

26:58.52    Compiling audioipc v0.2.1 (file:///var/tmp/portage/www-client/firefox-60.0/work/firefox-60.0/media/audioipc/audioipc)
26:59.51 error[E0063]: missing field `__pad1` in initializer of `libc::cmsghdr`
26:59.52    --> media/audioipc/audioipc/src/cmsg.rs:109:27
26:59.52     |
26:59.52 109 |             let cmsghdr = cmsghdr {
26:59.52     |                           ^^^^^^^ missing `__pad1`
26:59.52
27:00.56 error: aborting due to previous error
27:00.56
27:00.64 error: Could not compile `audioipc`.
27:00.64 warning: build failed, waiting for other jobs to finish...
27:23.34 error: build failed

Do we need to patch liblibc in rust or is it possible to fix this in firefox without breaking support for other arches? I'm not super familiar with rust.

@blueness
The version of elfutils in this overlay seems to work fine, should we just leave an issue here as a disclaimer, or should we override the virtual with a virtual in this overlay?

dev-libs/libelf and dev-libs/elfutils do provide different SONAME's..

Specifically it uses FTW_ACTIONRETVAL and others which do not exist in musl libc.

Some rewriting may be required.

Verifying ebuild manifests

Emerging (1 of 1) sys-libs/gpm-1.20.7-r2::musl

• gpm-1.20.7.tar.lzma SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]
• gpm-1.20.7-docs.patch.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]

Unpacking source...
Unpacking gpm-1.20.7.tar.lzma to /var/tmp/portage/sys-libs/gpm-1.20.7-r2/work
Unpacking gpm-1.20.7-docs.patch.xz to /var/tmp/portage/sys-libs/gpm-1.20.7-r2/work
Source unpacked in /var/tmp/portage/sys-libs/gpm-1.20.7-r2/work
Preparing source in /var/tmp/portage/sys-libs/gpm-1.20.7-r2/work/gpm-1.20.7 ...

• Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is:

• /var/tmp/portage/sys-libs/gpm-1.20.7-r2/files/gpm-1.20.7-sysmacros.patch

• ( gpm-1.20.7-sysmacros.patch )

• ERROR: sys-libs/gpm-1.20.7-r2::musl failed (prepare phase):

• Cannot find $EPATCH_SOURCE!

• Call stack:

• ebuild.sh, line  124:  Called src_prepare
  

• environment, line 2787: Called epatch '/var/tmp/portage/sys-libs/gpm-1.20.7-r2/files/gpm-1.20.7-sysmacros.patch'

• environment, line 946: Called die

• The specific snippet of code:

•               die "Cannot find \$EPATCH_SOURCE!";
  

• If you need support, post the output of emerge --info '=sys-libs/gpm-1.20.7-r2::musl',

• the complete build log and the output of emerge -pqv '=sys-libs/gpm-1.20.7-r2::musl'.

• The complete build log is located at '/var/tmp/portage/sys-libs/gpm-1.20.7-r2/temp/build.log'.

• The ebuild environment file is located at '/var/tmp/portage/sys-libs/gpm-1.20.7-r2/temp/environment'.

• Working directory: '/var/tmp/portage/sys-libs/gpm-1.20.7-r2/work/gpm-1.20.7'

• S: '/var/tmp/portage/sys-libs/gpm-1.20.7-r2/work/gpm-1.20.7'

amd64 keyworded dracut::musl fails to build with amd64 keyworded fts-standalone-0.2-r1::gentoo, because that version of fts-standalone does not provide pkgconfig file.

bullds fine with fts-standalone-1.2.7::gentoo tho (which is ~amd64) as it does provide pkgconfig file.

No logs this time, sorry.

Not sure how to deal with cross-repo keywording and on musl in general.
My guess is that fts-standalone-1.2.7::gentoo needs stable keyword for amd64 or 0.2-r1 needs to provide a .pc file.

Here are a bunch of patches that I used to compile MATE on my musl system, all placed in my /etc/portage/patches directory. Fixes all the packages required by mate-base/mate, and a few other scattered GNOME dependencies (from when I tried to compile gnome, which was a disaster).

Link: patches.zip

Contains the following:

app-text/enchant
mate-extra/mate-power-manager
net-dialup/ppp
net-libs/libndp
net-libs/libqmi
sys-auth/elogind
sys-fs/udisks
sys-libs/libblockdev
x11-wm/marco

Note: net-dialup/ppp is already in the musl overlay, but still does not compile for me without the given patch

Hello,
building efibootmgr fails:

In file included from /usr/include/stdlib.h:19:0,
                 from unparse_path.c:26:
/usr/include/bits/alltypes.h:18:13: error: conflicting types for ‘wchar_t’
 typedef int wchar_t;
             ^
In file included from unparse_path.c:24:0:
/usr/lib/gcc/x86_64-gentoo-linux-musl/4.9.4/include/stddef.h:324:24: note: previous declaration of ‘wchar_t’ was here
 typedef __WCHAR_TYPE__ wchar_t;

However, removing -fshort-wchar from Make.defaults fixes it (basically the same thing as https://cgit.gentoo.org/proj/musl.git/tree/sys-libs/efivar/files/0.21-musl.patch?id=72d39834f513ed0ec6d4c3030f8bce402e71d236)

used to need this to compile mesa-9999 version but applying this patch broke recently

as of today, the patches on the overlay does not apply due to changes on the source even alpine musl-fixes doesn't apply and gets rejected on emerging so im opening a bug on their bugzilla

im posting this here to make you guys aware of the status of mesa-git, which is not passing with musl at least on my usecase (radeonsi)
i have checked with VIDEO_CARDS=intel i965 and it does sucessfully compile

Steps to reproduce:

• policy: mcs (with strict too)
• sys-libs/libsemanage-2.7
• musl as libc

# semodule -B -vv
Committing changes:
libsemanage.semanage_direct_commit: semanage_genhomedircon returned error code -1.
semodule:  Failed!

As workaround I set disable-genhomedircon=true at /etc/selinux/semanage.conf. But users home directory context are wrong.

Hi,
I can't compile kodi, looks like there is problem at stage:
[ 2%] Built target dvdread

Why gentoo tries to build dvd module when i have -dvd in use flags?
[ebuild N ] media-tv/kodi-17.3-r1::gentoo USE="X alsa dbus libressl opengl pulseaudio (system-ffmpeg) udev udisks vaapi xslt -airplay -bluetooth -bluray -caps -cec -css -debug -dvd -gles -java -libusb -lirc -mysql -nfs -nonfree -samba -sftp (-systemd) {-test} -upnp -upower (-vdpau) -webserver -zeroconf" PYTHON_TARGETS="python2_7" 0 KiB

Here is my compilation output: link

There is one error during compilation:
error: unknown type name ‘__off_t’; did you mean ‘off_t’? .
I tried to compile it with _LARGEFILE64_SOURCE as suggested at stack overflow thread.
But it doesn't work for me.

Do you know any way to compile kodi?

After recently news of Grsecurity: Passing the Baton I choose to move from RBAC to Selinux.

I'm using musl profile:

# eselect profile list
Available profile symlink targets:
...
  [17]  hardened/linux/musl/amd64 *
...

I copy files from /usr/portage/profiles/features/selinux/ to /etc/portage/profile/ to get selinux profile with musl.

But when I try to rebuild world, I got dependancy from glibc:

The following mask changes are necessary to proceed:
 (see "package.unmask" in the portage(5) man page for more details)
# required by sys-apps/policycoreutils-2.6-r1::gentoo
# required by sec-policy/selinux-sasl-2.20170204-r2::gentoo
# required by dev-libs/cyrus-sasl-2.1.26-r9::gentoo
# required by mail-mta/exim-4.88::gentoo[sasl]
# required by @selected
# required by @world (argument)
# /usr/portage/profiles/hardened/linux/musl/package.mask:
=sys-libs/glibc-2.23-r3

I think SELinux must to work with musl because no other good MAC alternative exists.

With the update to sys-kernel/linux-headers to 4.13, chrony enables HAVE_LINUX_TIMESTAMPING_OPT_PKTINFO based on the existence of SOF_TIMESTAMPING_OPT_PKTINFO in the kernel headers.

This feature requires SCM_TIMESTAMPING_PKTINFO in socket.h, which current musl (1.1.18) is missing. As of Nov 05 2017, the development version of musl contains this macro (see here).

I have come across a fix that defines the macro in the chrony sources here.

musl doesn't provide this because it isn't posix compliant and would require reliance on a certain kind of pthread structure.

At the moment I'm not sure how to fix this.

Topic regarding the problem

https://forums.gentoo.org/viewtopic-p-8196860.html

Here what I purpose

qbittorrent-4.0.4-musl.patch.txt

qbittorrent-4.0.4.ebuild.txt

Hope it's help

I have a stupid script that masks every package in ::gentoo that is also in ::musl
Makes updating much easier when package in gentoo gets an update and it's not backported yet.

That way portage always picks ::musl version.

#!/bin/bash
set -euo pipefail
IFS=$'\n\t'
truncate --size=0 /etc/portage/package.mask/musl.conf
for atom in $(qatom -F '%{CATEGORY}/%{PN}' $(portageq --no-filters --repo musl) | sort -u);
	do printf "%s::gentoo\n" "$atom" >> /etc/portage/package.mask/musl.conf;
done

One can put this into /etc/portage/repo.postsync.d
Of course the script is just an example, it should be improved.

Any thoughts on this? Can and should something like this be used for this repo?

This is in 3.3.0_rc1

It depends on both libc headers such as <arpa/inet.h> and those included by the kernel, such as <linux/if.h>, and I'm not entirely sure how to get it to build.

I've been maintaining a lot of patches over here:
https://github.com/lluixhi/musl-extras

And I'm wondering what the easiest way to get them merged in would be.

I'm using two chroots to test both glibc and musl stuff for arm. Recently I could not build gcc-5.4.0-r3 because there is only one Gigabyte of Ram on the device, which is not enough to build genautomata. This issue was adressed in #56 , and while the same patch works fine for a glibc based gcc, it does not fully work for the musl based one.

glibc chroot with the patch from #56 : 3 jobs on 4 cores, 5 hrs 54 minutes
musl chroot with the patch from #56 : fails with 3 jobs, fails with 2 jobs, works with 1 job and takes 12 hrs 40 minutes

they both fail without the patch due to out of memory errors.

I found a patch for gcc to solve this issue for both genautomata and genattrtab

https://patchwork.ozlabs.org/patch/695293/

but I am not very certain if this can be backported? The patch got merged into gcc-7 , it can be applied to gcc-6.3.0 without problems, but I don't know if this means it will work as expected on gcc-7? The patch fails hard for gcc-5.4.0-r3, I doubt it would be possible to safely backport it, would it?

Hiya,

I'm just trying to emerge net-tools into a new stage 3 musl install (on ~amd64 globally) and it's failing to build with both clang and gcc. I can't quite piece together why it's doing so ;)

Here is the build log: https://bpaste.net/show/39b6cf916f03

And here is are my compile settings: https://bpaste.net/show/b3f686edf50b

I'm using libressl as well if that helps - Cheers!

recently upstream has anounced some major changes

• cairo-gtk2 will not be supported from >=firefox-53.0 on
• alsa will not be supported anymore (I believe from 52.0-esr on?)

these both seem to be minor problems, gentoo-dev's are aware of it as far as I know.

• dev-lang/rust will be a hard dependency from 54.0 on, according to https://bugzilla.mozilla.org/show_bug.cgi?id=1284816

@lluixhi - any progress in bootstrapping from a musl toolchain? It seems to depend on llvm-4 and clang, and cargo as well? I'd be happy to help out with compile and runtime testing.

Hi,
I have problem with VIDEO_CARDS option with hardened/linux/musl/amd64 profile.
>eselect profile list

When I don't set VIDEO_CARDS option in make.conf then emerge --info return VIDEO_CARDS="dummy fbdev v4l"

>cat /etc/portage/make.conf
>emerge --info

But when I set VIDEO_CARDS="i965 intel" option in make.conf then VIDEO_CARDS option disappeared from emerge --info.

>cat /etc/portage/make.conf
>emerge --info

My temporary solution is to edit /usr/portage/profiles/arch/base/use.mask
and change lines 141,142:

video_cards_i965
video_cards_intel

into:

-video_cards_i965
-video_cards_intel

After these changes, VIDEO_CARDS="i965 intel" is reported by emerge --info.

I think that VIDEO_CARDS is somehow masked by musl profile, do you have idea how to fix it?
Or can you provide permanent workaround?

Hi there,

I have successfully compiled compiler-rt-sanitizers on hardened/musl with the following patch [1].
Would be nice to push that to the overlay.

[1] https://gist.github.com/anonymous/92df175ea663004c5055bd6085476a70

It seems something in mesa must've broken -- presumably with musl, as applications that use OpenGL are segfaulting.

This isn't a problem pre-18.1.0

This is a problem if the build system does not have much ram per thread, or not much in general, or for a possible debug build. I did a bit of research, pullrequest #95 does have the results. For dev-util/cargo the problem has been solved, for dev-lang/rust it has been mitigated by a lot in restricting ./x.py

What is left to be dealt with is the minimal bootstrap between src_configure and the execution of ./x.py ; did a reasonable amount of research about what is going on there, but found nothing helpfull in terms of restricting the jobs, or even make them honor the MAKEOPTS from make.conf

Therefore, I think it should be okay to commit the pullrequest to the overlay, and to pick up the rest of the problem later on.

core/ -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -march=skylake -O2 -pipe -Wall -DSOCKS -c -o irssi.o irssi.c
irssi.c: In function ‘main’:
irssi.c:293:2: warning: implicit declaration of function ‘SOCKSinit’ [-Wimplicit-function-declaration]
SOCKSinit(argv[0]);
^~~~~~~~~
x86_64-gentoo-linux-musl-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src -I../../src/core/ -I../../src/fe-common/core/ -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -march=skylake -O2 -pipe -Wall -DSOCKS -c -o module-formats.o module-formats.c
/bin/sh ../../libtool --tag=CC --mode=link x86_64-gentoo-linux-musl-gcc -march=skylake -O2 -pipe -Wall -DSOCKS -export-dynamic -Wl,-O1 -Wl,--as-needed -o irssi gui-entry.o gui-expandos.o gui-printtext.o gui-readline.o gui-windows.o lastlog.o mainwindows.o mainwindow-activity.o mainwindows-layout.o statusbar.o statusbar-config.o statusbar-items.o term.o term-terminfo.o terminfo-core.o textbuffer.o textbuffer-commands.o textbuffer-view.o irssi.o module-formats.o ../fe-common/irc/libfe_common_irc.a ../fe-common/irc/dcc/libfe_irc_dcc.a ../fe-common/irc/notifylist/libfe_irc_notifylist.a ../fe-common/core/libfe_common_core.a ../irc/libirc.a ../irc/core/libirc_core.a ../irc/dcc/libirc_dcc.a ../irc/flood/libirc_flood.a ../irc/notifylist/libirc_notifylist.a ../core/libcore.a ../lib-config/libirssi_config.a -lsocks -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lssl -lcrypto -lncursesw
libtool: link: x86_64-gentoo-linux-musl-gcc -march=skylake -O2 -pipe -Wall -DSOCKS -Wl,-O1 -Wl,--as-needed -o irssi gui-entry.o gui-expandos.o gui-printtext.o gui-readline.o gui-windows.o lastlog.o mainwindows.o mainwindow-activity.o mainwindows-layout.o statusbar.o statusbar-config.o statusbar-items.o term.o term-terminfo.o terminfo-core.o textbuffer.o textbuffer-commands.o textbuffer-view.o irssi.o module-formats.o -Wl,--export-dynamic -pthread -Wl,--export-dynamic ../fe-common/irc/libfe_common_irc.a ../fe-common/irc/dcc/libfe_irc_dcc.a ../fe-common/irc/notifylist/libfe_irc_notifylist.a ../fe-common/core/libfe_common_core.a ../irc/libirc.a ../irc/core/libirc_core.a ../irc/dcc/libirc_dcc.a ../irc/flood/libirc_flood.a ../irc/notifylist/libirc_notifylist.a ../core/libcore.a ../lib-config/libirssi_config.a -lsocks -lgmodule-2.0 -lglib-2.0 -lssl -lcrypto -lncursesw -pthread
/usr/lib/gcc/x86_64-gentoo-linux-musl/6.4.0/../../../libsocks.so: undefined reference to `bindresvport'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:525: irssi] Error 1
make[3]: Leaving directory '/var/tmp/portage/net-irc/irssi-1.1.1/work/irssi-1.1.1/src/fe-text'
make[2]: *** [Makefile:445: all-recursive] Error 1
make[2]: Leaving directory '/var/tmp/portage/net-irc/irssi-1.1.1/work/irssi-1.1.1/src'
make[1]: *** [Makefile:543: all-recursive] Error 1
make[1]: Leaving directory '/var/tmp/portage/net-irc/irssi-1.1.1/work/irssi-1.1.1'
make: *** [Makefile:423: all] Error 2

• ERROR: net-irc/irssi-1.1.1::gentoo failed (compile phase):
• emake failed

Any idea ?

https://github.com/lluixhi/musl-extras
musl-extras has support for wayland, weston, chromium, gcc 6.1 and much more

The webkit-gtk ebuild can't successfully start compiling it, as it's trying to find a missing patch. See: https://github.com/gentoo/musl/blob/master/net-libs/webkit-gtk/webkit-gtk-2.16.2.ebuild#L133

mesa-17-musl_endian.patch correctly applies to 17.2.8, but not to 17.3.8 which is the current stable, breaking builds that need mesa.

Appending /home/blueness/REPOSITORIES/GIT/musl to PORTDIR_OVERLAY...
 * mesa-17.3.8.tar.xz BLAKE2B SHA512 size ;-) ...                                                                                                                                                    [ ok ]
>>> Unpacking source...
>>> Unpacking mesa-17.3.8.tar.xz to /var/tmp/portage/media-libs/mesa-17.3.8/work
>>> Source unpacked in /var/tmp/portage/media-libs/mesa-17.3.8/work
>>> Preparing source in /var/tmp/portage/media-libs/mesa-17.3.8/work/mesa-17.3.8 ...
 * Applying mesa-17-musl_endian.patch ...
1 out of 1 hunk FAILED -- saving rejects to file src/util/u_endian.h.rej                                                                                                                             [ !! ]
 * ERROR: media-libs/mesa-17.3.8::musl failed (prepare phase):
 *   patch -p1  failed with /var/tmp/portage/media-libs/mesa-17.3.8/files/mesa-17-musl_endian.patch
 * 
 * Call stack:
 *               ebuild.sh, line  124:  Called src_prepare
 *             environment, line 3461:  Called eapply '/var/tmp/portage/media-libs/mesa-17.3.8/files/mesa-17-musl_endian.patch'
 *             environment, line 1229:  Called _eapply_patch '/var/tmp/portage/media-libs/mesa-17.3.8/files/mesa-17-musl_endian.patch'
 *             environment, line 1167:  Called __helpers_die 'patch -p1  failed with /var/tmp/portage/media-libs/mesa-17.3.8/files/mesa-17-musl_endian.patch'
 *   isolated-functions.sh, line  117:  Called die
 * The specific snippet of code:
 *   		die "$@"
 * 
 * If you need support, post the output of `emerge --info '=media-libs/mesa-17.3.8::musl'`,
 * the complete build log and the output of `emerge -pqv '=media-libs/mesa-17.3.8::musl'`.
 * The complete build log is located at '/var/tmp/portage/media-libs/mesa-17.3.8/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/media-libs/mesa-17.3.8/temp/environment'.
 * Working directory: '/var/tmp/portage/media-libs/mesa-17.3.8/work/mesa-17.3.8'
 * S: '/var/tmp/portage/media-libs/mesa-17.3.8/work/mesa-17.3.8'

Currently, openssh is built with wtmp support because the wtmp detection in ./configure is broken for musl-based systems. The program is in a working state, of course, but any auth log output will be polluted by sshd[27660]: wtmp_write: problem writing /dev/null/wtmp: Not a directory.

I propose adding --disable-wtmp to the openssh ebuild for this overlay.
See also this bug for Alpine Linux.

There is a compile error with musl at least since 2.10.2, which is now the stable version in the gentoo tree. There is a patch available and we are having the fixed version 2.11 in the musl overlay. However, on a fresh install you will need to merge dev-vcs/git first and later on add the overlay including the fixed ebuild.

How is the status of this? Does upstream know about it, is there a gentoo bug available?

Meanwhile I would like to see the stable version 2.10.2 inherited into the overlay, was it deleted on purpose? Will create later a pullrequest for the overlay, or try to revert the commit that deletetd it if there is one, and I can find it.

libtrace.c: In function ‘log_exec’:
libtrace.c:683:18: error: ‘PATH_MAX’ undeclared (first use in this function)
static char buf[PATH_MAX + 1];
^~~~~~~~
libtrace.c:683:18: note: each undeclared identifier is reported only once for each function it appears in

Which make the build fail. I fixed it with this small patch, take a look and tell me if it is right and I will pull request

--- a/src/libtrace/libtrace.c
+++ b/src/libtrace/libtrace.c
@@ -29,7 +29,9 @@
 #include <arpa/inet.h>
 #include <sys/un.h>
 #include <sys/stat.h>
+#include <syslog.h>
 #include <dirent.h>
+#include <limits.h>

 // break recursivity on fopen call
 typedef FILE *(*orig_fopen_t)(const char *pathname, const char *mode)

Many gentoo packages for stuff in dev-lang assume glibc. They break on musl, and are generally messy.

This github issue was made to keep track of them.

One thing in common in all of these problems is that the user has no choice but to bootstrap these compilers. What I mean by this is that by default, all of these compilers are bootstrapped from binaries hardcoded in the ebuild. This behavior is bad, because if the ebuild doesn't work on a given architecture, it should be easy for the user to use their own binaries to bootstrap. A better solution would be a "bootstrap" use flag, as done by Exherbo in their dev-lang packages.

DEPENDENCIES="
    build:
        !bootstrap? ( dev-lang/go )
"

• Golang

Go is broken, since the ebuilds in the gentoo repository download stages from https://dev.gentoo.org/~williamh/dist, which contain binaries linked against glibc.

Exherbo's ebuild does this in a better way; by downloading stages directly from google. For example, for amd64, there is one stage, and it is libc independent.

• Rust

Rust is still broken on musl, because it doesn't compile with emerge rust.

• GHC (Haskell)

The stage haskell used in gentoo's ghc ebuild is linked against glibc, so the build fails. Exherbo's ebuild already accounts for musl:

DOWNLOADS+="
    bootstrap? (
        platform:amd64? (
            libc:glibc? ( http://code.haskell.org/~slyfox/${PN}-amd64/${PN}-bin-${PV}-amd64.tbz2 )
            libc:musl? ( https://www.somasis.com/dl/ghc-musl-bootstrap/${PNV}-x86_64-pc-linux-musl.tar.xz )
        )
        platform:x86? ( http://code.haskell.org/~slyfox/${PN}-x86/${PN}-bin-${PV}-x86.tbz2 )
    )
"

@milkey-mouse

here are your buid logs, including 5.0.1 for comparing and an emerge --info
USE="clang {-test}" ; clang-6 is from the musl overlay and clang-5 is from tree.

compiler-rt-sanitizers.tar.gz

seems to be the same bug?

This might not be a musl related issue, but I have no idea at this point.

Link to my forum post (contains error logs):
https://forums.gentoo.org/viewtopic-t-1071554-highlight-qtcore.html

Link to build.log
https://paste.ee/p/wHGU7

Stuff I tried:

• Patching source with alpine patches at https://git.alpinelinux.org/cgit/aports/tree/community/qt5-qtbase?h=master
• Using g++ only to compile, as I normally use clang systemwide
• qtcore-5.7.2-r3:musl compiles perfectly fine without any fiddling

Speculation:
From what I can see from the build logs, qtcore seems to test for the presence of the gold linker, and forces it's use if it is found, regardless of what is specified by the user. Since the build fails at link time, not compile time, I think this is probably the issue. But I have no idea.

Sidenote:
During the compile process, it forces the use of g++ similarly to how it forces gold, and this is also undesirable

hey there,

I wonder what is going on with the 17.0 profiles and musl?

Is there an upgrade path to enable pie?

thanks

man: bzip2: Bad system call
man: bzip2: Bad system call
man: bzip2: Bad system call
man: bzip2: Bad system call
man: bzip2: Bad system call
man: command exited with status 2: /usr/libexec/man-db/zsoelim | /usr/libexec/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl | nroff -mandoc -c -rLL=230n -rLT=230n -Tutf8

The syscall filter likely needs to be adjusted.