From: Joe MacDonald <Joe_MacDonald@mentor.com>
To: Kang Kai <Kai.Kang@windriver.com>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-networking][PATCH] xl2tpd: 1.3.0 -> 1.3.6
Date: Tue, 22 Sep 2015 09:42:02 -0400 [thread overview]
Message-ID: <20150922134201.GA5217@mentor.com> (raw)
In-Reply-To: <56010810.2020207@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 10679 bytes --]
[Re: [oe] [meta-networking][PATCH] xl2tpd: 1.3.0 -> 1.3.6] On 15.09.22 (Tue 15:49) Kang Kai wrote:
> On 2015年09月22日 02:39, Joe MacDonald wrote:
>
> Hi Kai,
>
> [[oe] [meta-networking][PATCH] xl2tpd: 1.3.0 -> 1.3.6] On 15.09.18 (Fri 17:14) kai.kang@windriver.com wrote:
>
>
> From: Kai Kang <kai.kang@windriver.com>
>
> Upgrade xl2tpd v1.3.0-46-gdf7e30e to 1.3.6.
>
> * drop PR
> * add patch to fix build failure with gcc 5.x
>
> Signed-off-by: Kai Kang <kai.kang@windriver.com>
> ---
> .../recipes-protocols/xl2tpd/xl2tpd.inc | 2 -
> .../fix-inline-functions-errors-with-gcc-5.x.patch | 116 +++++++++++++++++++++
> .../recipes-protocols/xl2tpd/xl2tpd_1.3.6.bb | 5 +
> .../recipes-protocols/xl2tpd/xl2tpd_git.bb | 5 -
> 4 files changed, 121 insertions(+), 7 deletions(-)
> create mode 100644 meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
> create mode 100644 meta-networking/recipes-protocols/xl2tpd/xl2tpd_1.3.6.bb
> delete mode 100644 meta-networking/recipes-protocols/xl2tpd/xl2tpd_git.bb
>
> diff --git a/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc b/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
> index 1a72fd1..03a1a0b 100644
> --- a/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
> +++ b/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
> @@ -6,8 +6,6 @@ DEPENDS = "ppp virtual/kernel"
> LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://LICENSE;md5=0636e73ff0215e8d672dc4c32c317bb3"
>
> -INC_PR = "r0"
> -
> SRC_URI = "git://github.com/xelerance/xl2tpd.git"
>
> S = "${WORKDIR}/git"
> diff --git a/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch b/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
> new file mode 100644
> index 0000000..dc78f02
> --- /dev/null
> +++ b/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
> @@ -0,0 +1,116 @@
> +Upstream-Status: Pending
> +
> +GCC 5.x defaults to -std=gnu11 instead of -std=gnu89. The semantics for
> +inline functions changes which causes build failures such as:
> +
> +| misc.h:68:20: warning: inline function 'swaps' declared but never defined
> +| extern inline void swaps (void *, int);
> +| ^
> +
> +and
> +
> +| control.c:1717: undefined reference to `check_control'
> +
> +Fix them by:
> +1 drop 'inline' attribute for function swap()
>
> The question about whether 'inline' belongs in a .c file or not aside
> (that's obviously not your department, that's how it is in the original
> code), why is swaps() treated differently than every other function? If
> the compiler really needed to be told 'inline' on all of these, this
> just ensures that swaps() is never inlined. Is that your intent?
>
>
> For the functions except swap(), they are not referred by other .c files. So
> they are not needed to be exported and can be mark as static inline.
Can you confirm you're looking at what you think you're looking at? The
modification is to a function called swaps() not swap().
> For swap(), it is referred by other .c files. It must be exported.
Are the other .c files #include-ing this one? If not, I can't see how
this was ever working. Anyway, my question was just primarily "did you
intend that swaps() would never be inlined". The behaviour now is that
swaps() will only be inlined now if the compiler thinks it can be in the
.c file where it is defined and if some other .c files are managing to
link against it (presumably through some implicit declaration) then it
will rely on an external reference. That's what you want to do here?
It seems like something that should be submitted upstream if only to vet
the change.
As a band-aid for building with gcc 5.x and 4.x simultaneously, though,
it seems okay.
-J.
>
> But the semantics for inline functions changes from gcc 4.x to gcc 5.x. GCC 5
> defaults to -std=gnu11 instead of -std=gnu89.
> While -std=gnu89 employs the GNU89 inline semantics, -std=gnu11 uses the C99
> inline semantics.
>
> • C99 inline: No externally visible function is generated. If the function is
> referenced in this TU, an external definition has to exist in another TU;
> same as GNU89 extern inline with no redefinition.
> • C99 extern inline: An externally visible function is generated; same as
> GNU89 inline.
> • GNU89 inline: Same as C99 extern inline.
> • GNU89 extern inline: No externally visible function is generated; no
> equivalent in C99, because redefinition is not permitted.
>
>
> There are not same meaning of 'extern inline'. For compatible with gcc 4.x, I
> choose to remove the inline attribution from function swap().
>
> Ref:
> https://gcc.gnu.org/gcc-5/porting_to.html
>
>
> Regards,
> Kai
>
>
>
> -J.
>
>
> +2 replace 'inline' with 'static inline' for other functions
> +
> +Signed-off-by: Kai Kang <kai.kang@windriver.com>
> +---
> + control.c | 8 ++++----
> + misc.c | 2 +-
> + misc.h | 2 +-
> + network.c | 4 ++--
> + 4 files changed, 8 insertions(+), 8 deletions(-)
> +
> +diff --git a/control.c b/control.c
> +index 134a7bf..0ef505b 100644
> +--- a/control.c
> ++++ b/control.c
> +@@ -1139,7 +1139,7 @@ int control_finish (struct tunnel *t, struct call *c)
> + return 0;
> + }
> +
> +-inline int check_control (const struct buffer *buf, struct tunnel *t,
> ++static inline int check_control (const struct buffer *buf, struct tunnel *t,
> + struct call *c)
> + {
> + /*
> +@@ -1275,7 +1275,7 @@ inline int check_control (const struct buffer *buf, struct tunnel *t,
> + return 0;
> + }
> +
> +-inline int check_payload (struct buffer *buf, struct tunnel *t,
> ++static inline int check_payload (struct buffer *buf, struct tunnel *t,
> + struct call *c)
> + {
> + /*
> +@@ -1381,7 +1381,7 @@ inline int check_payload (struct buffer *buf, struct tunnel *t,
> + #endif
> + return 0;
> + }
> +-inline int expand_payload (struct buffer *buf, struct tunnel *t,
> ++static inline int expand_payload (struct buffer *buf, struct tunnel *t,
> + struct call *c)
> + {
> + /*
> +@@ -1561,7 +1561,7 @@ void send_zlb (void *data)
> + toss (buf);
> + }
> +
> +-inline int write_packet (struct buffer *buf, struct tunnel *t, struct call *c,
> ++static inline int write_packet (struct buffer *buf, struct tunnel *t, struct call *c,
> + int convert)
> + {
> + /*
> +diff --git a/misc.c b/misc.c
> +index 3092401..af90dbf 100644
> +--- a/misc.c
> ++++ b/misc.c
> +@@ -170,7 +170,7 @@ void do_packet_dump (struct buffer *buf)
> + printf ("}\n");
> + }
> +
> +-inline void swaps (void *buf_v, int len)
> ++void swaps (void *buf_v, int len)
> + {
> + #ifdef __alpha
> + /* Reverse byte order alpha is little endian so lest save a step.
> +diff --git a/misc.h b/misc.h
> +index aafdc62..caab7a1 100644
> +--- a/misc.h
> ++++ b/misc.h
> +@@ -65,7 +65,7 @@ extern void l2tp_log (int level, const char *fmt, ...);
> + extern struct buffer *new_buf (int);
> + extern void udppush_handler (int);
> + extern int addfcs (struct buffer *buf);
> +-extern inline void swaps (void *, int);
> ++extern void swaps (void *, int);
> + extern void do_packet_dump (struct buffer *);
> + extern void status (const char *fmt, ...);
> + extern void status_handler (int signal);
> +diff --git a/network.c b/network.c
> +index 5e5b8b2..b019c2c 100644
> +--- a/network.c
> ++++ b/network.c
> +@@ -135,7 +135,7 @@ int init_network (void)
> + return 0;
> + }
> +
> +-inline void extract (void *buf, int *tunnel, int *call)
> ++static inline void extract (void *buf, int *tunnel, int *call)
> + {
> + /*
> + * Extract the tunnel and call #'s, and fix the order of the
> +@@ -155,7 +155,7 @@ inline void extract (void *buf, int *tunnel, int *call)
> + }
> + }
> +
> +-inline void fix_hdr (void *buf)
> ++static inline void fix_hdr (void *buf)
> + {
> + /*
> + * Fix the byte order of the header
> +--
> +1.9.1
> +
> diff --git a/meta-networking/recipes-protocols/xl2tpd/xl2tpd_1.3.6.bb b/meta-networking/recipes-protocols/xl2tpd/xl2tpd_1.3.6.bb
> new file mode 100644
> index 0000000..aac11b7
> --- /dev/null
> +++ b/meta-networking/recipes-protocols/xl2tpd/xl2tpd_1.3.6.bb
> @@ -0,0 +1,5 @@
> +require xl2tpd.inc
> +
> +SRCREV = "5619e1771048e74b729804e8602f409af0f3faea"
> +
> +SRC_URI += "file://fix-inline-functions-errors-with-gcc-5.x.patch"
> diff --git a/meta-networking/recipes-protocols/xl2tpd/xl2tpd_git.bb b/meta-networking/recipes-protocols/xl2tpd/xl2tpd_git.bb
> deleted file mode 100644
> index bd084aa..0000000
> --- a/meta-networking/recipes-protocols/xl2tpd/xl2tpd_git.bb
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -require xl2tpd.inc
> -PR = "${INC_PR}.0"
> -
> -SRCREV = "df7e30eb199fc5710faa83866381aea18b66e60c"
> -
> --
> 1.9.1
>
>
>
>
> --
> Regards,
> Neil | Kai Kang
>
--
-Joe MacDonald.
:wq
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
next prev parent reply other threads:[~2015-09-22 13:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-18 9:14 [meta-networking][PATCH] xl2tpd: 1.3.0 -> 1.3.6 kai.kang
2015-09-21 18:39 ` Joe MacDonald
2015-09-22 7:49 ` Kang Kai
2015-09-22 13:42 ` Joe MacDonald [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-11-30 7:38 kai.kang
2015-12-01 2:00 ` Joe MacDonald
2015-12-01 2:19 ` Kang Kai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150922134201.GA5217@mentor.com \
--to=joe_macdonald@mentor.com \
--cc=Kai.Kang@windriver.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.