* [Buildroot] [PATCH] pppd: Provide error() implementation in pppoe-discovery
@ 2016-10-15 18:25 stefan.nickl at gmail.com
2016-10-15 20:33 ` Thomas Petazzoni
0 siblings, 1 reply; 7+ messages in thread
From: stefan.nickl at gmail.com @ 2016-10-15 18:25 UTC (permalink / raw)
To: buildroot
From: Stefan Nickl <Stefan.Nickl@gmail.com>
The pppoe-discovery program calls error() from the CHECK_ROOM macro
defined in pppoe.h. Since pppoe-discovery is a standalone program not
linked with the rest of pppd, the only way this could build is by
linking to glibc's proprietary error(3) function instead of the function
of the same name (but with different arguments) defined in pppd/utils.c.
So with glibc this builds, but will probably crash when the assertion is
triggered. As the assertion is unlikely to fail, nobody has noticed.
The build however fails with musl libc or uClibc since they don't
provide the doppelganger.
Signed-off-by: Stefan Nickl <Stefan.Nickl@gmail.com>
--
I noticed pppd failing in the autobuild for uClibc due to one of the issues
that also prevent it from building with musl. This should fix building
for both, as well as a latent bug when built against glibc.
diff --git a/pppd/plugins/rp-pppoe/pppoe-discovery.c b/pppd/plugins/rp-pppoe/pppoe-discovery.c
index 3d3bf4e..55037df 100644
--- a/pppd/plugins/rp-pppoe/pppoe-discovery.c
+++ b/pppd/plugins/rp-pppoe/pppoe-discovery.c
@@ -9,6 +9,7 @@
*
*/
+#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
@@ -55,6 +56,14 @@ void die(int status)
exit(status);
}
+void error(char *fmt, ...)
+{
+ va_list pvar;
+ va_start(pvar, fmt);
+ vfprintf(stderr, fmt, pvar);
+ va_end(pvar);
+}
+
/* Initialize frame types to RFC 2516 values. Some broken peers apparently
use different frame types... sigh... */
^ permalink raw reply related [flat|nested] 7+ messages in thread* [Buildroot] [PATCH] pppd: Provide error() implementation in pppoe-discovery
2016-10-15 18:25 [Buildroot] [PATCH] pppd: Provide error() implementation in pppoe-discovery stefan.nickl at gmail.com
@ 2016-10-15 20:33 ` Thomas Petazzoni
2016-10-16 20:57 ` Stefan Nickl
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Petazzoni @ 2016-10-15 20:33 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 15 Oct 2016 20:25:14 +0200, stefan.nickl at gmail.com wrote:
> From: Stefan Nickl <Stefan.Nickl@gmail.com>
>
> The pppoe-discovery program calls error() from the CHECK_ROOM macro
> defined in pppoe.h. Since pppoe-discovery is a standalone program not
> linked with the rest of pppd, the only way this could build is by
> linking to glibc's proprietary error(3) function instead of the function
> of the same name (but with different arguments) defined in pppd/utils.c.
>
> So with glibc this builds, but will probably crash when the assertion is
> triggered. As the assertion is unlikely to fail, nobody has noticed.
>
> The build however fails with musl libc or uClibc since they don't
> provide the doppelganger.
>
> Signed-off-by: Stefan Nickl <Stefan.Nickl@gmail.com>
Thanks for this patch. Could you submit this as a Buildroot patch? I.e
a patch that adds a patch to package/pppd/ ?
Also, can you detail how you produce this error (Buildroot defconfig
that exhibits the issue) ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH] pppd: Provide error() implementation in pppoe-discovery
2016-10-15 20:33 ` Thomas Petazzoni
@ 2016-10-16 20:57 ` Stefan Nickl
2016-10-16 21:14 ` Arnout Vandecappelle
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Nickl @ 2016-10-16 20:57 UTC (permalink / raw)
To: buildroot
On Sat, Oct 15, 2016 at 10:33 PM, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:
> Thanks for this patch. Could you submit this as a Buildroot patch? I.e
> a patch that adds a patch to package/pppd/ ?
>
That was my original intention hadn't I messed up :)
However yesterday's autobuild showed that the issue I had in mind did not
actually break uclibc (which really does provide the error() facility) but
just caused a warning right before things went south.
The real breakage seems due to 4.8 kernel headers, see also
https://github.com/paulusmack/ppp/pull/69.
I think things aren't as simple at the patch proposed there suggests, will
investigate...
--
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161016/61a62910/attachment.html>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH] pppd: Provide error() implementation in pppoe-discovery
2016-10-16 20:57 ` Stefan Nickl
@ 2016-10-16 21:14 ` Arnout Vandecappelle
2016-10-20 21:24 ` Stefan Nickl
0 siblings, 1 reply; 7+ messages in thread
From: Arnout Vandecappelle @ 2016-10-16 21:14 UTC (permalink / raw)
To: buildroot
On 16-10-16 22:57, Stefan Nickl wrote:
> On Sat, Oct 15, 2016 at 10:33 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com
> <mailto:thomas.petazzoni@free-electrons.com>> wrote:
>
> Thanks for this patch. Could you submit this as a Buildroot patch? I.e
> a patch that adds a patch to package/pppd/ ?
>
>
> That was my original intention hadn't I messed up :)
>
> However yesterday's autobuild showed that the issue I had in mind did not
> actually break uclibc (which really does provide the error() facility) but just
> caused a warning right before things went south.
>
> The real breakage seems due to 4.8 kernel headers, see
> also https://github.com/paulusmack/ppp/pull/69.
>
> I think things aren't as simple at the patch proposed there suggests, will
> investigate...
Are the patches[1] that you submitted to fix musl builds still valid?
Regards,
Arnout
[1] http://patchwork.ozlabs.org/patch/664683/
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH] pppd: Provide error() implementation in pppoe-discovery
2016-10-16 21:14 ` Arnout Vandecappelle
@ 2016-10-20 21:24 ` Stefan Nickl
2016-10-21 18:30 ` Arnout Vandecappelle
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Nickl @ 2016-10-20 21:24 UTC (permalink / raw)
To: buildroot
On Sun, Oct 16, 2016 at 11:14 PM, Arnout Vandecappelle <arnout@mind.be>
wrote:
> Are the patches[1] that you submitted to fix musl builds still valid?
>
>
> Regards,
> Arnout
>
> [1] http://patchwork.ozlabs.org/patch/664683/
>
>
Hi Arnout and Thomas,
sort of, but:
1) One of those patches changes stuff in the area where the current uclibc
breakage happens, but I don't know how it interacts with that. I also just
sent out a new patch for that one.
2) The series didn't include one final patch for actually allowing musl in
Config.in. I also added some stuff to expose more options from the ppp
Makefile, so that patch probably needs breaking up before it makes sense to
submit (but see alternate proposal below).
3) The patch that started this thread is a "nicer" version for one in the
series.
The thing is that pppd seems mostly unmaintained now, it contains lots of
non-linux platform code and drags stuff along that is no longer relevant,
especially for embedded people (IPX, anyone?).
So I'm trying for a stripped-down fork of pppd at
https://github.com/snickl/lppp/tree/lpppd
The idea would be to only have the most urgent/minimal fixes for classic
pppd and do musl-ification among other things in lpppd.
However at least in the beginning I'd like to drop the rp-pppoe plugin from
lpppd, which is quite a troublemaker.
Any thoughts?
--
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161020/24d947a1/attachment.html>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH] pppd: Provide error() implementation in pppoe-discovery
2016-10-20 21:24 ` Stefan Nickl
@ 2016-10-21 18:30 ` Arnout Vandecappelle
2016-10-23 18:56 ` Stefan Nickl
0 siblings, 1 reply; 7+ messages in thread
From: Arnout Vandecappelle @ 2016-10-21 18:30 UTC (permalink / raw)
To: buildroot
On 20-10-16 23:24, Stefan Nickl wrote:
> On Sun, Oct 16, 2016 at 11:14 PM, Arnout Vandecappelle <arnout@mind.be
> <mailto:arnout@mind.be>> wrote:
>
> Are the patches[1] that you submitted to fix musl builds still valid?
>
>
> Regards,
> Arnout
>
> [1] http://patchwork.ozlabs.org/patch/664683/
> <http://patchwork.ozlabs.org/patch/664683/>
>
>
> Hi Arnout and Thomas,
>
> sort of, but:
> 1) One of those patches changes stuff in the area where the current uclibc
> breakage happens, but I don't know how it interacts with that. I also just sent
> out a new patch for that one.
> 2) The series didn't include one final patch for actually allowing musl in
> Config.in. I also added some stuff to expose more options from the ppp Makefile,
> so that patch probably needs breaking up before it makes sense to submit (but
> see alternate proposal below).
> 3) The patch that started this thread is a "nicer" version for one in the series.
>
> The thing is that pppd seems mostly unmaintained now, it contains lots of
> non-linux platform code and drags stuff along that is no longer relevant,
> especially for embedded people (IPX, anyone?).
>
> So I'm trying for a stripped-down fork of pppd at
> https://github.com/snickl/lppp/tree/lpppd
>
> The idea would be to only have the most urgent/minimal fixes for classic pppd
> and do musl-ification among other things in lpppd.
Sounds good to me. I'll mark the musl patch as rejected.
This patch, however, still seems relevant, since it even fixes for glibc, no?
>
> However at least in the beginning I'd like to drop the rp-pppoe plugin from
> lpppd, which is quite a troublemaker.
It's certainly acceptable to start with an lpppd without rp-pppoe. Especially
if there is an active upstream, it will be possible to work with them to fix any
issues.
Regards,
Arnout
>
> Any thoughts?
>
> --
> Stefan
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-10-23 18:56 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-15 18:25 [Buildroot] [PATCH] pppd: Provide error() implementation in pppoe-discovery stefan.nickl at gmail.com
2016-10-15 20:33 ` Thomas Petazzoni
2016-10-16 20:57 ` Stefan Nickl
2016-10-16 21:14 ` Arnout Vandecappelle
2016-10-20 21:24 ` Stefan Nickl
2016-10-21 18:30 ` Arnout Vandecappelle
2016-10-23 18:56 ` Stefan Nickl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox