Ftl: Can’t compile on musl based Alpine Linux

[debiansid]

In raising this issue, I confirm the following (please check boxes, eg [X]) Failure to fill the template will close your issue:

• [x] I have read and understood the contributors guide.
• [] The issue I am reporting can be replicated
• [x] The issue I am reporting isn't a duplicate

How familiar are you with the codebase?:

_{1}_

---

[BUG | ISSUE] Expected Behaviour:
make

[BUG | ISSUE] Actual Behaviour:
lack of backtrace on musl, it failed.

[BUG | ISSUE] Steps to reproduce:

-
-
-
-

Log file output [if available]

usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: obj/signals.o: in function `SIGSEGV_handler':
/home/ezhang/FTL-4.2.3/signals.c:45: undefined reference to `backtrace'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /home/user/FTL-4.2.3/signals.c:46: undefined reference to `backtrace_symbols'
collect2: error: ld returned 1 exit status
make: *** [Makefile:101: pihole-FTL] Error 1

Device specifics

Hardware Type: rPi, VPS, etc
OS:Alpine Linux

_This template was created based on the work of udemy-dl._

[debiansid]

https://github.com/zuhd-org/easyloggingpp/issues/540

[DL6ER]

There seems to be no easy solution for this.

• We could use libunwind, however, this would add a new dependency. The portability demands for pihole-FTL are enormous, one can hardly imagine on how many different devices users run Pi-holes.
• We could statically link libunwind to avoid adding an external dependency, however, a quick search brought up just too many issue tickets related to statically linked libunwind.
• We could just remove the backtrace generation for non-glibc builds. This would cause backtraces to be missing, however, it should hopefully allow to compile pihole-FTL at all, so it seems to be the favorable option here.

Please try to compile our new branch tweak/musl_support with your Alpine + MUSL setup.

[debiansid]

@DL6ER
It works in build machine, I will test it out later. Thanks

do-sgp:~/FTL$ ./pihole-FTL -b
tweak/musl_support                                         
do-sgp:~/FTL$ ldd pihole-FTL 
        /lib/ld-musl-x86_64.so.1 (0x7f92595b3000)          
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f92595b3000)  

[DDoSolitary]

@DL6ER Please change #include <sys/poll.h> to #include <poll.h> in dnsmasq/dnsmasq.h, or on newer Alpine installations gcc would complain:

In file included from dnsmasq/dnsmasq.h:98,
                 from dnsmasq_interface.c:11:
/usr/include/sys/poll.h:1:2: error: #warning redirecting incorrect #include <sys/poll.h]
 #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
  ^~~~~~~
cc1: all warnings being treated as errors

If you worry about compatibility please consider using this:

#ifdef HAVE_POLL_H
#include <poll.h>
#else
#include <sys/poll.h>
#endif

[debiansid]

@DL6ER
when you will consider to make pi-hole working on alpine linux?

thanks

[dschaper]

Upstream dnsmasq would need to build cleanly without needing patches first. See the build log for that code on Alpine at https://build.alpinelinux.org/buildlogs/build-3-9-x86_64/main/dnsmasq/dnsmasq-2.80-r3.log

We want to do as little modification to the core dnsmasq code as possible so that we can easily apply upstream code improvements and patches to pihole-ftl.

[DDoSolitary]

Then we need to change the compilation arguments to allow warnings.

[DDoSolitary]

Although the -Werror flag is not used when building dnsmasq, your code does includes dnsmasq_interface.h, which indirectly includes sys/poll.h.
Adding -Wno-error=cpp to EXTRAWARN in Makefile fixes this.

[DDoSolitary]

Another suggestion: change #include <execinfo.h> in signals.c to:

#if defined(__GLIBC__)
#include <execinfo.h>
#endif

The header is only used for backtrace here and musl doesn't have it.

[DDoSolitary]

One more suggestion: /sbin/setcap -> setcap in Makefile.
Alpine has the file in /use/sbin/setcap so make install will fail.

Also, please support make DESTDIR=xxx install or packagers from other distros won't be able to use the target.

[DL6ER]

@DDoSolitary Thanks for all your comments. As Dan already pointed out and as mentioned on our documentations page, we do not change the dnsmasq code except where ultimately necessary for Pi-hole integrations.
You have some good points, so please submit them to [email protected]

We can immediately source these patches into our code without having to wait for the next regular dnsmasq release so this can happen in a few days time. The changes will then immediately become part of our development branch and will therefore also be included in the next Pi-hole release.

With your changes we can keep -Werror which is something we consider useful as it guarantees that we have a warning-free code base (the CI will fail on any warnings and hence the PR checks won't allow the code to be merged).

The header is only used for backtrace here and musl doesn't have it.

Is it really missing on musl builds? It seems @debiansid was able to compile fine even with this included. However, I see why it is obsolete without backtrace and will wrap it in #if along when we merge the Alpine-related changes you triggered from upstream dnsmasq.

One more suggestion: /sbin/setcap -> setcap in Makefile.

I don't think we can do this as we had many issues in the past with PATH not being set on all platforms causing a simple command setcap to return a command not found error.

Also, please support make DESTDIR=xxx install or packagers from other distros won't be able to use the target.

Please open two separate issue tickets about this and the preceding issue (setcap) so we discuss them separately. From my fairly long reply in this issue ticket, you can already see that things start to deviate to a point where stuff might get lost during discussions which is not good.

[DDoSolitary]

@DL6ER

You have some good points, so please submit them to [email protected]

I've never submitted any patches to a mailing list so I don't know how to do this. Could you please help me with this?

Is it really missing on musl builds?

I can replicate this error in a clean Alpine docker image with only alpine-sdk linux-headers gmp-dev nettle-dev m4 installed. I guess @debiansid has libexecinfo-dev installed (probably as a dependency) in his build environment.

Please open two separate issue tickets about this and the preceding issue (setcap) so we discuss them separately.

Done: #557 #558

[DL6ER]

You can just write them a text mail, explaining what need to be done and why it needs to be done. No need to send a pre-formatted patch as your requested change is really a tiny one.

Could you share the exact Dockerfile you use for compiling FTL? This would be helpful.

[DDoSolitary]

I don't have any Dockerfile. I just used docker as a better chroot for testing because my dev environment is Arch based.

The following is what I did:

docker run --rm -it alpine:edge
# Now inside the container
apk add alpine-sdk linux-headers gmp-dev nettle-dev m4
git clone https://github.com/pi-hole/FTL
cd FTL
make

Then I get the error mentioned in the previous comment.

---

I just tried to subscribe to the mailing list but got nothing in my email inbox. Maybe they have manual reviewing for this?

[DDoSolitary]

Patch sent: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013019.html

[DL6ER]

@DDoSolitary Even after your patch,

/FTL # grep "sys/poll.h" -C 3 dnsmasq/dnsmasq.h
#if defined(HAVE_POLL_H)
#  include <poll.h>
#else
#  include <sys/poll.h>
#endif
#include <sys/wait.h>
#include <sys/time.h>

I'm still getting

In file included from dnsmasq/dnsmasq.h:101,
                 from dnsmasq_interface.c:12:
/usr/include/sys/poll.h:1:2: error: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Werror=cpp]
 #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
  ^~~~~~~

using instructions similar to those you posted above

docker run --rm -it alpine:edge
# Now inside the container
apk add alpine-sdk linux-headers gmp-dev nettle-dev m4
git clone https://github.com/pi-hole/FTL
cd FTL
git checkout tweak/musl_support
make

[DDoSolitary]

@DL6ER Sorry. Previously, I just googled around found most solutions to this issues use this HAVE_POLL_H but I didn't test myself because I was not near my pc at that time. I did some further investigation and it turned out that HAVE_POLL_H is something provided by autotools. I'm looking for an easier way to detect if the header exists.

[DDoSolitary]

Probably we can use something like this:

#if defined(__GLIBC__)
#  include <sys/poll.h>
#else
#  include <poll.h>
#endif

Because only some older versions of glibc don't have <poll.h>.

[DL6ER]

POSIX recommends including poll.h, not sys/poll.h.
How about replacing sys/poll.h by poll.h altogether?

We do not need to support ancient versions of glibc. If this allows compilation on all platforms we officially support (only fairly recent one), that should suffice for our purposes.

[DL6ER]

This is fixed in development. One result of this discussion is that we make a full static musl binary available. There are no current plans to automatically use it, however, the Arch Linux (and possibly other) groups might be interested in using them.

[debiansid]

yep, it is fixed.

alpine:~/FTL$ ./pihole-FTL -v
v4.3-200-g822fb88

I will try to figure out manual install pi-hole onto Alpine Linux.

[AzureMarker]

Tagging @graysky2, as he helps maintain the Arch Linux Pi-hole package.

[graysky2]

See the work by @max72bra who is the principal maintainer of the Arch Linux version, https://github.com/max72bra/pi-hole-ftl-archlinux-customization

[DL6ER]

@graysky2 Thanks. Looking at the patch for v4.3.1, it seems that most (if not all) of the changes by @max72bra seem unnecessary.

He is doing the followings things:

1. Remove -Werror
   Note: I do not see any errors when compiling FTL (gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1))
2. Change the inclusion of libhogweed, libgmp, and libnettle to dynamic instead of static linking.
3. Change the fall-back paths for various files. I intentionally made all of them configurable through the pihole-FTL.conf file to make this unnecessary. You can simply ship a config file like
   LOGFILE=/run/log/pihole-ftl/pihole-FTL.log PIDFILE=/run/pihole-ftl/pihole-FTL.pid PORTFILE=/run/pihole-ftl/pihole-FTL.port SOCKETFILE=/run/pihole-ftl/FTL.sock

[max72bra]

@DL6ER oh! nice thanks, i haven't seen the commit. Anyway, there's not official documentation on that.
I'll test again on dynamic linking, thanks.

[DL6ER]

Yeah, sorry, the documentation is lacking behind, I'll catch up on that within the next two weeks

[AzureMarker]

I assume the dynamic linking is done due to standard distro packaging rules.

[deftdawg]

Hi All,

I was able to build pihole-FTL on alpine without issues thanks to the comments above (below is my script for those who are looking to do the same).

Curious if anyone already installed a full pi-hole on Alpine? I can have a go, if no-one already has...

#!/usr/bin/env sh

apk update
apk add git alpine-sdk linux-headers gmp-dev nettle-dev m4 libexecinfo-dev

# Not enough space on /, so jump to this mount
mount -o remount,rw /media/mmcblk0p1
cd /media/mmcblk0p1 

git clone https://github.com/pi-hole/FTL 
cd FTL
git checkout development
make
./pihole-FTL -v && ldd ./pihole-FTL

[DL6ER]

@deftdawg You can always see how we compile FTL for the latest alpine by looking at our compile + test x86_64-musl Dockerfile.

[deftdawg]

@DL6ER ok, I can see there deps are updated a bit, that's cool... I already have a working binary for FTL, at some point I'll need to feed that to the pi-hole installer.

I guess you guys are only using alpine to build FTL rather than run the whole pi-hole install on it? I'm working to see if I can get https://github.com/pi-hole/pi-hole/blob/master/automated%20install/basic-install.sh to work on alpine.

[DL6ER]

@deftdawg Yes. We compile FTL for musl not necessarily for alpine we just happen to use alpine for this task. The real goal is to get a self-contained binary that is independent of the installed glibc that can be used more easily with docker.

[deftdawg]

Made some good progress on getting it going on Alpine (https://github.com/deftdawg/pi-hole/blob/alpine/automated%20install/basic-install.sh), any idea when the changes relating to this stuff will be released? Would be nice if the FTL binary could be pulled from the usual place the installer gets it from. Right now, I'm manually replacing pihole-FTL with my own build from the development branch.

[Wychmire]

How is this coming along? I tried running @deftdawg's script via curl -Ssl https://raw.githubusercontent.com/deftdawg/pi-hole/alpine/automated%20install/basic-install.sh | bash but it fails after selecting ok at the FYI: IP Conflict section.

If I run it a second time it fails during

[i] Main Dependency checks...
[i] Checking for php-phar (will be installed)

and progresses no further despite how many times its run.

Edit: After enabling the community repo it still fails on the first run but on the second run it completes. lighthttpd doesn't run though, and I get

[✗] DNS service is NOT running
/opt/pihole/updatecheck.sh: line 75: /usr/bin/pihole-FTL: No such file or directory
/opt/pihole/updatecheck.sh: line 88: /usr/bin/pihole-FTL: No such file or directory

towards the end of the install.

[deftdawg]

@Wychmire Alpine won't work out-of-the box; bash is missing and the pihole-FTL binary must be built... refer to this testing script which wraps the pihole installer and builds pihole-FTL. Some more thought will have to be given as to how to resolve those before an Alpine install can be as seamless as a Centos / Ubuntu one.

[DL6ER]

The musl binary we compile should work out-of-the-box with Alpine (but not the rest of the installer).

[ilpianista]

Hi everybody,

unfortunately alpine 3.11 removed the static build of the nettle library, so the dynamic linking is needed if you want to support latest alpine.

I got pihole working on alpine 3.10. I started from scratch, but my work has been inspired by @deftdawg patch and by the last_alpine_commits branch and it's available here and here. I can file the PRs if you says to do so.

Mine isn't a port just for the sake of doing it, but I do really need to get pihole working on alpine since my BeagleBoneBlack has an eMMC of just 2GB :-)

[debiansid]

even the admin webui? I want to try it out then.

On Tue, Apr 14, 2020 at 9:24 PM Andrea Scarpino [e-mail]
wrote:

Hi everybody,

unfortunately alpine 3.11 removed the static build of the nettle library,
so the dynamic linking is needed if you want to support latest alpine.

I got pihole working on alpine 3.10. I started from scratch, but my work
has been inspired by @deftdawg https://github.com/deftdawg patch and by
the last_alpine_commits branch and it's available here
https://github.com/ilpianista/pi-hole/commits/alpine and here
https://github.com/ilpianista/docker-pi-hole/commits/alpine. I can file
the PRs if you says to do so.

Mine isn't a port just for the sake of doing it, but I do really need to
get pihole working on alpine since my BeagleBoneBlack has an eMMC of just
2GB :-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pi-hole/FTL/issues/552#issuecomment-613440168, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACJN3AJ2YFW4OJ43NZR5HF3RMRPX7ANCNFSM4HGZPMDA
.

[DL6ER]

@ilpianista Are you aware of the reasoning for removing the static build of libnettle under Alpine? It isn't a real show-stopper for us as we're not using bleeding-edge Alpine (we use 3.10 for the FTL CI build machines). We can add another building step for compiling libnettle ourselves first in case we want to switch to an Alpine version lacking static builds of libnettle. This shouldn't be an issue.

[ilpianista]

@DL6ER Apparently there's no reason for that. I'll send them a patch to get the static library in a nettle-static package.

EDIT: MR

[ilpianista]

even the admin webui? I want to try it out then.

Yes.

There's only one problem: ip -oneline is broken in alpine >= 3.9 and thus the discovery of the interfaces fails. I manually edited /etc/pihole/setupVars.conf to set the PIHOLE_INTERFACE variable.

[debiansid]

Can you send me instructions? Thanks

Sent from Mobile

On Apr 24, 2020, at 16:39, Andrea Scarpino [e-mail] wrote:


even the admin webui? I want to try it out then.

Yes.

There's only one problem: ip -online is broken in alpine >= 3.9 and thus the discovery of the interfaces fails. I manually edited /etc/pihole/setupVars.conf to set the PIHOLE_INTERFACE variable.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[DL6ER]

Pi-hole v5.0 has just been released, I'm closing this topic now. Feel free to re-open or rather open a new ticket when further discussion is needed.